Static Generation at Request Time in Next.js

The common way to implement SSG in Next.js is to generate every page up front, during the build. Generating a page the first time someone actually requests it is another option: nothing pre-builds, and Next.js caches each page after its first visit, the same as any other static route. I used this to remove RudderStack's 3,500-page integration catalog from its build at Bejamas, cutting a 40-minute deploy to about 3 minutes.

How does Next.js decide when a static page gets built?

The common way to implement SSG is to generate every page up front, during the build (Next.js docs, all paths at runtime). That works well until the page count gets large enough that the waiting time for the build itself becomes the cost.

What happens if generateStaticParams returns an empty array?

Every path gets generated the first time someone requests it, and nothing is prerendered during the build. Next.js’ own wording for the App Router: “To statically render all paths the first time they’re visited, return an empty array (no paths will be rendered at build time)” (Next.js docs, all paths at runtime). It is a two-line change in the route:

// app/integrations/[slug]/page.js
export async function generateStaticParams() {
  return [];
}

The empty array is required. If the function returns nothing or is removed, the route renders dynamically on each request. The Next.js docs say generateStaticParams must return an array, even when it is empty.

What has to be true for this to work?

Check these four conditions before moving a large route.

• Router and version. This is App Router behaviour, as documented on the generateStaticParams reference page for Next.js 16 (page last updated 25 August 2026). The Pages Router has its own API for on-demand generation, getStaticPaths with a fallback option, and its semantics are not the same - do not port the reasoning across.
• Un-generated paths are allowed through. The dynamicParams segment config decides what happens when a visitor hits a dynamic segment that generateStaticParams did not return, and it defaults to true (Next.js route segment config). Set it to false and those paths 404, at which point an empty array means the route serves nothing at all. Note also that Next.js 16 removes this option, and the rest of the segment config, when Cache Components is enabled.
• You have a way to invalidate a page. Nothing rebuilds on its own. A CMS webhook calling revalidatePath for the changed page is what turns “cached forever” into “current” - without it, the first render is the last one until the next deploy.
• Your host keeps the cache. The deployment platform decides how long a generated page stays cached and whether it survives a deploy. Check the host’s documentation before assuming a page renders once.

What’s the tradeoff of generating pages on demand?

The cost moves from the build to the first request for each page.

• Pro: editors publish in the CMS and see it live in seconds - no need to wait for the build to complete.
• Con: the first visitor to a page that has not been generated waits for it to render. On a catalog where most pages get little traffic, many visitors can hit that slower first request.
• Con: hosting costs get less predictable because cache reads and writes replace a fixed build.

Choose based on page count, update frequency, traffic to less visited pages and build time.

What did this change for a real deploy?

At Bejamas, I worked on RudderStack’s marketing site, with an integration catalog of 3,500+ pages - one page per platform pairing, the kind of programmatically generated content every dev tool site accumulates. Every deploy rebuilt all 3,500+ of them, and the whole thing was taking about 40 minutes. Moving those pages to request-time generation took them out of the build entirely, and the deploy dropped to about 3 minutes.