Next.js 16.3 ships Instant Navigations alongside a set of experimental Turbopack chunking controls. The headline feature gets the attention, but the chunking controls underneath it are what determine whether navigations actually feel instant on a real app with a real component tree — not just a demo route.
The Problem These Flags Solve
Route-level chunking — bundling JavaScript and CSS by route boundary — works fine until your app has shared components used across unrelated pages, or styles that only make sense when several components render together. Two symptoms show up in production: navigating to a page loads different (and sometimes visually inconsistent) CSS than refreshing directly on it, and the runtime can't make smart decisions about what to fetch because it only understands chunks at the page level.
Next.js 16.3 addresses both at a finer grain.
Component-Level Chunking
generateComponentChunks makes Turbopack chunk-aware at the component level instead of only at route boundaries. In practice, this lets the runtime decide what to fetch based on what's already cached, rather than re-fetching an entire route's worth of JavaScript for a small shared change.
// next.config.js
module.exports = {
experimental: {
generateComponentChunks: true,
},
};The benefit compounds on apps with a heavy shared UI layer — design systems, dashboards with reused chart or table components — where route-level chunking was forcing redundant downloads.
Graph-Based CSS Chunking
cssChunking: "graph" groups styles by which components actually render together across the app, instead of inferring groupings from the route tree. This directly targets the "this page looks different when I navigate to it versus when I refresh" class of bug, which is usually caused by shared styles getting duplicated, or arriving in an unpredictable order relative to page-specific styles.
// next.config.js
module.exports = {
experimental: {
cssChunking: "graph",
},
};Tuning staleTimes
staleTimes controls how long the client trusts its in-memory copy of a page before refetching — static for fully prefetched pages (5 minutes by default) and dynamic for everything else (0 by default, meaning always refetch). Combined with Instant Navigations, tuning this is how you trade a bit of staleness for meaningfully fewer network round-trips on pages that don't change often.
// next.config.js
module.exports = {
experimental: {
staleTimes: {
dynamic: 30,
static: 300,
},
},
};A dynamic value of 30 seconds is a reasonable starting point for content that updates occasionally but doesn't need to be real-time on every navigation — internal dashboards and catalog pages are typical candidates.
When It's Worth Enabling
These are still experimental flags, and that's not a formality — behavior can change between minor releases. We'd reach for them when:
- The app has a large shared component or design-system layer reused across many routes.
- You've actually observed the navigate-vs-refresh CSS inconsistency, not just suspect it.
- Navigation performance is a measured problem (Core Web Vitals, user complaints), not a hypothetical one.
Migration Notes
Enable one flag at a time on a staging environment, not all three at once — if something regresses, you want to know which control caused it. Watch bundle analyzer output before and after; component-level chunking can increase the total chunk count even as it reduces redundant downloads, which is a tradeoff worth confirming for your app rather than assuming.
webhani's Take
For projects we run on Next.js, we treat experimental flags as something to pilot on a single high-traffic route first, not roll out app-wide. cssChunking: "graph" is the one we'd prioritize if you're actively seeing style inconsistencies — it fixes a real, user-visible bug class. The component chunking and staleTimes tuning are worth adopting once you have data showing navigation payload size or staleness is actually the bottleneck, rather than enabling them speculatively.