O Que É Server-Side Rendering? HTML Construído sob Requisição
O server-side rendering (SSR) gera uma página no servidor a cada requisição, enviando HTML pronto para exibir em vez de um shell vazio que o browser precisa preencher.
Um app puramente renderizado no cliente envia um arquivo HTML quase vazio e constrói a página no browser, o que atrasa o primeiro paint e complica o SEO. O SSR renderiza o HTML no servidor primeiro, então o usuário vê o conteúdo imediatamente. Isso muda o que seu build produz e como você faz deploy, porque agora há um servidor em execução, não apenas arquivos estáticos.
Como o SSR funciona
A cada requisição, o servidor executa o código do seu app, produz o HTML final e o envia ao browser. O browser o exibe imediatamente e então carrega o JavaScript que assume a interatividade por meio da hydration.
SSR vs renderização no cliente
A renderização no cliente envia JavaScript que constrói o DOM no browser, então a primeira resposta é quase vazia. O SSR envia HTML significativo na primeira resposta. O SSR melhora a velocidade percebida e o SEO ao custo de rodar um servidor por requisição.
O que você abre mão
- Você precisa de um servidor em execução ou de uma função serverless, não apenas de hospedagem estática.
- O tempo de render no servidor adiciona latência sob carga.
- O código precisa rodar tanto no ambiente do servidor quanto no do browser.
Frameworks que fazem SSR
Next.js, Nuxt, Remix e SvelteKit todos suportam SSR. Eles borram a linha entre servidor e cliente, permitindo que você escreva componentes que renderizam em qualquer lugar, com o framework conectando a hydration.
SSR no CI/CD
Um build de SSR produz tanto um bundle de cliente quanto um de servidor, e o alvo de deploy precisa executar esse código de servidor, não apenas servir arquivos. O pipeline constrói as duas metades e então envia o bundle de servidor para um runtime serverless ou de contêiner. Isso torna o artifact de build e a etapa de deploy mais pesados do que um site estático.
Principais conclusões
- O SSR renderiza HTML no servidor por requisição para um primeiro paint rápido e melhor SEO.
- Ele requer um servidor em execução, então o deploy é mais pesado que a hospedagem estática.
- O CI constrói tanto um bundle de cliente quanto um de servidor, e então envia o servidor para um runtime.