Por que SSR é melhor que SSG

Jun 30, 2024

Por que SSR é suficiente por si só

SSR (renderização do lado do servidor) refere-se à renderização de páginas sob demanda em tempo de execução no servidor, e depois enviá-las para o frontend. SSG (geração de sites estáticos) refere-se à pré-compilação de arquivos HTML e outros arquivos estáticos, e enviá-los diretamente para o frontend quando os usuários os solicitam.

Com essas definições claras, é fácil entender que SSR pode incorporar lógica dinâmica, mas requer um servidor em constante execução, enquanto SSG é mais adequado para conteúdo estático que pode ser colocado em um CDN. O conhecido framework NextJS suporta tanto SSR quanto SSG. No entanto, o mais novo framework Remix abandonou completamente o SSG, acreditando que há benefícios suficientes nesta abordagem. Com base na minha experiência, com o suporte de CDNs modernos, esta abordagem faz sentido.

CDNs modernos como Cloudflare e Vercel suportam ambientes serverless, tornando a implantação de aplicações NodeJS quase tão conveniente quanto a implantação de arquivos estáticos.
A principal vantagem do SSG é implantar arquivos estáticos diretamente em CDNs para economizar recursos do servidor. No entanto, o SSR também pode facilmente armazenar em cache conteúdo em CDNs configurando os cabeçalhos Cache-Control apropriados. Isso significa que o servidor SSR só é executado na primeira solicitação, tornando-o quase indistinguível de arquivos estáticos.
Não é necessário recompilar e reimplantar toda vez que o conteúdo estático é modificado.
Uma vez que se abandona a abordagem do NextJS de distinguir entre SSG e SSR, a carga mental é significativamente reduzida. A configuração de cache depende completamente de padrões HTML como Cache-Control, sem necessidade de aprender um conjunto adicional de interfaces. A depuração de problemas de cache também se torna muito mais fácil - quando o navegador armazena em cache uma solicitação que não deveria ser armazenada em cache, você só precisa verificar sua configuração de Response.

Um exemplo

Na verdade, o site oficial do Remix é um excelente exemplo. Sua documentação é gerada usando SSR. Muitas pessoas podem pensar que, como a documentação é apenas texto estático, o SSG não seria o melhor? A equipe do Remix explica seu raciocínio.

Sua documentação está armazenada no repositório de código-fonte do Remix, não escrita diretamente no site oficial. Esta abordagem de manter a documentação com o código-fonte tem vários benefícios:

Mais referencial ao ler código
Mais fácil modificar a documentação ao alterar o código
O Git rastreia automaticamente as alterações na documentação, vinculando-as às versões do código-fonte

O servidor do site oficial lê do repositório de código-fonte do Remix e gera páginas de documentação através do SSR. Esta abordagem tem vários benefícios:

Não é necessário recompilar e reimplantar todo o site toda vez que a documentação é modificada
Pode-se acessar diretamente a documentação para qualquer versão do Remix do repositório de código-fonte, até mesmo a documentação mais recente do branch dev. Isso permite que o site oficial exiba documentação correspondente a qualquer versão do Remix.

Como a documentação não são dados em tempo real, eles implementaram algumas otimizações de cache:

Usando lru-cache para armazenar em cache resultados da documentação. O cache está no lado do servidor, então todos os clientes se beneficiam.
- Timeout definido para 5 minutos
Configurando Cache-Control para stale-while-revalidate. Isso permite o cache em CDN:
```
return json(
  { doc },
  {
    headers: {
      "Cache-Control": "max-age=300, stale-while-revalidate=604800",
    },
  }
);
```
Isso significa que quando a documentação é modificada, o site oficial exibirá as alterações com um atraso máximo de 5 minutos (max-age=300).