It _can_ prerender all of those combinations. Here is a directory I made with 1000+ pages, prerendered and hosted for free on netlify: https://www.givepuppylove.com/organizations/ . I've found that single digit thousands is about the maximum you can currently have and keep build times reasonable.

If you want to recognize the user's location and display the appropriate currency or language, you would probably want to wrap content dependent on location in a "ClientOnly" type component. So it would not be prerendered in that case. Example code:

  export default function ClientOnly({ children, ...delegated }) {
    const [hasMounted, setHasMounted] = useState(false)
    useEffect(() => { setHasMounted(true) }, [])

    return hasMounted ? <div {...delegated}>{children}</div> : <div></div>
  }

This allows you to grab things off the "window" and change behavior based on that info, which you can't do with prerendering.

As far as count of pages Vercel has a limit of 16000 and Netlify technically has no limit (AFAIK), although the build times will cost you eventually. You can work around this limit in a lot of cases while keeping things prerendered by putting dynamic information in querystrings.

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.

What happens if there are millions of pages?

Wish Next.js would have a "scalability issues and solutions" documentation...

For each page, you can set `fallback: 'blocking'`. If set, the page is not built at compile time. Instead, it will be compiled the first time it's requested. So the first request will take longer, then after that it'll be fast.

Alternatively, on a per-page decision you could decide to use server side generation (page built at compile time) or server side rendering (page compiled when requested).

You have options that let you spread out the time, but ultimately it's going to take time to build millions of pages.

Like acoard said below, I think the recommendation there would be to use their hybrid cache / dynamic rendering option. You do lose a lot of the cool benefits of being fully static in that case though. In general, yes that kind of documentation would be very helpful.

Disclaimer being that I'm talking mostly about 5 - 10 page presentation websites, consistently, I achieve 95+ on Google Page Speed for Mobile when deploying the Next.JS solutions on the Vercel infrastructure. There are helpers for working with images that can generate multiple versions, transform to WebP and other stuff. This is where most of the optimization work goes I think.

> Most of the time when I see the "new hotness" being advertised, there don't really seem to be any specifics that tackle advanced use-cases so it's difficult to accurately assess whether the technology is worth serious consideration

I'm also averse to 'hotness' but at the same time, consideration should be given based on use case. I can't talk for advanced use-cases with Next.JS but using it for the one off freelancing simple website gig, it's a breath of fresh air.

There's also a customer serving around 100.000 pregenerated web pages (simple stuff, catalog item with pictures, related items and people linked to it) and the speed is insane for navigating their internal catalogue :)

> if I have a store with 500 products, will it pre-render the HTML (photos, etc.) for all 500 products and serve it as a static request?

You can set it up to retrieve all 500 products and render the html on the server.

> What if my store has multicurrency / multilingual versions of all these 500 pages - will it pre-render all of these combinations?

The server is making all the requests that would have been made on the frontend. So if the server knew the locale of the user it could presumably load the correct currency and language.

Next.js can do both pre-rendering (static output) and dynamic server-side rendering. I can't speak to your questions about internationalization though.

I recently played around with Next 9.5 prerendering. It had about 400 simple pages with artificially slow API responses to get an idea.

- you can prerender a decent amount of pages no probs

- you can prerender only a subset and then have Next render the necessary pages on the server upon request

- as the page is being prerendered, you can send placeholder content, so ttfb is low

- linking to a non-prerendered page within Next will prefetch (and thus prerender) said page as soon as the link is in the viewport (can be disabled)

- in Vercel you can set the branch name as an env variable. I set it to prerender almost nothing during build time if the branch name contained “hotfix”

So far I think it is worth serious consideration. Will it work for you? I dunno. But it’s a breeze to set up, quick to learn, and run some experiments of your own.

> I haven't used a JS framework with server-side rendering in a while - but from what I remember it seemed to add a terribly high TTFB to the overall page load, which negatively impacted SEO.

You can just stick a CDN like Cloudflare in front of your requests, and this issue is resolved.

yes, next will prerender everything. you should give it a try.