You're totally right. Apparently this on the Nextjs team's radar though:

>Up next, we will be working on a supplemental RFC to address two additional incremental static generation capabilities:

> - Re-generating and invalidating multiple pages at once (like your blog index and a certain blog post)

> - Re-generating by listening to events (like CMS webhooks), ahead of user traffic

Source: https://nextjs.org/blog/next-9-5#stable-incremental-static-r...

But yeah, if you have 10k pages it seems unavoidable to me that initial build time will be high. With `fallback: 'blocking` you could decide to build each page at runtime when it is requested for the first time – this spreads out initial build time.

What would be nice is being able to re-use compiled pages across builds. Imagine having 10k pages compiled, and you have to push out a new build that only updates 5 pages, or none at all (eg an API change). It would be nice if it could make use of the compiled pages from the previous build, only re-compiling the pages that needed it. Of course the devil is in the details, and figuring out which pages need to be re-compiled basically requires you re-building the pages.

Right, actually building all those pages at once necessarily takes time. But on Netlify, most of my build time isn't actually used doing `next build`, it's the un-logged-to-user file transfer to their server / CDN cache invalidation / whatever hosting magic they do after the static files are built.

So at least in my case, NextJS would have to create a way to not rebuild files that haven't changed, and then the hosting/CDN provider would also need to be able to see which files those are and respond accordingly. This all seems very doable eventually though.