Technology
Pre-rendering technology - how it works under the hood
Use this hub when the real question is architectural, not editorial and not vendor-specific. The team is usually trying to answer one of four things: whether pre-rendering or SSR is the right model, what pre-rendering actually adds to the stack, where cache and invalidation fit, or whether the ownership burden belongs in-house at all.
Pre-rendering is not a frontend framework. It is a crawler-facing rendering layer that sits beside the live app. A headless browser pool captures HTML snapshots, a cache serves them to crawlers, and routing rules decide who sees what. That separation is why it can fix acquisition surfaces, large catalogs, and JavaScript-heavy public content without forcing a full framework rebuild.
Start with dynamic rendering vs SSR if the architecture itself is still undecided. Move to guides when the model is clear but the operational bottleneck is crawl waste, stale snapshots, or render cost. Move to compare once the team is already shortlisting vendors or build paths.
15-minute quick start
import { NextResponse } from "next/server";import type { NextRequest } from "next/server";const BOT_REGEX = /bot|crawler|spider|googlebot|bingbot/i;export function middleware(req: NextRequest) { const ua = req.headers.get("user-agent") ?? ""; if (!BOT_REGEX.test(ua)) return NextResponse.next(); return NextResponse.rewrite( new URL( `https://render.ostr.io/render?url=${encodeURIComponent(req.nextUrl.toString())}`, ), );}- Avg. organic traffic increase
- 340%
- Indexing time (from weeks)
- < 2hrs
- Engineering teams served
- 200+
- Crawlability score achieved
- 99.9%
Definition
Empty DOM vs full HTML — drag to compare
The handle reveals what Googlebot fetches today on a CSR-only site versus the same URL after pre-rendering. The difference is what makes JavaScript SEO either work or quietly fail.
<!DOCTYPE html>
<html>
<head>
<title>Loading…</title>
</head>
<body>
<div id="root"></div>
<!-- Empty DOM. -->
<script src="/app.js"></script>
</body>
</html>Drag the handle · ← → arrow keys · Home/End to jump to edges
Five stages from crawler request to cached snapshot
Each stage is independently scalable. Most teams customise stages 2 (cache TTL) and 5 (invalidation) for their content cadence.
Stage 1 of 5
1. Crawler detection at the edge
A middleware layer inspects User-Agent on every request. Bots are routed to the snapshot cache; users continue to the live SPA. The detection runs in ~1ms at the edge with zero impact on user latency. If you are still comparing this architecture to a framework-bound model, read dynamic rendering vs SSR.
Stage 2 of 5
2. Snapshot cache lookup
If a cached HTML snapshot exists for the requested URL and is within its TTL window, it returns immediately. Otherwise the request is queued for rendering. The TTL and freshness policy is the same layer covered in pre-render cache headers.
Stage 3 of 5
3. Headless Chrome render pool
A dedicated pool of headless Chrome instances loads the URL, waits for the data-ready signal, and serialises the DOM to HTML. Typical render time is 1-3 seconds. If you need the cost model behind that stage, go to JavaScript rendering cost.
Stage 4 of 5
4. Snapshot storage + edge distribution
The serialised HTML is stored in an edge-distributed cache (regionally replicated) so subsequent bot requests from any geography hit the closest edge node with ~10-50ms TTFB. Teams deciding whether to own this stack themselves should compare the trade-off in ostr.io vs Cloudflare.
Stage 5 of 5
5. Invalidation on content change
CMS updates, price changes, or inventory changes fire a purge against the affected URL set. Batch purge supports up to 10,000 URLs per call, so large publishers can re-snapshot at scale without overrunning the render pool. This is where large sites with 100k+ URLs stop being theory and become an operations problem.
Stage 1 of 5
1. Crawler detection at the edge
A middleware layer inspects User-Agent on every request. Bots are routed to the snapshot cache; users continue to the live SPA. The detection runs in ~1ms at the edge with zero impact on user latency. If you are still comparing this architecture to a framework-bound model, read dynamic rendering vs SSR.
Stage 2 of 5
2. Snapshot cache lookup
If a cached HTML snapshot exists for the requested URL and is within its TTL window, it returns immediately. Otherwise the request is queued for rendering. The TTL and freshness policy is the same layer covered in pre-render cache headers.
Stage 3 of 5
3. Headless Chrome render pool
A dedicated pool of headless Chrome instances loads the URL, waits for the data-ready signal, and serialises the DOM to HTML. Typical render time is 1-3 seconds. If you need the cost model behind that stage, go to JavaScript rendering cost.
Stage 4 of 5
4. Snapshot storage + edge distribution
The serialised HTML is stored in an edge-distributed cache (regionally replicated) so subsequent bot requests from any geography hit the closest edge node with ~10-50ms TTFB. Teams deciding whether to own this stack themselves should compare the trade-off in ostr.io vs Cloudflare.
Stage 5 of 5
5. Invalidation on content change
CMS updates, price changes, or inventory changes fire a purge against the affected URL set. Batch purge supports up to 10,000 URLs per call, so large publishers can re-snapshot at scale without overrunning the render pool. This is where large sites with 100k+ URLs stop being theory and become an operations problem.
Tap a stage to learn more · Tab to navigate · Enter to select
Paste any URL — see the snapshot diff in real time
Mock preview today; production will proxy through render.ostr.io. The example responses show the kinds of indexable content gaps prerendering closes.
Mock preview · production will proxy through render.ostr.io
Deep dives inside this hub
Dynamic rendering vs SSR
Start here if the team still needs the architecture decision: when pre-rendering wins, when SSR wins, what hybrid models look like, and where each approach becomes the wrong fit.
Guides
Go here when the architecture is already plausible and the real bottleneck is operational: crawl-budget waste, stale cache, weak recrawl, render cost, or parity drift.
Use cases
Choose this path when the same rendering model needs to be translated into vertical rules for SaaS docs, ecommerce facets, stale listings, bookings, or route fanout.
Compare vendors
Move here once the architecture and failure mode are clear and the team is choosing between managed services, framework-bound alternatives, or build-your-own ownership.
Questions engineers ask before shipping
Yes. Google's developer docs explicitly name dynamic rendering and pre-rendering as acceptable patterns for JavaScript-heavy sites, provided the pre-rendered HTML substantially matches the hydrated page.
SSR rebuilds HTML on every request from the framework runtime. Pre-rendering generates snapshots ahead of time and serves them from an edge cache. Pre-rendering is cheaper per request and scales independently of framework CPU.
No. Users never see the pre-rendered HTML. They get the live SPA and hydrate as usual. Only bots receive the snapshot, so hydration mismatches cannot surface to real users.
~1ms at the edge for the UA check. Snapshot lookup adds another ~10-50ms if the cache hits. On a cache miss for a bot request, the render pool takes 1-3s — still much faster than the Googlebot render queue's 4-48h wait.
Pre-rendering is designed for the public crawlable surface. Authenticated pages should remain behind login and be excluded from the crawler routing rule. Attempting to pre-render authenticated pages is also a security anti-pattern.
Any framework that produces a hydratable DOM: React, Vue, Angular, Svelte, Next.js, Nuxt, SvelteKit, Ember, Lit, and vanilla SPA. It operates at the HTTP layer, so it is framework-agnostic by design.
Add the middleware snippet (shown above) to your edge runtime, point the render target at ostr.io (or your own render pool), deploy. The middleware intercepts bot traffic and sends it to the snapshot cache. No frontend changes required.
Editorial trust
Written by ostr.io engineering team · Engineering Team. We build and run pre-rendering infrastructure for more than 200 engineering teams, which is where the numbers and code samples on this page come from.
Last updated . Editorial scope and review policy: About prerender.info.