Support for deferred static path resolution at runtime

[TahirMontgomery]

Goals

1. Enable developers to offload expensive getStaticPaths execution to runtime instead of build time
2. Improve build scalability for apps with tens or hundreds of thousands of dynamic pages
3. Allow dynamic generation of static paths while retaining full static performance and caching benefits

Non-Goals

1. Replacing getStaticPaths entirely — this feature should be additive and backwards compatible

Background

In projects where we have a lot of dynamic content, like user profiles, marketplace listings, or blog posts, using getStaticPaths starts to break down at scale. Once you cross a few thousand pages, build times can balloon, sometimes taking 30 minutes to hours. This becomes a major bottleneck for teams that want to keep shipping fast or frequently.

For a SaaS with potentially thousands of pages, we don't need all of those pages pre-rendered at build time, but we do want them eventually static and cached, without having to pay the cold-start penalty of SSR or using fallback for each one.

Right now, there isn’t a great middle ground between building everything upfront with getStaticPaths and handling everything on-demand with SSR. I think there’s an opportunity to give developers more flexibility.

Proposal

The idea is to introduce a new optional function called getAsyncStaticPaths, which works just like getStaticPaths — except it doesn’t run at build time. Instead, it would run when the app boots up, or lazily on the first request to the route.

This lets developers skip the slow build process while still eventually generating all their pages as static files. Those pages could be cached just like any other SSG page, and the paths could be updated periodically behind the scenes (maybe with a revalidate option).

I’d love to help contribute! While I don’t have much experience contributing to large open source projects yet, I’m comfortable with TypeScript and willing to dig in. I’d appreciate guidance or direction from the maintainers if this moves forward, but I’m happy to help however I can

[icyJoseph]

Doesn't returning an empty array in getStaticPaths with fallback set to true, accomplish this?

It means, keep this open for runtime requests. Then within getStaticProps at runtime, you can verify the inputs, make sure content exists and such, and return props which will render a page. You need to handle useRouter().isFallback, and probably want to include revalidate times for not-found and data paths.

• https://nextjs.org/docs/pages/building-your-application/data-fetching/get-static-paths#generating-paths-on-demand

This one uses blocking though, but same idea.

[TahirMontgomery]

Thanks for the reply! You’re right that getStaticPaths with fallback: true allows on-demand generation of individual pages, but that’s not quite what I’m proposing.

The issue isn’t with rendering and caching pages on demand (which is what returning an empty array from getStaticPaths currently does). It’s with having to fetch, render and cache all possible paths at build time, which becomes a bottleneck when you have tens or hundreds of thousands of them.

What I’m suggesting is the ability to defer that path array generation to runtime, and let the system generate ALL those pages in the background (I.e, through a background worker or separate process), proactively, not just one individual page when a user visits.

So it’s not about skipping getStaticPaths, it’s about offloading it from the build step to speed up builds, while still getting the benefits of static pages later.

[icyJoseph]

I see, would instrumentation.ts serve this purpose somehow? On runtime, when ran, you start to fetch with absolute URLs from your application, in batches. If the process exits, you can cancel any ongoing and future work, otherwise continue to generate your pages.

[TahirMontgomery]

Hmm, that’s an interesting idea. That could work but it does feel a bit more like a workaround/hack than a first-class solution. Especially since getStaticPaths is already a core part of the framework, it seems natural to extend it with native support for runtime generation.

[icyJoseph]

Yeah, well, I'd say, another way is to render in getStaticPaths, the pages that are most visited, or rather, the smallest sub-set that yields, say 70% of your readers ~ then pre-fetching will take care of the rest. As soon as an un-generated page, comes into the viewport of a visitor, it'll be generated.