After running `next build` on a Next.js app, the route table prints a "First Load JS" column per route plus a "First Load JS shared by all" line. What does each number actually count?

## Reading the table `next build` ends with a table of routes. For the App Router the columns are the route path, `Size`, and `First Load JS`, followed by a legend for the route markers and a separate `+ First Load JS shared by all` line with the shared chunks broken out beneath it. The mental model is a stack of layers a browser must have before that route can render in the client: 1. The **shared baseline** — the framework and React runtime, and modules imported from so many places that the bundler hoisted them into a common chunk. 2. The **layout chunks** for every layout wrapping that segment, including the root layout's client components. 3. The **route's own chunk** — the page's client components and everything they statically import. `First Load JS` is the sum of all three. `Size` is roughly the third layer alone: what this route contributes on top of what it inherits. ## The two misreadings **Adding the column down the page.** The rows are not disjoint. Every route includes the shared baseline, so summing them massively overcounts — it counts the shared chunks once per route. If you want "how much JavaScript does this app ship in total", the route table is the wrong instrument; the analyzer's treemap of the client bundle is the right one. **Reading it as what every visit costs.** It is a *first* load figure. Once the shared chunks are in the browser cache, a client-side navigation to another route fetches only what that route adds. So a fat shared baseline is worse than a fat leaf route: everyone pays it once and it sits on the critical path of every cold entry point, while a heavy leaf route is only paid by people who land there. ## What moves which number This is the diagnostic value of splitting the two figures. - Adding an import inside one page's client component moves **that route's `Size`** and its First Load JS. - Adding an import to the **root layout**, to a provider wrapped around the whole app, or to a module many routes already use, moves the **shared** number — and therefore every route at once. A jump in the shared line is the loudest signal in the whole build output, because it is a regression for every entry point simultaneously. - Wrapping a component in `next/dynamic` should move the route's number down without changing the shared line, *provided* nothing else still imports that module eagerly. A useful habit is to record the shared number and the two or three highest routes for each release, so "it grew" is a fact rather than a hunch. ## What it does not include First Load JS counts JavaScript, and only the client bundle. It does not tell you about: - **CSS**, images, or fonts, which also block or delay rendering. - **Server-side code.** Modules used only by Server Components or route handlers do not appear in the client figure at all — which is precisely why moving work to the server shows up here as a drop. - **What is actually executed.** A chunk can be downloaded and largely unused; bytes shipped and bytes needed are different questions. - **Compression.** Interpret the figure consistently — compare build to build rather than arguing about the absolute number against numbers quoted elsewhere. ## Turning it into a check The number is only useful if someone looks at it. Two practical moves: - Print the build output in CI and eyeball the shared line on every release, or fail the build when it crosses a threshold you chose deliberately. - When a route regresses, do not guess: run the build with `@next/bundle-analyzer` enabled and look at the treemap for that route's chunk. The table tells you *that* something grew; the analyzer tells you *what*. ```bash ANALYZE=true npx next build ``` The pairing is the point — the route table is the alarm, the analyzer is the investigation.