Enable Cache Components
Next.js 16 introduces Cache Components that replaces the old implicit caching model and makes data fetching dynamic by default. You have to use the 'use cache' directive to perform caching giving you more control over what is cached and their duration.
For a SitecoreAI Content SDK application, this means:
- Editing and preview modes always bypass the cache.
- Every component is handled individually and you should not wrap the
<Placeholder/>component with<Suspense/>. - Cached data is automatically refreshed after a set duration using
cacheLife. - You can manually invalidate cached data after a mutation using
revalidateTag,updateTag, orrevalidatePath. - You can render content at runtime using the
connection()function and not pre-render at build time. This usually occurs when you access external information that you intentionally want to change the result of a render, such asMath.random()ornew Date().
To set up Cache Components in your Content SDK Pages Router app:
-
In your
next.config.tsfile, enable thecacheComponentsflag as shown: -
All route handlers are dynamic by default when using Cache Components. The route segment configuration in your route handlers is therefore incompatible and must be removed. In the following files:
src/app/api/editing/config/route.tssrc/app/api/editing/render/route.tssrc/app/api/sitemap/route.tssrc/app/api/robots/route.ts
Remove the following line:
-
Copy the 3 cached versions of your data fetching functions for page, dictionary, and error page requests into the
src/lib/cachefolder. -
After copying the data fetching functions, you must now update references to use them.
-
In
/[[...path]]/page.ts, replace instances of theclient.getPagefunction in the component andgenerateMetadatafunctions with thegetSitecorePagefunction fromsrc/lib/cache:ImportantDo not wrap the component with
'use cache';.In the
draft.isEnabledblock, do not routeclient.getPreviewandclient.getDesignLibraryDatathrough cache helpers. -
In
src/app/not-found.tsxand/[[...path]]/not-found.tsx, replace instances ofclient.getErrorPagewith thegetSitecoreErrorPagefunction fromsrc/lib/cache:ImportantDo not apply
'use cache';to the entireNotFoundcomponent. The file relies ongetCachedPageParams()inside the cached boundary, and React cache boundaries do not align with Next.js cache context in this case. -
In
global-error.tsx, verify that it renders a dedicated layout that does not reference any cache components, as global-error is a client component. You will most likely need to introduce a separate layout rather than using a shared one. -
In
i18n/request.ts, replace instances ofclient.getDictionarywith thegetSitecoreDictionaryfunction from thesrc/lib/cachefolder:ImportantYou must disable the SDK's dictionary cache in the client configuration (
sitecore.config.ts) so that it doesn't clash with the Cache Components layer:
-
Add cache tags to cached reads
Using 'use cache' together with cacheLife() enables time-based cache expiry, but it does not provide a mechanism for targeted cache invalidation.
To invalidate specific content on demand, such as after a Sitecore publish webhook, each cached data-fetching function must register deterministic cache tags using cacheTag(). The revalidation endpoint must then reconstruct and revalidate the same tag values.
The Content SDK provides helper functions that generate these tags consistently for both page rendering and webhook processing. Use the SDK helpers rather than constructing tag strings manually.
Import the helpers from the SDK package entry point:
The helper functions normalize tag segments before constructing tag values. Segments are:
- Converted to lowercase
- Sanitized so that
/, :,and whitespace characters become_.
This ensures tags remain stable regardless of differences in URL casing, encoding, or webhook payload formatting.
Because cached reads and webhook handlers use the same SDK tag builders, a Sitecore publish webhook or custom mutation flow can reconstruct the correct tag and invalidate the exact cache entries that were created during rendering.
Without cache tags, Cache Components are limited to time-based expiration through cacheLife(). With cache tags, applications can support immediate, event-driven cache invalidation through revalidateTag() or updateTag().
collectSitecorePageCacheTags
collectSitecorePageCacheTagsThe collectSitecorePageCacheTags() helper function returns a deduplicated string[] containing:
- The route tag
- The item tag associated with the rendered Sitecore item.
You can use this helper in page and error-page cache functions.
buildSitecoreDictionaryCacheTag
buildSitecoreDictionaryCacheTagThe buildSitecoreDictionaryCacheTag() helper function returns the dictionary tag for a site and locale.
You can use this helper in dictionary cache functions.
Avoid multiple caching layers
If your SitecoreClient or another fetch layer also uses Next.js fetch caching options such as cache: 'force-cache', next: { revalidate }, or next: { tags }, then you effectively have two caching layers.
'use cache'on helper functions likegetSitecorePageandgetSitecoreDictionary, which caches at the application level and can be invalidated withrevalidateTagusingcacheTagnames.- The fetch data cache, controlled by
fetchoptions and invalidated through tags on fetch requests if you use them.
To keep behavior predictable, it is recommended to prefer one main caching strategy and avoiding conflicting time-to-live (TTL) assigned to the same GraphQL response. If you use both tag systems, make sure webhook invalidation covers both naming schemes.