After a stale-data fix, a Next.js App Router app that used to prerender most of its routes now builds with almost every route rendered on demand, and TTFB and origin CPU are up. How do you find what turned prerendering off, and how do you get it back?

## Step 1 — get the facts from the build, not from intuition `next build` prints a route table that says, per route, whether it was prerendered or will be rendered on demand. This is the artifact to reason from, because it reflects what actually shipped rather than what the code appears to say. Two shapes of damage: - **A whole subtree went dynamic** → suspect a `layout.tsx` in that subtree. - **Essentially everything went dynamic** → suspect the root layout, or a module imported by every route. Compare against the previous build's table if you keep them in CI. If you do not, this incident is the argument for starting: a diff of that table is the cheapest possible regression detector for exactly this class of change. ## Step 2 — the usual suspects, in order of likelihood **A segment config in a layout.** The root layout is rendered inside every route in the app. If it declares itself request-time, nothing beneath it can be served as a prerendered document — which is every page you have. ```tsx // app/layout.tsx — a one-line change with app-wide reach export const dynamic = 'force-dynamic' ``` The same is true of `export const revalidate = 0` there. Both express "do not reuse a stored render of this segment," and the root segment is inside everything. **A shared component that awaits `connection()`.** A header, a nav, or an experiment wrapper rendered by the root layout has the same reach as the layout itself. This one is harder to spot because the marker is in a component file rather than in a route file. **A `no-store` inside a shared data helper.** Someone needed one caller to be fresh and edited the helper instead of the call site. Now every page that imports it re-reads that data. This may not by itself flip routes to dynamic, but it does explain a spike in upstream traffic and origin CPU that arrives alongside the rendering change — and the two edits usually ship in the same commit. **Reading request data in something shared.** Pulling cookies or headers into a shared layout ties every route to a request. Whether that was the deliberate fix or collateral from a refactor, the effect is the same as the config export. ## Step 3 — confirm before you fix Bisect. Revert the single suspect line, rebuild, and diff the route table. This matters because the plausible causes stack: teams under staleness pressure frequently ship two or three of them at once, and reverting one while another remains looks like "the fix did nothing," which sends people down the wrong path. One change, one build, one table diff. ## Step 4 — re-fix at the right scope The original stale-data bug was real; do not simply revert and leave it broken. Re-implement the fix as low as it will go: 1. If it was one read, mark that read uncached at its call site — and if it lives in a shared helper, pass the caching decision in as a parameter so each caller states its own need instead of inheriting someone else's. 2. If a component must genuinely execute per request, put `await connection()` in that component rather than in a layout above it. 3. Only if the entire route is per-request should the segment config appear, and it belongs in that route's own `page.tsx`, not in a layout other routes share. Then split the page so the request-time region is its own component and streams in, leaving the document itself prerenderable. That is the shape that gives you both correctness and a fast first byte. ## Step 5 — make the regression visible next time The reason this incident is expensive is that nothing failed. Tests passed, the page was correct, and the only symptom was a slower, more expensive site. Two cheap guards: - Assert on the build's route table in CI — fail the build if a route that is expected to be prerendered is not. - Treat any segment config export in a `layout.tsx`, especially the root, as a reviewed change with a written justification. Opt-outs in shared files are the only ones that scale badly, so they are the ones worth gating. ## What the interviewer is listening for They want the reflex of *placement over flags*: the candidate who immediately asks "where was that put?" rather than "which flag was used?", who reads the build output rather than guessing, and who can name the cost in the currency of the incident — TTFB, origin CPU, upstream request volume — instead of describing caching in the abstract.