Prerendering

How it works in practice

A build script starts the app in a headless browser, visits every route in a list, waits for the view to settle, and writes the resulting DOM to dist/<route>/index.html. The deployed site then contains one real HTML file per page. A visitor gets readable content on the first byte, and the JavaScript bundle still loads afterwards to make the page interactive — the hydration step.

The reason to bother is that not every consumer of your pages runs JavaScript. Google does, with a delay and a rendering budget. Bing is inconsistent. Most LLM crawlers, link preview bots and scrapers simply read the HTML they are given. For those, an unrendered single-page application has no content at all.

Prerendering, SSR and SSG are not the same thing

The words are used loosely, so it is worth pinning them down:

• Prerendering happens once, at build time, and produces static files. Content is as fresh as your last deploy.
• Server-side rendering (SSR) happens per request, on a server, so the HTML can be personalised or up to date. It costs a running server.
• Static site generation (SSG) is essentially prerendering as the primary architecture rather than a bolt-on to an existing client app.

There is also a second, unrelated meaning: browsers use "prerender" for speculatively loading a page the user is likely to visit next. Same word, different subject — context usually makes it obvious which one is meant.

What to watch out for

Prerendering only covers the routes you list, so a new page that nobody added to the list ships as an empty shell. Anything personalised must not be captured in the snapshot — prerendering a logged-in view bakes one user's data into a public file. And the prerendered HTML and the client render need to agree, because if they differ the page will visibly flicker as the app replaces the markup.