Choosing a rendering strategy per route

Each tank carries a printed panel, the same for every visitor and readable by anyone walking past, including the guidebook writer who copies only what is on the walls. A panel is reprinted when the tank's residents change. A keeper gives each school group its own talk, so at the busy hour groups queue for keepers. The handheld audio guide says nothing until a visitor starts it. The shark tank's feeding screen shows the live camera, not a panel. Some panels have a clip where the keeper slides in the group's own feeding-time card.

At the aquarium	In rendering
the printed tank panel	a prerendered page, shared by every visitor (step 3)
the guidebook writer reading the walls	a crawler reading the first HTML (step 2)
reprinting a panel when the residents change	revalidating when content changes (step 4)
a keeper's talk for each group, queues at the busy hour	server rendering per request, its cost at a peak (step 7)
the audio guide, silent until started	client rendering: a placeholder in the first HTML (step 2)
the live feeding screen	second-by-second data (step 4)
a panel with a clip for the group's own card	a shared shell with a per-request hole (step 6)
a group's name never painted on a panel	personal data never in a shared response (step 5)

In real terms: each display answers who reads it, whether it is shared, and how fresh it must be.

Breaks down when: a reprint costs paint, while a revalidated page regenerates in the background, and a web route can have far more pages than an aquarium has tanks (step 11). Wrong inference: "every page must be printed in advance."

Contrasting case: a museum with only an audio tour and bare walls: a visitor who never starts the device, like a crawler, learns nothing.

4.1 ExamHall: the console that was server-rendered

EXH-1480: to make the proctor console "faster", it was server-rendered on every open. The fixture builds the console both ways; the replies are for proctor Ines in Hall B.

console server per request first HTML: alert text x2 · room name yes · console code in client JS yes
console in the browser     first HTML: alert text x0 · room name no · console code in client JS yes

The server-rendered reply carries each alert twice, once as markup and once in the data the browser needs to hydrate it, and it is built per proctor on every open. The browser still downloads the same console code (step 10). The live feed replaces the snapshot within a second. MR !1680 went back to a client-rendered console behind a small shell. Nobody crawls a signed-in console, so its empty first HTML costs nothing (step 2).

4.2 Proof domain, e-commerce catalog: one product page, three ways

A boot's product page is built three ways; the hole holds the "Hi Ana, 1 item in your basket" greeting. Shoppers Ana and Ben each load it.

product prerendered      shell holds product yes · both replies start with the stored shell yes · Ana's name in Ana's reply no, in Ben's no, in the stored prerender no · cache-control s-maxage=31536000
product per request      shell holds product no · both replies start with the stored shell yes · Ana's name in Ana's reply yes, in Ben's no, in the stored prerender no · cache-control private, no-cache, no-store, max-age=0, must-revalidate
product shell + one hole shell holds product yes · both replies start with the stored shell yes · Ana's name in Ana's reply yes, in Ben's no, in the stored prerender no · cache-control private, no-cache, no-store, max-age=0, must-revalidate

The prerendered page is one copy, stored at build and marked for shared caches, so it can greet nobody (step 5). Rendered per request, the greeting works, but the stored part holds only a fallback, and the product is rendered again on every visit (step 7). The shell with one hole keeps the product in the stored copy everyone gets and renders only the greeting per request (step 6). How Next builds the shell belongs to next-rendering-modes-ppr.