Skip to content

CONCEPT Cited by 1 source

Build time scales with page count

Pathology

When a static-site / SSG tool pre-renders every page listed in the enumerator (Next.js's generateStaticParams(), Gatsby's createPages, etc.) during the build, build time scales linearly with page count. A site with 10,000 product pages costs 10,000 renders; 100,000 product pages cost 100,000. "This is why large Next.js sites end up with 30-minute builds." (Source: vinext launch)

Why it's a problem

  • Deploy latency — 30-minute builds make every fix a 30-minute rollout.
  • Wasted work — for most content sites, the vast majority of those pre-rendered pages receive zero or near-zero traffic until they expire and must be re-rendered next deploy.
  • Build↔production coupling — generateStaticParams() typically pulls the full page list from the production database, coupling build infrastructure to production data (auth, permissions, data-residency, staging parity concerns).

How the problem is typically worked around

  • Hybrid rendering modes — pre-render some pages, SSR others, cache via ISR. Still requires enumerating which pages to pre-render.
  • On-demand ISR — don't pre-render anything; let the cache warm up from live traffic. Trades build time for cache-miss latency on the first hit to each URL.
  • Sampling the enumerator — pre-render a subset, but the subset choice has no traffic-grounded signal.

TPR resolves this

vinext's TPR exploits power-law URL traffic to pre-render only the URLs that actually receive traffic, cutting a 100,000-page build to rendering ~184 pages ("50 to 200" per the post) while still covering ~90 % of user traffic with warm cache on first request.

Seen in

Last updated · 200 distilled / 1,178 read