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 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). As the page count grows, generating every page can slow deployments.

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). The route returns an empty array:

// 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?

Before changing a route, check the router, cache and publishing setup.

• 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 uses getStaticPaths with a fallback option, which behaves differently.
• 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. A CMS webhook can call revalidatePath for the changed page. Without invalidation, the cached page stays unchanged 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.

• Publishing: editors can see changes in seconds without waiting for a full build.
• First visit: the first visitor to an ungenerated page waits for it to render. On a catalog where most pages get little traffic, many visitors can hit that slower first request.
• Hosting: costs become 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. Its integration catalog had more than 3,500 pages, one per platform pairing. Rebuilding them on every deploy took about 40 minutes. I moved those pages to request-time generation, which cut the deploy to about 3 minutes.