What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In Next.js 16, enable Partial Prerendering through Cache Components: set cacheComponents: true in next.config.ts. This is an application-level setting, so you can begin by migrating and validating one target page rather than changing every route’s code at once. The page can combine a prerendered shell with cached content and request-time sections streamed inside React Suspense boundaries.
What changed in Next.js 16
Next.js 16’s current Partial Prerendering behavior is part of Cache Components. The opt-in configuration is cacheComponents: true; the older experimental.ppr flag and route-level experimental_ppr setting belong to an earlier canary implementation, not the Next.js 16 setup. Cache Components first appeared in Next.js 16.0.0 and unifies the earlier ppr, useCache, and dynamicIO flags. See the Next.js 16 upgrade guide and the cacheComponents configuration reference.
With Cache Components enabled, Next.js prerenders a shell containing static HTML and serialized React Server Component payload. Work that can finish during prerendering—including synchronous I/O, module imports, and pure computation—can be included. Work that cannot finish then must either be cached when reuse is suitable or deferred until a request, typically behind Suspense. The official Partial Prerendering guide describes this model.
Migrate one page first
- Confirm your Next.js version and rendering setup. Use the Next.js 16 Cache Components path rather than copying instructions for the older canary feature. If your application is already using the Next.js 15 canary PPR implementation, follow the version-specific guidance in the upgrade guide rather than mixing both configurations.
- Enable Cache Components in the Next config. In
next.config.ts, addcacheComponents: trueto the exported configuration. This is a project-level switch, not a per-route flag. Keep your first migration scope to the page you intend to validate. - Inspect the target route’s work. Identify data access and other operations that need request-specific information or cannot complete during prerendering. In development or during a build, Next.js reports an
Uncached data was accessed outside of <Suspense>error when uncached work is left outside a Suspense boundary. - Choose caching or deferral for each dynamic section. Use
use cachefor data or output that can be reused and does not depend on request-local context. For request-dependent content, isolate the runtime access in a subtree rendered behind Suspense. The fallback becomes part of the prerendered shell while the actual result streams at request time. - Make each boundary narrow and its fallback useful. Place Suspense close to the component that needs dynamic work. A narrow boundary keeps more of the page in the shell, and separate dynamic sections can render in parallel.
- Review legacy route-segment settings. With Cache Components enabled, older settings such as
dynamic,revalidate, andfetchCachegive way to the newer cache model. The migration guide saysforce-dynamicis unnecessary; start by removingforce-staticand resolving resulting errors, usecacheLifeinstead of route-levelrevalidate, and do not usefetchCachewithin ause cachescope. - Build and validate for your deployment runtime. Inspect build output to confirm whether the target route is fully prerendered or contains the dynamic holes you expect. Cache Components requires the Node.js runtime and is not supported on Edge Runtime. Check your hosting platform’s PPR support and cache behavior before production deployment.
Choose what happens to dynamic content
| Approach | Use it when | What the reader sees | What you must manage |
|---|---|---|---|
use cache with an appropriate cache lifetime |
The data does not need to be fresh on every request and does not require request-local context. | Reusable output can be included in the shell or reused at runtime. | Choose a suitable lifetime with cacheLife or arrange tag-based/on-demand invalidation when needed. |
| Defer work behind Suspense | The result needs request-time information or must remain uncached and fresh. | The fallback appears in the shell; the dynamic result streams at request time. | Keep the boundary focused and make its fallback useful while the result is pending. |
Neither option is universally faster or correct. Decide based on freshness and personalization needs, whether the code requires request context, the quality of the fallback, and how much cache invalidation your application can reliably handle.
#1 Best Overall
Handle request context and metadata deliberately
APIs such as cookies(), headers(), and request-specific searchParams need request context. Keep those reads in the dynamic subtree that needs them and place that subtree behind Suspense so the rest of the page can prerender. Do not move personalized values into a shared cache unless that reuse is safe for the users and requests involved.
Metadata and viewport access are tracked separately. If only metadata or viewport code reads uncached or runtime data, that data still needs to be explicitly cached where appropriate, or the application must signal intentional deferred rendering. Check these paths as well as the visible page body during migration.
Rank #2
Check legacy configuration and navigation behavior
Cache Components changes how route-level caching and rendering configuration is expressed. Review each legacy setting rather than mechanically carrying it over: force-dynamic is unnecessary, force-static should initially be removed while you address errors, cacheLife replaces route-level revalidate, and fetchCache is not needed inside a use cache scope. Consult the migration guide for the applicable code patterns.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →With Cache Components enabled, Next.js uses React <Activity> to preserve state for recently visited routes during client-side navigation. Include navigation and state-retention checks in your validation, rather than testing only the first page load.
Verify support before deployment
- Confirm the application runs on Node.js; Cache Components is not supported on Edge Runtime.
- Review build output for the target route and make sure its static shell and deferred sections match your design.
- Test the page with request-specific data, cache invalidation, and client-side navigation as relevant to its behavior.
- Check the deployment platform’s implementation and cache behavior. The Next.js self-hosting guide points to platform-specific PPR support information; support should not be assumed to be identical everywhere.
Next.js describes Cache Components as a way to combine static, cached, and dynamic content in one route. That is the framework’s stated design rationale, not a measured performance guarantee; the cited documentation does not establish a general speedup percentage.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
