Skip to content

CONCEPT Cited by 1 source

Traffic-aware Pre-Rendering

Definition

Traffic-aware Pre-Rendering (TPR) is a deploy-time pre-rendering strategy that uses edge analytics — the CDN's record of which URLs have actually been requested — to decide which pages to render ahead of time. Pre-render only the URLs that receive real traffic; everything else falls back to on-demand SSR + ISR.

Introduced by Cloudflare in vinext (2026-02-24) as vinext deploy --experimental-tpr.

Problem TPR resolves

Traditional pre-rendering (Next.js's generateStaticParams()) enumerates every page to render at build time — a 10,000-product-page e-commerce site means 10,000 renders, even though the vast majority of those URLs may never receive a request. Build time scales linearly with page count — "this is why large Next.js sites end up with 30-minute builds." See concepts/build-time-scales-with-page-count.

How TPR exploits traffic shape

Real-world URL traffic follows a power law: a tiny fraction of URLs collects the overwhelming majority of requests. Per the 2026-02-24 post: "a site with 100,000 product pages, the power law means 90 % of traffic usually goes to 50 to 200 pages." Pre-rendering those 50-200 is cheap; pre-rendering the remaining 99,800 is wasted build time.

Deploy flow

  1. Developer runs vinext deploy --experimental-tpr.
  2. vinext queries Cloudflare zone analytics for the last 24 h of traffic.
  3. Rank URLs by request count; pick the top-N covering 90 % of traffic.
  4. Pre-render those pages to KV / the cache substrate.
  5. Deploy the Worker.
  6. Unmapped URLs render on demand via SSR + cache via ISR after first request.

Example deploy log from the post:

TPR: 12,847 unique paths — 184 pages cover 90% of traffic
TPR: Pre-rendering 184 pages...
TPR: Pre-rendered 184 pages in 8.3s → KV cache

Why this is a CDN-exclusive capability

TPR requires existing traffic data for the deploying site. A CDN that proxies the site already has this as a side effect of being in the request path; an offline build tool has no way to produce it without coupling the build to the production database or a separate analytics backend. "Cloudflare is already the reverse proxy for your site. We have your traffic data." See systems/cloudflare-workers for the platform position.

What TPR automatically captures

  • Pages that go viral between deploys get picked up on the next deploy (they show up in the traffic data).
  • Set refreshes on every deploy without developer action — no generateStaticParams() edits needed.
  • Works without generateStaticParams() entirely.
  • Decouples build from the production database.

Caveats

  • Experimental flag --experimental-tpr; "we plan to make it the default once we have more real-world testing behind it."
  • Cloudflare-specific; depends on zone analytics. Other CDNs could implement the same idea but it isn't a portable concept.
  • First deploy bootstrap: a brand-new site has no traffic data. ISR fills in over time; first deploy is effectively a cold start for pre-rendering.
  • Doesn't address the static-only site case where 100 % of HTML is pre-built. Post recommends Astro for that workload.
  • Time-varying traffic: if traffic distribution changes between deploys (a new campaign page goes viral), the first requests are cache-misses rendered on demand.

Seen in

Last updated · 200 distilled / 1,178 read