Fundamentos da arquitetura SSR: o que é e por que importa

• Server-Side Rendering (SSR) é o processo de gerar o HTML da página no servidor, entregando conteúdo completo ao cliente já pronto para renderizar.
• Comparado ao Client-Side Rendering (CSR) e à Static Site Generation (SSG), o SSR oferece melhor SEO inicial, tempo de primeira renderização (FCP) e controle sobre o conteúdo dinâmico.
• Trade-offs: maior carga no servidor, complexidade de cache e estratégia de hidratação; quando bem aplicado, reduz latência percebida e evita a viagem completa do JavaScript ao usuário.
• Contextos de uso comuns: páginas com conteúdo dinâmico, personalização de usuário, SEO sensível e sites com altas variações de conteúdo entre requisições.

Pipeline de renderização: fluxo, dados e hidratação

1. Receita da requisição: o cliente solicita uma página; o cache intermediário pode retornar HTML já pronto.
2. Coleta de dados: servidor consulta serviços, bases de dados e APIs necessárias para compor a página.
3. Renderização no servidor: o HTML é montado com estado inicial pronto para entregar ao cliente.
4. Streaming e entrega: em pipelines modernos, o HTML pode ser enviado em partes (streaming) para reduzir o tempo até o conteúdo visível.
5. Hidratação no cliente: o JavaScript assume a interatividade, ligando o HTML estático a componentes dinâmicos, mantendo a consistência de estado.
6. Interações subsequentes: navegação entre páginas pode usar SSR repetidamente ou estratégias híbridas (CSR em partes da UI).

CDN / Edge Cache

Servidor SSR

HTML renderizado

Fluxo típico: Cliente → CDN/Cache → Servidor SSR → HTML entregue ao cliente. O cache pode reduzir a latência em requisições repetidas.

Arquitetura prática: camadas, cache e escalabilidade

• Camada de apresentação: templates ou componentes renderizados no servidor, com capacidade de inserir estado inicial e dados dinâmicos.
• Camada de dados: orquestração de chamadas a bancos, serviços e APIs, com estratégias de cache para reduzir latência.
• Cache inteligente: adote cache de borda (CDN/Edge) para conteúdo estático e sem código sensível; cache do servidor para dados dinâmicos com invalidation clara.
• Estratégias de invalidação: time-to-live (TTL), stale-while-revalidate e políticas por endpoint para balancear frescor e disponibilidade.
• Observabilidade: tracing, logs estruturados e métricas de tempo de renderização, tempo até FCP e taxa de cache hit.

// Exemplo simples de um handler SSR em Node.js (sem dependências)
const http = require('http');

function renderToHtml(url) {
  // Renderização simulada no servidor
  const title = url === '/' ? 'Página inicial' : 'Página: ' + url;
  return `

    
${title}
    
Conteúdo renderizado no servidor.
  
`;
}

const server = http.createServer((req, res) => {
  const html = renderToHtml(req.url);
  res.writeHead(200, { 'Content-Type': 'text/html' });
  res.end(`${html}`);
});

server.listen(3000, () => console.log('SSR ouvindo na porta 3000'));

Boas práticas de desempenho, SEO e acessibilidade

• Desempenho: orçamento de performance, pré-carregamento estratégico de recursos críticos, e entrega progressiva de HTML via streaming quando possível.
• SEO: conteúdo visível imediatamente, tags meta corretas, dados estruturados (schema.org) e conteúdos renderizados por robôs de busca.
• Acessibilidade: mantenha contraste suficiente, use aria-labels onde necessário, e garanta semântica correta (main, nav, header, footer).
• Experiência do usuário: minimize hidratação bloqueante; seções estáticas devem ser entregues como HTML puro para reduzir o tempo até a interatividade.