Measured numbers across four surfaces
Twenty-two leaves on this surface: one minute fifty-eight seconds cold build, twenty-six seconds warm build, on the production Docker compose pipeline. Eighty-six leaves on a prior client surface: four minutes twelve seconds cold, fifty-eight seconds warm. Two hundred forty leaves on a separate engagement: nine minutes thirty-one seconds cold, two minutes eighteen seconds warm. Two thousand-leaf synthetic surface (generated for this benchmark): one hour twelve minutes cold. The cold-build curve is linear up to roughly five hundred leaves, then super-linear from the metadata-generation step.
Three knobs that move the curve
One, output mode: standalone is faster than export by roughly fifteen percent on cold builds because it skips the page-data optimization step for runtime cases. Two, MDX versus inline strings: MDX compilation adds about thirty milliseconds per leaf on average, which is invisible at twenty leaves and material at two thousand. Three, parallel page generation: Next.js parallelizes the generateStaticParams output, but the experimental.workerThreads option gates whether that parallelism actually engages on Docker hosts; enabling it cuts our 240-leaf build by twenty-two percent. The Next.js docs on the output option cover the trade-offs.
The cutover to ISR
Past about five hundred leaves, full static regeneration on every deploy stops being economic; a single content change forces a multi-minute rebuild of every leaf. Incremental static regeneration solves this: leaves are generated on first request and cached at the edge until a manual invalidation. The cost is a slower first-request latency for cold leaves (eight hundred milliseconds to one and a half seconds on our benchmarks) and the loss of the perfect-determinism property of static builds. We have shipped ISR on one engagement at three hundred leaves; the cutover was clean.
