What is Prerendering?

What is prerendering?

Prerendering means generating the finished HTML of a page ahead of the request, usually at build time, so a browser or crawler receives ready-to-read markup instead of an empty JavaScript shell. It gives a single-page app better first paint and indexable content without rendering on every request. In this entry the word means that build-time sense; it is a close cousin of static site generation and sits between client-side rendering and server-side rendering. See rendering for the full spectrum.

How it works

A build step runs your app for a list of routes, waits for the content to appear, and saves the resulting HTML for each URL. A CDN serves those files. In the browser, the page paints immediately and the JavaScript then takes over through hydration. If a route's content changes often, incremental static regeneration rebuilds pages after a set time or on demand instead of on every deploy.

Flavours and when to use them

• Build-time prerendering. One HTML file per route, produced during the build. Best for marketing pages, blogs and docs. Limit: content changes need a rebuild.
• Regeneration. Pages are static but refreshed after a time limit or on demand. Best for catalogues and articles that change occasionally.
• Dynamic prerendering. A service renders pages for crawlers while people get the normal app. Google calls dynamic rendering a workaround, not a recommended solution, and recommends server-side rendering, static rendering or hydration instead. It does not generally treat it as cloaking as long as crawlers and users get similar content.

The other meaning: browser prerendering

In the browser, a prerender rule in the Speculation Rules API tells a supporting browser to load and run a likely next page in a hidden tab so navigation feels instant. That is a different technique with a different goal, described in prefetch for resources and speculative loading. MDN notes it is same-origin by default and unsafe for pages whose server actions have side effects, such as sign-out or add-to-cart.

Why it matters for performance and SEO

• Faster first paint. The browser gets markup it can paint without waiting for JavaScript to fetch and render content, which usually helps Largest Contentful Paint.
• Crawlable content. Search engines can read the content from the first HTML response.
• Cheap to serve. Static files cache well on a CDN and cost little per request.

Common mistakes

• Baking personal data into the HTML. Names, carts and preferences belong in client-side code after load, never in a page shared by all users.
• Stale pages. A long cache time or a missing rebuild leaves users with old content.
• Hydration mismatches. Dates, random ids or locale formatting that differ between build and browser cause warnings and re-renders.
• Missing metadata. Title, description, canonical and structured data must be in the prerendered HTML too.
• Prerendering logged-in pages. Use server or client rendering for anything per user.

Testing prerendered pages

Check the page the way users get it: through your CDN, from several regions, with caching on. LoadFocus page speed monitoring runs scheduled Lighthouse audits and tracks Largest Contentful Paint and other Core Web Vitals over time. If you regenerate pages on demand, a load test shows whether that endpoint holds up under traffic. More in load testing single-page applications.

FAQ: Prerendering

Is prerendering the same as SSR?

No. SSR renders on each request, while prerendering renders ahead of time, at build or on a schedule. Both send HTML to the browser, but freshness and caching differ.

Is prerendering the same as static site generation?

Build-time prerendering and static site generation are nearly the same thing. The term prerendering is also used for dynamic services and for the browser feature, so check which one a source means.

Does Google still need prerendering?

Google can run JavaScript, but sending finished HTML is simpler and more reliable, and other crawlers may handle JavaScript less well. Google recommends server-side or static rendering over dynamic rendering for new work.

Can I prerender pages for logged-in users?

No. Content that differs per user should not be baked into shared HTML. Render it on the server per request or on the client after load.