SSR vs SSG: where your pages get built, and why it matters

What it actually is

Think of a restaurant’s menu. SSG is a batch of menus printed once before the doors open, every guest gets the same paper all day, cheap and instant to hand out. SSR is a chef writing out a fresh menu by hand for every single guest as they sit down, always current, but someone has to do that work every time. ISR is the printed-menu approach with a twist: the kitchen reprints a specific page automatically every so often, or the moment a price changes, so guests still get a fast printed copy that isn’t stuck being wrong for weeks.

Translated to a real page: SSG builds your HTML once, at deploy time, and a CDN serves that exact file to everyone. SSR builds the HTML on the server at the moment of each request. ISR builds it once like SSG, but rebuilds that single page in the background on a schedule you set (or when you tell it something changed) without rebuilding your whole site.

Why your AI just did this

Your agent has to decide, for every page, when its HTML gets produced. A marketing page or a blog post looks the same for everyone and rarely changes, so a careful agent renders it as SSG: fastest possible load, and it still works even if your backend is briefly down. A logged-in dashboard, a cart, or anything personalized has to be different per visitor, so that gets SSR. And for something in between, a product page whose price or stock changes now and then but is otherwise the same for everyone, the agent reaches for ISR: it sets a revalidate value so the page stays static-fast but refreshes itself.

In Next.js code, this shows up as export const revalidate = 3600 (refresh at most every hour), or a fetch call using cache: 'force-cache' versus cache: 'no-store'. That one line is the whole decision.

When you’ll run into it

• You edit a blog post in your CMS and the live site still shows the old text, that’s SSG (or ISR mid-window) waiting for its next build or refresh.
• next build output tags each route: ○ for static (prerendered) and ƒ for dynamic (server-rendered on demand), that’s the whole legend.
• Your agent’s code contains getStaticProps, getServerSideProps, generateStaticParams, or a revalidate number, those names are naming the rendering choice.
• A page is specifically slow to start loading (not slow after), that’s usually SSR waiting on a database or API call on every request, with nothing cached to fall back on.
• You ask “why isn’t my change live yet” right after editing content, and the honest answer is “it will be, once the next build or revalidation runs.”

What to check

• Does this page’s content differ per visitor, login, cart, personal data? If yes, it needs SSR, not SSG
• Does it look identical for every visitor and rarely change? SSG is enough, don’t pay server compute you don’t need
• Does it look the same for everyone but update sometimes, price, stock, edited copy? That’s ISR territory, check the revalidate number actually matches how fresh it needs to be
• On Vercel, check the deployment’s route list to see which mode each page actually got rather than assuming
• If a change isn’t showing, check whether it needs a full redeploy, an on-demand revalidation call, or just time for the interval to pass

Say it like a dev

Instead of: “why isn’t my content update showing up” Say: “is this page static, and does it need a rebuild or revalidation to pick up the change?”

Instead of: “make the page load faster” Say: “can this route be static instead of server-rendered, since it’s the same for every visitor?”

Instead of: “the page is slow” Say: “is this SSR, and is it waiting on a slow API call on every request?”