Render Modes & Activation

Prerendering at build time runs a route's data loading and render once, during the build, and writes the finished HTML into the build output. Every visitor is then served that same file, with no per-request fetch or render.

Hydration is a server-rendered route's second delivery: after the finished HTML paints, the browser downloads the component code and the data the server rendered with, then attaches behaviour to the existing markup instead of rebuilding it.

The browser receives a finished document: the framework matched the URL, ran that route's server-side data work and rendered markup before replying. Content is visible in the first paint, and machines that never run scripts can read it.

Input that arrives with the HTTP request and differs between callers: the cookie jar, request headers, the query string, the caller's address. Reading a database, a config value or a path parameter does not, by itself.

Being stale marks a copy as due for refresh; it does not withhold it. The request is still answered from storage, and the fresh HTML first reaches whoever arrives after the out-of-band render has completed and replaced the copy.

A dynamic segment has no fixed path list, so the route supplies a build-time enumeration step returning the parameter sets to render — usually a query against the data source that fills the pages. The build emits one page per entry.

Scope decides the script budget. Whole-route hydration ships the route's entire component tree; islands ship only the parts declared interactive and leave the rest as inert HTML; a no-script route ships none, so only platform behaviour works.

The response body is the rendered markup, and markup cannot be produced before the values it prints are known. So the request waits for the route's server data work plus render time, and the first byte carries both of those costs.

Inference derives the mode from what the render touched, so a request-bound read silently flips the route and shows up later as cost or staleness. Declaration makes the route state its promise and fails loudly when the render breaks it.

Only the levels that resolve before the shell is flushed — in practice the outermost ones. Status, headers and cookies leave with the first bytes, so a deferred level can change only the markup in its own region.

The shell goes first: the document frame with a placeholder wherever a region is still pending. As each region resolves, its markup is appended to the same open response, with an inline script that moves it into place.

With nothing stored there is no stale copy to serve. Frameworks take one of two routes: hold the request for a first render and store its output, or answer immediately with a placeholder while the render runs out of band.

Three behaviours are on offer: answer 404 because the path was not enumerated; render it on the server on first request and usually keep the output; or return a placeholder shell and fill it from the browser.

Deferring moves takeover work off the window after paint, and can avoid it for parts never seen. It does not shrink what a hydrated component costs, and it widens the period where a control looks ready but is inert.

Every view is its own render: one route match, one set of data reads, one tree rendered to a string, one serialisation. That work is repeated per visitor rather than amortised, so compute, upstream load and concurrency all track traffic almost linearly.

No. A parameterised segment makes the URL shape dynamic, not the render. It can be prerendered once per known value, and becomes per-request only when the render reads request-bound input such as a cookie, header or query string.

The last good copy stays in place, because a failed render is not published. Visitors keep getting fast, valid, steadily older HTML with a success status, so only render telemetry and the age of the stored copy reveal that anything is wrong.

Typically one render per path rather than one per request: implementations keep a single refresh in flight for a path and answer the rest of the burst from the stored copy. Render and data-source load therefore tracks paths refreshed, not traffic.

The deployed page is a file rendered from the data as it stood during the build, and serving it never consults the source. The correction ships when a new build runs and deploys, so publishing needs an automatic rebuild trigger.

Split the per-route build output into the baseline every route pays and what this route adds. Usual causes: whole-route hydration scope, an interactive element dragging its subtree in, or a shared layout that widens scope for every page beneath it.

A shared cache stored one visitor's personalised render and replayed it to everyone matching the same cache key, which is usually method plus URL and ignores the session cookie. Personalised responses must declare themselves uncacheable by shared caches, or vary the key.

You keep the route static, shared-cacheable and cheap. You pay a waterfall after the bundle loads, an element missing from the initial HTML, layout shift or a wrong-state flash, and a new authenticated endpoint.

An unguessable flag on the editor's request is request-bound input: reading it forces a fresh render, tells the data layer to return drafts, and bypasses stored copies. That response must never be storable by a shared cache.

A late chunk that swaps the placeholder for the nearest error fallback, on a response that already reported success. The route's whole-page error screen is unreachable, because replacing the document would mean un-sending bytes the browser has parsed.

Three, and only one is clean: promote the check above the shell flush so the response can still refuse or redirect; render a denial state in that region; or navigate from the client afterwards.

Decide per data source, not per route: which reads are essential to the page and which are decoration. Essential reads justify holding the response to a bounded deadline then failing; optional ones get a short timeout and render without them.

Sort route work by what its result can change. Anything that can change the response itself — status, headers, cookies, destination — resolves before the shell; work that only fills a region may be deferred.

Classify content by the cost of being briefly wrong. Surfaces whose facts tolerate age take the stored copy; prices, availability, permissions and anything personalised do not. The model promises eventual freshness, never current data, so name a worst-case age and measure it.

Treat build duration as a budget with an owner. Prerender families whose content changes on the deploy cadence and whose page count is capped to a valuable slice; move per-user, fast-moving and long-tail families to another mode.