What is Prerendering?

What is prerendering?

Prerendering is the technique of generating fully-rendered HTML for specific URLs ahead of time — at build time, on-demand at request time, or scheduled — so when a browser or crawler requests the page it receives ready-to-paint markup instead of an empty SPA shell that needs JavaScript to populate. Prerendering sits between full Server-Side Rendering (SSR, which renders on every request) and pure Client-Side Rendering (CSR, which renders only in the browser). It solves the SEO + first-paint problem of single-page applications without taking on the operational complexity of SSR.

The technique has multiple flavors that get conflated in conversation. Static prerendering (build-time, also called SSG) generates one HTML file per route during the build pipeline — outputs go to a CDN. Dynamic prerendering (request-time, often via services like Prerender.io or Rendertron) detects bot traffic and serves a pre-rendered cache while regular users get the SPA. Hybrid prerendering mixes both — pre-render the most-visited routes statically, fall back to SSR or CSR for long-tail routes.

The three prerendering strategies

1. Static prerendering / SSG (build time)

Generate HTML for every route during deployment. Tools: Next.js getStaticProps, Gatsby, Astro, SvelteKit's static adapter, Nuxt's static generate. Best for content that doesn't change per-request: marketing pages, blogs, docs, e-commerce category listings. Limitation: rebuild required for content changes.

2. Dynamic prerendering (request-time, bot-targeted)

Server detects User-Agent (Googlebot, Bingbot, social crawlers) and routes them to a headless-Chrome-rendered cache. Regular users still get the SPA. Tools: Prerender.io, Rendertron, custom Puppeteer + cache. Best for: legacy SPAs you can't refactor to SSR, but need SEO. Limitation: violates Google's preference for parity (humans vs. crawlers should see the same content).

3. Incremental Static Regeneration (ISR)

Hybrid: pages are static but regenerate in the background after a TTL or on-demand. Next.js, Astro, and Nuxt 3 support this. Best for: content that changes occasionally (product pages, news articles, listings). Combines SSG speed with SSR freshness.

Prerendering vs. SSR vs. CSR — when to use which

Why prerendering matters for performance + SEO

• Faster TTFB / LCP. Prerendered HTML hits the browser ready to paint. No JS download + execute + fetch + render cycle.
• Better Core Web Vitals scores. LCP measures the largest above-fold paint. Prerendered content usually paints faster than SPA-mounted content. Direct ranking-signal benefit.
• Crawlable HTML. Search engines parse content from the initial HTML, not after JavaScript executes. Removes the rendering-bottleneck risk in Googlebot's two-pass crawl.
• Cache-friendly. Static HTML caches anywhere — CDN edges, browser, intermediate proxies. SSR responses are usually per-user, can't cache as aggressively.
• Offline-friendly. Prerendered pages can be cached by service workers for offline access.

Common prerendering mistakes

• Prerendering personalized content. User-specific data (name, prefs, cart) shouldn't be in the static HTML. Hydrate it client-side after mount.
• Stale prerendered content. If your TTL is too long, users see outdated info. Tune ISR / cache-control aggressively.
• Cloaking via dynamic prerendering. Serving Googlebot a fully-rendered version while users get a slow shell can violate Google's cloaking guidelines if the content differs.
• Hydration mismatches. Prerendered HTML and client-side render must match exactly, or React/Vue throws warnings + re-renders. Check for non-deterministic content (Date, random IDs, locale-specific formatting).
• Build-time bloat. Static-prerendering 100,000 routes can take hours. Use ISR for the long tail; static for the top 5,000.
• Forgetting metadata. Prerendering should populate title, meta description, og:image, JSON-LD — not just body content.

FAQ: Prerendering

Is prerendering the same as SSR?

No. SSR renders on every request (server-side), prerendering renders ahead of time (build or scheduled). Both produce HTML for the browser, but with different caching + freshness tradeoffs.

Does Google still need prerendering in 2026?

Less than before — Googlebot now executes JavaScript. But: rendering is the bottleneck stage of Google's crawl; prerendered HTML gets indexed faster and more reliably. Other crawlers (Bingbot, social media, LLM training scrapers) handle JS less well, so prerendering still pays off.

What's the difference between prerendering and static site generation (SSG)?

SSG is one form of prerendering — specifically the build-time variant. Prerendering is the broader concept that also covers dynamic and incremental approaches.

Should I use Prerender.io or rebuild with SSG?

Prerender.io is a stopgap for legacy SPAs that can't be refactored. If you can rebuild on Next.js, Astro, or SvelteKit with their native SSG/ISR, that's almost always the better long-term answer.

How does prerendering affect deploy time?

For SSG with thousands of routes, build time can balloon (hours). Strategies: parallel builds, cache build artifacts, ISR for the long tail (only build top routes statically + regenerate the rest on demand).

Can I prerender authenticated pages?

Don't — auth state is per-user, and serving the same static HTML to all users leaks information or breaks personalization. Use SSR or CSR for auth-gated content.

How LoadFocus relates to prerendering

Prerendering improves LCP and TTFB, but the gains only show up if your CDN + caching setup serves the prerendered HTML correctly. LoadFocus website speed testing validates that prerendered routes actually hit Core Web Vitals targets (LCP ≤2.5s, INP ≤200ms, CLS ≤0.1) in production. Load testing validates that the regeneration workflow (ISR, dynamic prerender) holds up under traffic — common failure mode is the regenerator getting overloaded during cache-stampede scenarios.