SSR, SSG e site estático: diferenças na hospedagem

Toda página web precisa virar HTML em algum momento. A diferença entre SSR, SSG e site estático está em quando isso acontece: a cada visita, uma vez durante o build ou dentro do navegador. Essa escolha define que tipo de hospedagem você precisa, quanta RAM paga e o que dá para colocar em cache.

Os termos se misturam porque SSG e "site estático" descrevem o mesmo resultado visto de ângulos diferentes. As seções abaixo separam cada um, com tabela e exemplos.

O que é um site estático?#

É um conjunto de arquivos HTML, CSS e JavaScript prontos, entregues exatamente como estão. A MDN resume assim: sites estáticos não têm lógica no servidor, então todo usuário recebe o mesmo conteúdo para uma URL. O servidor só lê o arquivo e envia.

Não há código seu rodando na hospedagem. Isso torna o site barato, fácil de colocar atrás de uma CDN e difícil de derrubar por excesso de acessos. Para o passo a passo de publicar um, veja o que é um site estático.

O que é SSG (static site generation)?#

SSG é o processo que produz o site estático: um comando de build roda seu código uma vez, busca os dados necessários e grava um HTML por rota. Em seguida você publica a pasta gerada.

No Next.js, o App Router renderiza Server Components durante o next build, como num gerador de sites tradicional. A configuração abaixo faz o framework exportar tudo como arquivos:

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
}

module.exports = nextConfig

Depois de next build, a pasta out contém os HTML, CSS e JS. Rotas dinâmicas como /blog/[id] só funcionam nesse modo se tiverem generateStaticParams(), que lista quais páginas gerar no build.

O custo do SSG: o conteúdo só muda quando você faz um novo build. Num site com milhares de páginas o build demora mais, e um preço atualizado só aparece no próximo deploy.

O que é SSR (server-side rendering)?#

No SSR o servidor monta o HTML a cada requisição. Ele pode ler o cookie de sessão, consultar o banco de dados e devolver uma página diferente para cada visitante. Por isso precisa de um processo rodando o tempo todo.

No Next.js, ler um dado que só existe no pedido, como um cookie, torna aquele trecho dinâmico:

// app/perfil/page.tsx
import { cookies } from 'next/headers'
import { Suspense } from 'react'

async function Saudacao() {
  const tema = (await cookies()).get('tema')?.value ?? 'claro'
  return <p>Seu tema: {tema}</p>
}

export default function Page() {
  return (
    <>
      <h1>Perfil</h1>
      <Suspense fallback={<p>Carregando...</p>}>
        <Saudacao />
      </Suspense>
    </>
  )
}

Segundo a documentação do Next.js, com Cache Components ativado (cacheComponents: true no next.config) o título (estático) e o fallback entram num "static shell" gerado no build, e só o trecho que lê cookies é renderizado no pedido. Estático e dinâmico convivem na mesma rota.

O custo do SSR: cada visita consome CPU e RAM de um processo sempre ligado (compare com serverless e containers), o tempo de resposta depende do código e dos dados, e uma página lenta de montar deixa o visitante esperando.

E o CSR, onde entra?#

No CSR (client-side rendering) o servidor envia um HTML quase vazio e o JavaScript monta a tela no navegador. Uma SPA em React puro funciona assim. Na hospedagem ela se comporta como um site estático, porque o que você publica são arquivos prontos. A diferença aparece para quem busca e para quem tem internet lenta: o conteúdo só existe depois que o JavaScript roda.

Qual a diferença na hospedagem?#

Duas consequências práticas. Primeiro, o site estático aceita quase qualquer hospedagem: a documentação do Next.js diz que o resultado pode ser servido por qualquer servidor web capaz de entregar HTML, CSS e JS. Segundo, ao usar output: 'export' você abre mão de recursos que dependem de um servidor Node.js: Server Actions, cookies, redirects, rewrites e headers do next.config, ISR e a otimização de imagens padrão, entre outros.

Como escolher o modelo de cada página?#

Pergunte, página por página, se o conteúdo muda por visitante ou por minuto:

• Blog, documentação, landing page, portfólio: SSG. O conteúdo muda quando você publica. É o caso mais barato e mais rápido.
• Painel, perfil, carrinho, página que depende de login: SSR, ou SPA falando com uma API. O conteúdo é diferente para cada pessoa.
• Catálogo com preços que mudam várias vezes ao dia: SSG com regeneração (ISR) ou SSR com cache. Dá para manter páginas estáticas e atualizá-las em intervalos, mas isso exige um servidor Node.js e não funciona com output: 'export'.
• App com muito JavaScript e pouco SEO: SPA estática costuma bastar.

Uma regra útil: comece estático e adicione servidor só onde um requisito pedir. O meio-termo mais comum é manter o front-end estático e mover a parte dinâmica para uma API separada.

Como saber se o meu site já é estático?#

Rode o build e olhe o resultado. Se ele gera uma pasta só com .html, .css e .js (como out, dist ou build), você pode publicá-la em qualquer servidor de arquivos. Se o framework exige um comando como next start para subir (veja como hospedar um app Next.js), existe um processo Node.js que precisa ficar ligado, e a hospedagem precisa oferecer isso.

Como fazer isso na Square Cloud#

Na Square Cloud, cada modelo tem o seu caminho. Para a parte estática, entre diversos runtimes, há um de sites estáticos: o nginx fica sempre no ar servindo a pasta, e cada atualização entra no ar na hora. Você envia a pasta gerada (out, dist) pelo painel em ZIP, pela CLI, pelo GitHub ou pela extensão do VS Code. O arquivo de configuração squarecloud.app é opcional: o painel o gera no deploy, ou você o escreve na raiz do projeto.

Para SSR, use o runtime de Node.js e rode o servidor do framework, como o next start. A plataforma não tem etapa de build, então rode o next build num CI externo ou no comando de início. No comando de início, as dependências do build (como typescript) precisam estar em dependencies, porque a instalação roda com NODE_ENV=production e pula as devDependencies.

As aplicações ficam em containers sempre ligados, sem cold start nem modo de suspensão, com reinício automático (ligado por padrão no deploy pelo painel) quando o processo encerra com erro. Uma aplicação web precisa de pelo menos 512 MB da RAM do seu plano, que é um pool compartilhado entre as suas aplicações. Não há autoscaling: você ajusta a RAM de cada aplicação nas configurações.

Toda aplicação web ganha um subdomínio *.squareweb.app com HTTPS, em qualquer plano. Domínio personalizado está disponível a partir do plano Standard: você cria os registros DNS no seu registrador, e o TLS é automático. O Hobby, a partir de R$ 12,49 por mês, atende sites, e todos os planos incluem CDN global e analytics web sem cookies. Os detalhes estão na página de Sites.