In a Next.js App Router app, do you have to configure anything for one route's JavaScript to stay out of another route's initial download, and what is next/dynamic for then?
answer
- routes are already separate downloads
- the extra split lives inside one route
- deferral, not deletion
- interaction-gated, and big relative to the route
- loading fallback reserves the space
basics
~10 sNothing to configure: Next.js code-splits per route automatically, so visiting /dashboard does not download /settings' client code. next/dynamic splits inside a route, deferring a heavy component until it is actually rendered or needed.
solid answer
~40 sRoute-level splitting is free in the App Router. Each route segment's client components end up in their own chunks, plus a shared chunk for what every route needs (the framework runtime, the root layout's client code, widely imported modules). You never touch bundler config for that. `next/dynamic` is the *within-route* tool: `const Chart = dynamic(() => import('./Chart'))` keeps that component out of the chunk the route loads up front and fetches it when it first renders. You reach for it when a single route carries something heavy that most visitors never see — a chart library, a rich text editor, a map, a modal's contents — or something that only works in the browser. It is a deferral, not a deletion: the code is still built and shipped, just requested later.
go deeper
Know that Next splits JavaScript per route with no setup, and that next/dynamic is how you defer one heavy component inside a route. Be able to write the dynamic() call with a loading fallback.
Explain that the import graph, not the render branch, decides what ships, so a conditionally rendered component still lands in the eager chunk. Say what the loading option is for and why deferral is not deletion.
Show you pick split points from measurements: which routes are heavy, what fraction of users hit the deferred path, and what the added request latency costs at the moment of interaction. Mention prefetching on intent and verifying the drop in the build output.
Own the policy question — where splitting is worth the extra chunk and where the team should instead cut the dependency or move work to the server. Set a budget the build output can be checked against so splitting decisions stop being folklore.
## The default: one split per route In the App Router you do not configure code splitting. When Next builds, every route segment gets its own client JavaScript chunks, and modules needed by many routes are hoisted into shared chunks. A visitor landing on `/dashboard` downloads the framework runtime, the shared chunks, the client code of the layouts wrapping that route, and that route's own client code — and nothing that belongs only to `/settings`. This is why the `next build` route table prints a per-route number alongside a "shared by all" number: the per-route figure is what that page adds on top of the common baseline. ## What that default does not do Route splitting is *coarse*. It says nothing about the size of a single route. If one page statically imports a 300 kB charting library at the top of a client component, that library lands in the chunk the route needs before it can render — even if the chart lives behind a tab nobody clicks. ```tsx 'use client' import { Chart } from 'heavy-chart-lib' // downloaded on first paint of this route export function Panel({ open }: { open: boolean }) { return open ? <Chart /> : <p>Open the panel to see the chart.</p> } ``` The conditional render does not help. Whether a module ships is decided by the import graph at build time, not by which branch runs. ## What next/dynamic adds `next/dynamic` turns a static import into a lazily fetched chunk that is requested when the component first renders: ```tsx 'use client' import dynamic from 'next/dynamic' const Chart = dynamic(() => import('./Chart'), { loading: () => <p>Loading chart…</p>, }) ``` The factory must be a literal `import()` the bundler can see statically — a computed specifier gives it nothing to split on. If the module exports the component by name rather than as a default, resolve it in the factory: ```tsx const Chart = dynamic(() => import('./Chart').then((mod) => mod.Chart)) ``` Two options matter. `loading` supplies the placeholder shown while the chunk is in flight — give it roughly the height of the real thing so the page does not jump when it arrives. `ssr: false` additionally tells Next not to render the component on the server at all, which is how you host browser-only libraries. ## It defers; it does not delete A dynamically imported module is still compiled, still deployed, and still downloaded by anyone who reaches the code path. The win is *when*, not *whether*. That has two consequences worth saying out loud in an interview: - **Total bytes can go up.** More chunks means more requests and a little duplicated boilerplate. Splitting a 4 kB component is pure overhead. - **The deferred fetch has to happen sometime**, and it happens at the moment the user asked for the thing. If that moment is a click, the spinner is visible latency you have moved rather than removed. Prefetching on hover or intent is the usual mitigation. ## When it is actually worth it Good candidates: a component that is large relative to the route (tens of kilobytes and up), that a minority of visitors on that route ever sees, and whose appearance is already gated behind an interaction — modals, drawers, editors, maps, charts, video players, admin-only panels. Bad candidates: anything above the fold, anything on the critical render path, and anything small. Also note the pull in the other direction: if two routes each dynamically import the same heavy module, the bundler will usually put it in a chunk they share, so the first route to load it pays and the second gets it from cache. ## Checking your work The honest check is the build output before and after: did this route's First Load JS actually drop? If it did not, the module is still reachable from something that loads eagerly — a static import elsewhere in the same route's graph will keep it in the eager chunk no matter how many `dynamic()` wrappers point at it. `@next/bundle-analyzer` shows which chunk it landed in and what dragged it there.
- If splitting is automatic per route, why does the build output still report a chunk shared by every route?Because some code genuinely is common: the framework runtime, the root layout's client components, and modules imported from enough places that the bundler hoists them instead of duplicating them per route. That baseline is downloaded once and cached, so it counts toward every route's first load but only costs the user on the first page they visit.
- Does wrapping a component in next/dynamic remove it from the deployed build?No. It is still compiled and shipped as its own chunk; you have only changed when the browser requests it. Anyone who triggers the code path downloads it then. If your goal is to stop shipping the code at all, the answer is deleting the dependency or moving the work to the server — not a lazy import.
- What happens if you pass a computed module path to next/dynamic, such as dynamic(() => import(`./widgets/${name}`))?The bundler can no longer identify a single target, so it either fails or bundles every module matching the pattern into the split — usually the opposite of what you wanted. Keep the specifier a literal string, and use an explicit map from key to a distinct `dynamic()` call when you need to choose at runtime.
saying these in an interview costs you the question
- Thinks you must hand-configure webpack splitChunks in Next
- Says next/dynamic reduces the total JavaScript shipped
- Believes a conditional render keeps an imported module out of the bundle
- Wraps small components in dynamic() and calls it an optimization
- Confuses lazy-loading code with lazy-loading data