O que o SSR muda
O SSR move a geração da marcação inicial para o servidor. O navegador recebe o HTML e, depois, o JavaScript pode fazer a hidratação dos componentes interativos. SSR não é sinônimo de geração estática, cache, TTFB rápido nem indexação bem-sucedida.
A prova está no corpo e no status da resposta de uma URL real, e não em uma configuração do framework.
Teste a resposta
Inspecione o HTML inicial com o JavaScript desativado ou com um fetch bruto. Verifique o status, a tag canonical, o texto principal e o comportamento em caso de erro antes da hidratação.
- Busque o HTML inicial.
- Teste uma rota inexistente.
- Compare o conteúdo renderizado com o bruto.
- Meça o TTFB separadamente.
- Teste as variantes de cache.
Escolha o caminho de renderização
Use SSR quando for necessário trabalhar com dados no momento da requisição ou personalização, e a origem conseguir responder de forma confiável. Para páginas públicas e estáveis, uma saída estática ou em cache pode ser mais adequada.
| Pergunta | Verificação | Limite |
|---|---|---|
| Conteúdo inicial | Presente no HTML da resposta | O HTML sozinho não garante qualidade |
| Rota de erro | Status 404/410/500 corretos | A interface do cliente pode mascarar o status |
| Desempenho | TTFB e recursos separados | Uma pontuação única esconde as camadas |
Limites do SSR
Uma página renderizada no servidor ainda pode ser lenta, retornar um erro ou esconder conteúdo atrás de chamadas feitas depois pelo cliente.