1. Why rendering strategy is even a decision
Every page a browser receives is just HTML, but when that HTML gets generated changes everything about performance, cost, and freshness. There are really only three moments it can happen: at build time (before any user ever asks for the page), at request time (right when a user asks for it), or somewhere in between (built once, then quietly rebuilt on a schedule). Static, SSG, SSR, and ISR are four names for exactly those moments — the confusion is that "static" and "SSG" often get used interchangeably even though they're subtly different.
2. Static rendering (plain static export)
The simplest possible case: HTML files are generated once, ahead of time, and served as-is forever — no server-side logic runs per request. This is what you get from a plain static export (next export or the App Router's static export mode) or a classic static site generator.
- Pros: can be hosted on literally any static file host or CDN, extremely fast (no server compute per request), effectively free to scale, no server to keep alive or secure.
- Cons: content is frozen until you rebuild and redeploy the whole thing — no per-user personalization, no live data without a client-side fetch afterward.
Good fit: marketing pages, documentation, a portfolio — anything where every visitor should see the exact same HTML and updates are rare.
3. SSG — Static Site Generation
SSG is static rendering's more data-aware sibling: Next.js fetches data and renders each page once at build time, then the server just hands out those pre-built files. The difference from plain static export is that SSG pages are typically generated per-item from a data source (a blog post per Markdown file, a product page per database row) rather than being hand-authored HTML.
Mental model
Think of SSG as "run the page's data-fetching logic once, at deploy time, for every possible version of the page, and cache the result forever."
Good fit: blogs, docs, catalogs where content changes on a schedule (a deploy) rather than second-to-second.
4. SSR — Server-Side Rendering
SSR flips the timing: the HTML is generated at request time, on the server, for every single visit. The server runs the page's data-fetching and rendering logic fresh, every time someone loads the page.
- Pros: always up to date, can be personalized per request (logged-in user's dashboard, real-time prices), no stale content risk.
- Cons: slower than serving a pre-built file (there's always at least one round trip to a data source per request), needs a running server (or serverless function) rather than just static files, cost scales with traffic.
Good fit: dashboards, anything behind a login, search results, checkout flows — pages where "slightly stale" is not acceptable.
5. ISR — Incremental Static Regeneration
ISR is Next.js's answer to "I want SSG's speed but I can't rebuild the whole site every time content changes." It's a hybrid: the first visitor after deploy gets the pre-built static version (fast), and you configure a revalidate time — after that window passes, the next request triggers a background regeneration, and future visitors get the refreshed version, without anyone waiting on a slow rebuild.
// app/products/[id]/page.tsx
export const revalidate = 60; // regenerate at most once per 60 seconds
export default async function ProductPage({ params }) {
const product = await getProduct(params.id);
return <ProductView product={product} />;
}
Good fit: e-commerce product pages, news articles, anything with hundreds/thousands of pages that change occasionally but don't need to be instantly live for every single edit.
6. Side-by-side comparison
| Strategy | HTML built when | Freshness | Typical cost/scale profile |
|---|
| Static export | At build time, once | Frozen until next deploy | Cheapest, CDN-only |
| SSG | At build time, per page | Frozen until next deploy | Cheap, CDN-only |
| ISR | At build time, then periodically in the background | "Eventually fresh" (bounded by revalidate window) | Cheap, occasional server compute |
| SSR | At every request | Always fresh | Server compute on every request |
7. How the App Router changes the mental model
In the App Router, you don't usually pick a strategy explicitly with a named function anymore (like the old getStaticProps/getServerSideProps from the Pages Router) — instead, Next.js infers it from how your Server Component fetches data. A component with statically analyzable data fetching gets rendered at build time and cached like SSG; add a revalidate export and it behaves like ISR; use a dynamic API (like reading cookies or search params) and the route automatically becomes SSR for that request. The four concepts didn't disappear — they became a spectrum the framework picks a point on for you, per route, based on what the code actually does.
8. How to actually choose, in practice
Default to static/SSG for anything where all visitors see the same content and updates happen on a deploy cadence — it's the cheapest and fastest option by a wide margin.
Reach for ISR when you have many pages backed by a data source that changes occasionally (products, articles) and a full rebuild per change would be wasteful or too slow.
Reach for SSR only when the page truly needs per-request freshness or personalization — it's the most expensive option and should be the exception, not the default.
The trap to avoid: reaching for SSR by default "just in case," when in practice most of a typical app's pages (marketing, docs, product listings, even most dashboards' shell) can be static or ISR, with only the truly dynamic slices needing per-request rendering.
1. Por que estratégia de renderização é sequer uma decisão
Toda página que o navegador recebe é só HTML, mas quando esse HTML é gerado muda tudo em termos de performance, custo e atualidade da informação. Só existem três momentos possíveis: no momento do build (antes de qualquer usuário pedir a página), no momento da requisição (na hora que alguém pede) ou em algum ponto intermediário (construído uma vez e depois silenciosamente reconstruído numa agenda). Static, SSG, SSR e ISR são quatro nomes pra exatamente esses momentos — a confusão é que "static" e "SSG" costumam ser usados como sinônimos mesmo sendo sutilmente diferentes.
2. Renderização estática (static export puro)
O caso mais simples possível: arquivos HTML são gerados uma vez, antecipadamente, e servidos exatamente como estão pra sempre — nenhuma lógica de servidor roda por requisição. É o que você recebe de um static export puro (next export ou o modo de export estático do App Router) ou de um gerador de site estático clássico.
- Prós: pode ser hospedado literalmente em qualquer host de arquivo estático ou CDN, extremamente rápido (sem computação de servidor por requisição), praticamente de graça pra escalar, sem servidor pra manter vivo ou seguro.
- Contras: conteúdo fica congelado até você reconstruir e reimplantar tudo — sem personalização por usuário, sem dado ao vivo sem um fetch no cliente depois.
Bom encaixe: páginas institucionais, documentação, um portfólio — qualquer coisa onde todo visitante deveria ver exatamente o mesmo HTML e atualizações são raras.
3. SSG — Static Site Generation
SSG é a irmã mais "ciente de dados" da renderização estática: o Next.js busca dados e renderiza cada página uma vez no momento do build, e o servidor só entrega esses arquivos pré-construídos. A diferença do static export puro é que páginas SSG normalmente são geradas por item a partir de uma fonte de dados (um post de blog por arquivo Markdown, uma página de produto por linha do banco) em vez de HTML escrito à mão.
Modelo mental
Pense em SSG como "rode a lógica de busca de dados da página uma vez, no momento do deploy, pra cada versão possível da página, e guarde o resultado em cache pra sempre."
Bom encaixe: blogs, documentação, catálogos onde o conteúdo muda numa cadência de deploy em vez de segundo a segundo.
4. SSR — Server-Side Rendering
SSR inverte o momento: o HTML é gerado no momento da requisição, no servidor, pra cada visita. O servidor roda a lógica de busca de dados e renderização da página do zero, toda vez que alguém carrega a página.
- Prós: sempre atualizado, pode ser personalizado por requisição (dashboard de usuário logado, preços em tempo real), sem risco de conteúdo desatualizado.
- Contras: mais lento que servir um arquivo pré-construído (sempre existe pelo menos uma ida-e-volta a uma fonte de dados por requisição), precisa de um servidor rodando (ou função serverless) em vez de só arquivos estáticos, custo escala com tráfego.
Bom encaixe: dashboards, qualquer coisa atrás de login, resultados de busca, fluxos de checkout — páginas onde "levemente desatualizado" não é aceitável.
5. ISR — Incremental Static Regeneration
ISR é a resposta do Next.js pra "eu quero a velocidade do SSG mas não posso reconstruir o site inteiro toda vez que o conteúdo muda." É um híbrido: o primeiro visitante depois do deploy recebe a versão estática pré-construída (rápida), e você configura um tempo de revalidate — depois que essa janela passa, a próxima requisição dispara uma regeneração em background, e visitantes futuros recebem a versão atualizada, sem ninguém esperar por um rebuild lento.
// app/products/[id]/page.tsx
export const revalidate = 60; // regenera no máximo uma vez a cada 60 segundos
export default async function ProductPage({ params }) {
const product = await getProduct(params.id);
return <ProductView product={product} />;
}
Bom encaixe: páginas de produto de e-commerce, artigos de notícia, qualquer coisa com centenas/milhares de páginas que mudam ocasionalmente mas não precisam estar instantaneamente ao vivo pra cada edição.
6. Comparação lado a lado
| Estratégia | HTML construído quando | Atualidade | Perfil típico de custo/escala |
|---|
| Static export | No momento do build, uma vez | Congelado até o próximo deploy | Mais barato, só CDN |
| SSG | No momento do build, por página | Congelado até o próximo deploy | Barato, só CDN |
| ISR | No momento do build, depois periodicamente em background | "Eventualmente atualizado" (limitado pela janela de revalidate) | Barato, computação de servidor ocasional |
| SSR | A cada requisição | Sempre atualizado | Computação de servidor a cada requisição |
7. Como o App Router muda o modelo mental
No App Router, você normalmente não escolhe mais uma estratégia explicitamente com uma função nomeada (como os antigos getStaticProps/getServerSideProps do Pages Router) — em vez disso, o Next.js infere a partir de como seu Server Component busca dados. Um componente com busca de dados estaticamente analisável é renderizado no build e fica em cache como SSG; adicione um export de revalidate e ele se comporta como ISR; use uma API dinâmica (como ler cookies ou parâmetros de busca) e a rota vira SSR automaticamente pra aquela requisição. Os quatro conceitos não desapareceram — viraram um espectro no qual o framework escolhe um ponto pra você, por rota, com base no que o código de fato faz.
8. Como escolher de verdade, na prática
Prefira static/SSG por padrão pra qualquer coisa onde todo visitante vê o mesmo conteúdo e atualizações acontecem numa cadência de deploy — é a opção mais barata e rápida, de longe.
Use ISR quando você tem muitas páginas alimentadas por uma fonte de dados que muda ocasionalmente (produtos, artigos) e um rebuild completo a cada mudança seria desperdício ou lento demais.
Use SSR só quando a página realmente precisa de atualidade ou personalização por requisição — é a opção mais cara e deveria ser a exceção, não o padrão.
A armadilha pra evitar: recorrer ao SSR por padrão "só por garantia", quando na prática a maioria das páginas de um app típico (institucional, documentação, listagens de produto, até a casca da maioria dos dashboards) pode ser static ou ISR, com só as fatias verdadeiramente dinâmicas precisando de renderização por requisição.