In a meta-framework, what does prerendering a route at build time mean, and what happens when a visitor requests it?
answer
- rendered once, served many times
- the build runs the data loading
- a request is a file read
- data is a snapshot from build time
- chosen per route, not per app
basics
~20 sPrerendering 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.
solid answer
~50 sA prerendered route is rendered while the project builds, not while a user waits. The build runs the route's data loading against the data source as it stands at that moment, renders the markup to an HTML string, and emits it as a file in the build output alongside the `js` and `css` that page needs. After that, a request is essentially a file read: no route code runs per request, so the response is cheap and a CDN in front of it can absorb the traffic without touching the origin. Because every visitor receives the same bytes, nothing per-user can be baked in, and the data in the page is a snapshot taken at build time. It is normally a per-route decision, so an app can prerender its marketing and documentation routes and still deploy a server for the rest.
go deeper
Be able to state the two phases out loud: the render happens during the build, the request only reads the resulting file. Say what every visitor receives and why they all receive the same bytes.
Explain where the data comes from and the exact moment it freezes, and that the mode is picked per route. Contrast the per-request cost of build-time and per-request rendering concretely.
Show that you weigh which route families tolerate build-frozen data, and that you know the serving path afterwards is a plain file a CDN can hold without ever reaching the origin.
Frame it as a cost and publishing decision: per-request render cost and origin capacity traded against build duration, and against the fact that publishing a correction now means running a deploy.
**Build-time prerendering** — often called *static generation* — means the HTML for a route is produced once, while the project is being built, and that finished HTML is what users are served afterwards. It is one of the render modes a meta-framework offers, and in most of them it is chosen per route rather than for the whole application. ## What the build actually does For each route the build decides can be rendered without a request, it performs three steps: 1. **Run the route's data loading.** Whatever the route would normally ask for at request time — a query against a database, a call to a content service, reading files from a content directory — runs now, against the data as it stands during the build. 2. **Render to a string.** The component tree is executed on the build machine and serialised to HTML, exactly as a server would do it for a request, except that there is no request: there are no incoming headers, no cookies, no session, no client IP. 3. **Write the output.** The HTML is written into the build output as a file, together with the JavaScript, CSS and any serialised data the page will need once it reaches the browser. The important consequence of step 2 is that a route which genuinely needs request-bound input cannot be prerendered at all: there is nothing to read it from. Frameworks differ in how strictly they enforce that — some fail the build, some quietly fall back to rendering the route per request — but the constraint itself is universal. ## What a request costs afterwards Once the build has emitted the file, serving it is a file lookup: - no data source is consulted, no application code executes for that request; - time-to-first-byte is dominated by the file read and the network, not by your slowest query; - the bytes are identical for every visitor, which is exactly what makes the response shareable in a cache; - load on the origin stops scaling with traffic — ten thousand views cost what one view costs, minus the bandwidth. The page can still do work in the browser after it arrives — take over the markup, fetch something per-user, and so on. That client-side half is a separate decision from how the HTML was produced. ## Build time versus request time, side by side | | Rendered at build | Rendered per request | |---|---|---| | When data is read | Once, during the build | On every request | | Freshness | As of the last build | As of the request | | Per-user content | Not possible in the HTML | Possible | | Cost per view | A file read | A render plus its data fetches | | What a traffic spike costs | Bandwidth | Origin capacity | | What publishing a change requires | A new build and deploy | Nothing — the next request sees it | ## Where the data freezes The subtle part for newcomers is *when* the data in the page was true. A prerendered page is a photograph of the data source at build time. If an article is edited an hour after the build, the deployed file still contains the old text until something produces a new file. Within this mode, that something is another build and deploy; meta-frameworks also offer separate modes that refresh a prerendered page out of band, but those are a different mechanism, not a property of build-time prerendering itself. This is why the mode suits content whose change cadence is close to the deploy cadence — marketing pages, documentation, changelogs, reference data, published articles — and suits per-user or fast-moving data badly. ## What it is not - It is **not** all-or-nothing. Most meta-frameworks let one route prerender while the route next to it renders per request, in the same deployment. - It is **not** the same as caching a rendered response. A cache is filled by a request and expires; a prerendered file exists before any request and lives until the next deploy replaces it. - It is **not** a promise that no JavaScript ships. How much script the page needs to become interactive is an independent choice. - It is **not** limited to routes with fixed paths. A route with a dynamic segment can be prerendered too, provided the build is told which concrete paths to produce. ## Why interviewers ask it It is the cheapest way to find out whether a candidate can separate *when* HTML is produced from *when* it is requested. Someone who can state the two phases, name what freezes in between, and say what a request costs afterwards has the mental model the rest of the render modes build on.
- Can a route that reads a cookie or a request header be prerendered at build time?No. During the build there is no request, so there is nothing to read those values from. A route that depends on request-bound input has to render per request, or read that input in the browser after a prerendered shell has loaded.
- Does prerendering a route mean the page ships without JavaScript?No — those are independent choices. Prerendering decides when the HTML is produced; how much script is shipped to make the page interactive is decided separately, and ranges from a full client takeover to none at all.
- How is a prerendered file different from a cached server response?A cached response is created by the first request that misses, has a lifetime, and can be evicted; until it is filled, someone pays the full render. A prerendered file exists before any traffic, is part of the deployed artifact, and is replaced by the next deploy rather than expiring.
It is printing a poster rather than writing the notice out for each passer-by: the print run is the expensive part, every reader gets the identical sheet, and correcting a typo means printing again.
saying these in an interview costs you the question
- Thinks the HTML is produced by the first visitor's request rather than by the build
- Says a prerendered page re-reads its data source on every visit
- Assumes prerendering is an all-or-nothing choice for the whole application
- Expects per-user content inside a file every visitor receives byte for byte
- Confuses prerendering with shipping no JavaScript at all
- Believes a prerendered route can read request headers or cookies while building