An e-commerce Next.js App Router app serves 50,000 product pages from a /products/[slug] route. How do you decide whether to prerender all of them at build time, and what are your options when a full build takes too long?

## What generateStaticParams actually controls A dynamic segment such as `app/products/[slug]/page.tsx` matches an unbounded set of URLs, so Next.js cannot know at build time which pages to produce unless you tell it. `generateStaticParams` is that instruction: an exported async function returning an array of param objects, each of which becomes a page rendered during the build. ```tsx // app/products/[slug]/page.tsx export async function generateStaticParams() { const slugs = await getTopSellingSlugs(500) return slugs.map((slug: string) => ({ slug })) } export default async function ProductPage({ params, }: { params: Promise<{ slug: string }> }) { const { slug } = await params const product = await getProduct(slug) return <ProductView product={product} /> } ``` Everything about the decision follows from one fact: **the size of that array is the size of your build.** Fifty thousand entries means fifty thousand renders, each with whatever upstream calls the page makes, on every deploy. ## The three positions on the dial **Build everything.** Return all slugs. Every product page is a stored file from the first request, so there is no cold-start penalty anywhere and traffic is uniformly cheap to serve. The cost is deploy latency and build-time load on whatever backend serves the product data. This is the right answer when the catalogue is bounded and the build fits comfortably in your release cadence — a hotfix that has to wait out a forty-minute build is an incident-response problem, not just an inconvenience. **Build a hot subset.** Return the slugs that matter: top sellers, recently updated items, whatever your analytics say covers most traffic. Slugs not in the list are not built; the first request for one renders it on demand and it is cached for subsequent visitors. Long-tail products therefore have a slower first hit and are fast afterwards. Given how skewed e-commerce traffic usually is, a few hundred prerendered pages can cover the large majority of requests while the build stays measured in minutes. **Build nothing.** Return an empty array. Nothing is prerendered and every page fills in on first request. This suits a catalogue that changes faster than you deploy, or one whose slug list is not cheaply enumerable at build time. You keep on-demand caching benefits without letting the build depend on catalogue size at all. ## The knob that changes the meaning of "not listed" By default, params outside the returned list are still rendered on demand. Exporting `dynamicParams` as `false` inverts that: the returned list becomes exhaustive and any other slug produces a 404. That is what you want when the URL space genuinely is closed — a fixed set of landing pages, a finished archive — and it is a foot-gun on a live catalogue, because a product added after the last deploy would 404 instead of rendering. ## How to actually decide Run the numbers rather than the intuition. 1. **Measure one page's build cost.** Render time plus upstream latency, times the number of pages, divided by build parallelism, is your build-time estimate. If that number is inside your acceptable deploy window with headroom, building everything is the simplest system and you should take it. 2. **Look at the traffic distribution.** If 300 SKUs cover 80% of page views, a hot subset gives you nearly all the benefit for under 1% of the build. 3. **Measure the cold path.** The first request for an unbuilt slug costs a render plus its upstream calls. If that is 200 ms it is a non-issue; if the product query takes two seconds, fix the query before you decide anything about rendering. 4. **Check catalogue churn.** If products are added hourly, a build-everything strategy is pinned to your deploy cadence and new items are invisible until the next release, which usually forces a subset or on-demand approach with an invalidation path for updates. ## The failure modes to name The two bad outcomes are worth stating explicitly in an interview. **Build explosion**: nobody notices until deploys creep past the point where the team stops deploying, and the fix is retroactive and disruptive. **Cold long tail**: crawler traffic and deep links hit unbuilt pages, so your synthetic monitoring on the homepage looks perfect while real users on product pages see the slow path. Both are measurable in advance, which is exactly why the interviewer is asking rather than accepting "prerender everything".