PATTERN Cited by 1 source
Traffic-aware pre-rendering¶
Pattern¶
Instead of pre-rendering every page (Next.js's
generateStaticParams()) or none (pure SSR), query the
CDN's traffic record at deploy time and pre-render only
the URLs that actually receive traffic. Everything else
falls back to on-demand SSR + ISR caching after the first
request.
Forces that motivate the pattern¶
- Build time scales linearly with page count — big sites (100 k+ products, many CMS pages) produce 30-minute builds (concepts/build-time-scales-with-page-count).
- URL traffic is power-law-distributed — a tiny fraction of URLs covers the majority of traffic (concepts/power-law-url-traffic).
- Build-time enumeration requires either an explicit list
(
generateStaticParams()) or production-database access — both have operational costs. - CDNs already see traffic as a side effect of proxying. The data is free to the CDN, expensive or impossible to produce offline.
Solution shape¶
- At
deploytime, framework queries CDN analytics for the last 24 h of traffic. - Rank URLs by request count.
- Pick the top-N covering ~90 % of traffic.
- Pre-render those N pages into the cache substrate (KV / R2 / …).
- Deploy.
- Un-pre-rendered URLs render on demand via SSR; result is cached via ISR on first hit.
Every new deploy refreshes the pre-rendered set from the most recent traffic distribution. Viral pages get picked up automatically on the next deploy.
Consequences¶
- Build time collapses from O(page-count) to O(traffic- head). 100 k pages → ~184 pages pre-rendered (per the vinext post's example).
- Decouples build from production database — no
generateStaticParams()query needed. - Cache miss on first request to a cold URL (ISR fills in afterwards).
- First deploy has no traffic data — cold-start problem until enough ISR cache warms up.
- Specific to CDN-hosted frameworks — requires zone analytics access.
- Pre-rendered set drifts from real-time traffic — between deploys, newly hot URLs pay the on-demand cost on first request.
Canonical wiki instance¶
vinext's vinext deploy --experimental-tpr
is the canonical wiki instance of this pattern, introduced in
the 2026-02-24 launch post.
Seen in¶
- sources/2026-02-24-cloudflare-how-we-rebuilt-nextjs-with-ai-in-one-week — canonical wiki instance.
Related¶
- concepts/traffic-aware-prerendering — the concept form.
- concepts/power-law-url-traffic — the traffic-shape observation.
- concepts/build-time-scales-with-page-count — the pathology.
- concepts/incremental-static-regeneration — the fallback mechanism.
- concepts/cloudflare-zone-analytics — the data substrate.
- systems/vinext — the implementation.
- systems/cloudflare-workers — the platform.