Site estático ou dinâmico: diferenças e quando usar cada um

Todo site responde a um pedido do navegador com HTML. A diferença entre estático e dinâmico está no que acontece no servidor entre o pedido e a resposta: ou ele só lê um arquivo que já existe, ou roda código para montar aquela página naquele momento.

Essa diferença decide quase tudo o que vem depois: que tipo de hospedagem você contrata, quanto paga, quanto trabalho tem para manter o site seguro e como o conteúdo é atualizado. E muitos projetos hoje ficam no meio do caminho, combinando os dois.

O que é um site estático?#

A MDN define um site estático como aquele que devolve o mesmo conteúdo fixo sempre que um recurso é pedido. O servidor busca o arquivo no disco e responde com 200 OK. Não há linguagem de back-end rodando nem banco de dados consultado.

Os arquivos podem ser escritos à mão ou gerados por uma ferramenta (Astro, Hugo, Eleventy, Vite, Next.js) num passo de build. Depois do build, o resultado é uma pasta com HTML, CSS, JavaScript e imagens, e é essa pasta que vai para o servidor. Os detalhes estão em o que é um site estático.

Estático não significa sem interação. O JavaScript que roda no navegador pode abrir menus, filtrar listas e chamar APIs. "Estático" descreve o servidor, não a página.

O que é um site dinâmico?#

Num site dinâmico, parte da resposta é gerada na hora. Segundo a mesma página da MDN, as páginas costumam ser criadas inserindo dados de um banco em templates HTML, e o site pode devolver conteúdo diferente para a mesma URL conforme o usuário ou as preferências salvas.

Isso exige código no servidor (Node.js, Python, PHP, Ruby, Java e outros), um processo rodando para atender os pedidos e, quase sempre, um banco de dados. Em troca, o site pode fazer o que um conjunto de arquivos não faz: login com sessão, conteúdo personalizado, controle de acesso, carrinho, busca em dados que mudam o tempo todo. Lojas virtuais, redes sociais, painéis e o WordPress são dinâmicos. Como juntar site e banco está em site com banco de dados.

Quais as diferenças lado a lado?#

Algumas linhas pedem explicação:

• Velocidade. Ler um arquivo é sempre mais barato que rodar código e consultar um banco. Um site dinâmico bem feito pode ser rápido, mas depende de cache e de consultas otimizadas; o estático é rápido por padrão.
• Segurança. Sem código no servidor, não há injeção de SQL, sessão roubada ou plugin desatualizado para explorar. O dinâmico precisa de atualizações constantes e de um checklist de segurança.
• SEO. O Google processa JavaScript em três fases (rastreamento, renderização e indexação), e a própria documentação de busca do Google diz que renderizar no servidor ou pré-renderizar continua sendo uma boa ideia, porque deixa o site mais rápido e nem todo robô executa JavaScript. Tanto o estático quanto o dinâmico que monta HTML no servidor atendem a isso. O que atrapalha é o conteúdo que só aparece depois de rodar JavaScript no navegador.
• Custo. O estático não roda código seu nem banco: basta um servidor web entregando arquivos, o que cabe na hospedagem mais simples. O dinâmico paga RAM e CPU para o processo e para o banco. Os números estão em quanto custa hospedar um site.

Como fica a mesma página nos dois modelos?#

No modelo estático, a página é um arquivo index.html na pasta publicada. Se ela precisa de um dado que muda, o navegador busca esse dado numa API depois de carregar:

<!doctype html>
<meta charset="utf-8">
<title>Status</title>
<h1>Status do serviço</h1>
<p id="status">Carregando...</p>
<script type="module">
  const res = await fetch("/api/status.json");
  const data = await res.json();
  document.querySelector("#status").textContent = data.message;
</script>

No modelo dinâmico, o servidor monta o HTML com os dados antes de responder. Um exemplo mínimo com o módulo node:http do Node.js, sem dependências:

import { createServer } from "node:http";

const escapeHtml = (s) =>
  s.replace(/[&<>"']/g, (c) => `&#${c.charCodeAt(0)};`);

const server = createServer((req, res) => {
  const url = new URL(req.url, "http://localhost");
  const name = url.searchParams.get("nome") ?? "visitante";
  const now = new Date().toLocaleTimeString("pt-BR", { timeZone: "America/Sao_Paulo" });

  res.writeHead(200, { "content-type": "text/html; charset=utf-8" });
  res.end(`<!doctype html><meta charset="utf-8">
<h1>Olá, ${escapeHtml(name)}</h1>
<p>Página gerada às ${now}</p>`);
});

server.listen(process.env.PORT ?? 3000);

Cada visita a /?nome=Ana produz um HTML diferente, com o nome e a hora daquele pedido. Repare no escapeHtml: todo dado vindo do usuário precisa ser escapado antes de entrar no HTML, ou o site fica vulnerável a XSS. No modelo estático não há template no servidor para escapar; no JavaScript do navegador, escrever o dado com textContent, como no primeiro exemplo, evita o mesmo problema.

Existe meio-termo entre os dois?#

Existe, e é o que a maioria dos projetos modernos usa. Três combinações comuns:

1. Site estático + API. O front-end é estático e uma API separada cuida de login, formulários e dados. O site continua leve e barato, e só a API precisa de servidor. Entenda o lado da API em o que é uma API REST.
2. CMS + build automático. O conteúdo fica num CMS ou em arquivos Markdown. Cada publicação dispara um novo build, e o site publicado continua estático.
3. Framework híbrido. Next.js, Nuxt, Astro e similares decidem página por página: o que é igual para todos vira HTML no build, e o que depende do pedido é renderizado no servidor. Nesse caso o projeto precisa de um servidor rodando. A documentação do Next.js mostra que, ao exportar só arquivos estáticos, recursos como cookies, Server Actions e Incremental Static Regeneration deixam de funcionar.

A diferença entre gerar no build e gerar a cada pedido está detalhada em SSR, SSG e site estático.

Quando escolher cada um?#

A regra prática: comece pelo estático e só adicione código no servidor quando aparecer algo que dependa de cada visitante ou precise mudar sem novo deploy. Se o conteúdo é igual para todos e muda poucas vezes por dia, um site estático resolve com menos custo e menos risco. Para colocar qualquer um dos dois no ar, veja como hospedar um site.

Como fazer isso na Square Cloud#

A Square Cloud hospeda os dois modelos, e o meio-termo, na mesma conta. Para o estático, entre diversos runtimes, como Node.js, Python e Go, há um para sites estáticos: o nginx fica sempre no ar servindo a pasta gerada pelo build, nenhum código seu roda no servidor, e um novo commit, upload ou edição no gerenciador de arquivos entra no ar na hora. Para o dinâmico, use o runtime da sua linguagem (Node.js, Python, PHP, Ruby, Java, Go e outros), num container sempre ligado, sem cold start nem modo de suspensão. Veja os runtimes disponíveis hoje em Runtimes.

No arranjo estático + API, o front-end e a API viram duas aplicações separadas, cada uma com o próprio subdomínio *.squareweb.app com HTTPS. Cada aplicação web usa no mínimo 512 MB da RAM do plano, que é um pool compartilhado entre elas. O deploy é seu: ZIP no painel, CLI, GitHub ou extensão do VS Code, e o arquivo squarecloud.app é opcional, porque o painel o gera no deploy.

O Hobby, a partir de R$ 12,49 por mês, atende sites e inclui analytics web sem cookies, com visitas, rotas e códigos de status. Domínio personalizado e hospedagem de banco de dados, que um site dinâmico costuma precisar, começam no Standard. Comece pelo runtime de sites estáticos ou veja a página de sites.