The Problem with Static Site Generation — and How ISR Solves It

When I first started using Static Site Generation (SSG) in Next.js, it felt like magic. You pre-render your pages at build time, deploy them, and boom — your site is fast, SEO-friendly, and scalable. What’s not to love?

But then I asked myself a question:

"What happens if I have thousands of blog posts? Are all of them generated during build? What if a new one is added later?"

Let’s walk through that exact thought process — because it’s the same question every developer faces when scaling their app with SSG.

---

🤔 First, a Quick Recap — What is Static Site Generation?

SSG means that your website’s pages are converted to static HTML at build time.

For example, in a blog site:

• /blog/react-hooks

• /blog/js-hoisting

• /blog/nextjs-ssg

If you use getStaticProps (and getStaticPaths), Next.js will:

• Pre-fetch the data for each route

• Pre-render the HTML during the build

• Save it as static files that get instantly served when requested

This is why SSG pages are blazingly fast and great for SEO.

---

🧠 But Then I Asked…

"If these static pages are still interactive (buttons, animations, etc.), then what exactly is static in SSG?"

Great question.

• What’s static is the initial HTML sent from the server.

• Once that HTML loads in the browser, React hydrates the page — activating interactivity like hooks, state, modals, etc.

So yes, static pages can be dynamic in behavior, but their structure and content at first load are predefined.

---

🧨 And Then I Hit the Real Limitation...

“So if I have 1000 blog posts now and the 1001st post is added tomorrow, do I have to rebuild the whole site again to include it?”

By default, with pure SSG:
Yes — you'd have to rebuild the entire site to include the new page.

But here’s where the real limitation hit me harder:

Then I thought…

““What if I have 1 million, or even 10 million blog posts? Surely I can’t pre-generate and store all of them as static files, right?”

That was my next obvious question. Static pages are just plain .html and .json files stored on a CDN. So technically, I should be able to generate millions — even billions — of them, right?

And the answer is… yes, but with some caveats.

There’s no hardcoded limit on the number of static pages you can generate. If your hosting provider supports it and your infrastructure can handle it, you can pre-render a massive number of pages during build time. However, the more pages you generate, the longer your build times get. Also, handling millions of static files can become a pain from a deployment and caching perspective. Imagine rebuilding your whole site every time one of those pages changes. That's where the real limitations start showing up — not with storage, but with practicality and scalability.

---

🔥 Why Prebuilding Millions of Pages is a Problem

Let’s say you want to pre-render 10 million pages using SSG.

“So what’s the solution then? Surely I can’t rebuild my whole site every time one page changes?”

Exactly. That’s the problem with pure SSG — it expects you to know all your pages at build time and rebuild everything if even one page updates. That might be fine for a small blog, but what if you’re running a CMS-backed site, a news platform, or an e-commerce store with millions of products?

Here’s the idea: What if pages are generated in on-demand, as users request them — and then cached statically just like regular SSG pages?

Incremental Static Regeneration (ISR) do the exact same thing.

ISR is like having the best of both worlds. When a page is requested for the first time, Next.js generates it on the fly, saves it to the CDN, and serves it instantly. The next time someone visits that page — it’s already cached and lightning-fast, just like SSG.

But it doesn’t stop there. You can even tell it when to revalidate a page — for example, every 10 seconds, or every hour. So your content stays fresh without full rebuilds. You don’t need to prebuild a million pages — you just build the ones people are actually visiting, as they visit.

“So does that mean the SSG in Next.js is actually ISR under the hood?”

Not quite — but close.

Next.js supports both:

• Pure SSG (Static Site Generation): You define all your routes at build time using getStaticPaths, and every single page is pre-rendered into static HTML + JSON. No server involved during request time. It's great for small sites or content that doesn't change often.

• ISR (Incremental Static Regeneration): This extends SSG. It still generates static pages, but only when needed, and it can revalidate them over time. You enable this behavior by using revalidate in getStaticProps.

So ISR is built on top of SSG — it uses the same static generation mechanism, but instead of doing all the work up front during a massive build, it does it incrementally and on demand.

You could say: SSG is the foundation. ISR is the scalable evolution.