Renderização do lado do servidor

A renderização do lado do servidor é uma abordagem na qual o servidor gera a marcação completa de uma página e a envia para o navegador, em vez de enviar um documento mínimo que o JavaScript preenche posteriormente. O navegador pode exibir conteúdo relevante assim que a resposta chega, sem precisar esperar que um pacote seja baixado, analisado, executado e os dados sejam obtidos.

Ele aborda as fragilidades específicas e bem documentadas da renderização puramente no lado do cliente. O conteúdo aparece substancialmente mais rápido, principalmente em dispositivos e conexões mais lentas, onde a execução de JavaScript é custosa. Mecanismos de busca e outros consumidores automatizados recebem o conteúdo diretamente, em vez de depender de uma etapa de renderização que pode estar atrasada ou incompleta. As pré-visualizações para compartilhamento em redes sociais funcionam sem tratamento especial. E a experiência se degrada de forma mais elegante quando o JavaScript falha ao carregar ou executar, o que acontece com mais frequência do que a maioria das equipes imagina.

A hidratação é o custo associado e frequentemente subestimado. Após a exibição da marcação renderizada pelo servidor, o framework do lado do cliente precisa anexar manipuladores de eventos e reconstruir seu estado interno para tornar a página interativa. Durante esse período, a página parece pronta, mas não responde, o que produz uma falha característica em que o visitante clica em algo visível e nada acontece. Em páginas grandes e dispositivos mais lentos, esse período pode ser considerável.

Diversas abordagens surgiram para reduzir esse custo. A hidratação parcial e seletiva torna interativas apenas as partes da página que são interativas, em vez da página inteira. O streaming envia a marcação progressivamente, de modo que o conteúdo apareça antes que a página inteira seja gerada. As arquiteturas em ilha tratam os componentes interativos como unidades isoladas dentro de uma marcação estática. Cada uma delas reduz a quantidade de trabalho do lado do cliente necessária após a renderização inicial.

A geração de sites estáticos é a alternativa que vale a pena considerar inicialmente para conteúdo que não muda a cada requisição. As páginas são renderizadas no momento da compilação e servidas como arquivos, o que é mais rápido do que renderizar a cada requisição, mais barato de servir, mais resiliente e mais fácil de armazenar em cache na borda. Quando o conteúdo muda, mas não a cada visitante, as estratégias de regeneração incremental reconstroem as páginas afetadas de acordo com um cronograma ou sob demanda, o que captura a maior parte dos benefícios sem uma reconstrução completa.

As implicações operacionais diferem da hospedagem estática de maneiras que exigem planejamento. A renderização por requisição consome recursos do servidor proporcionalmente ao tráfego, o que introduz considerações de escalabilidade e custos que os arquivos estáticos não possuem. O armazenamento em cache torna-se importante, e o armazenamento em cache de páginas que contêm conteúdo personalizado requer uma separação cuidadosa do que varia para cada usuário e do que não varia. Erros de servidor agora afetam a renderização da página, e não apenas o carregamento de dados.

A estratégia de busca de dados determina grande parte do benefício na prática. A renderização no servidor só é vantajosa se os dados necessários para a página estiverem disponíveis rapidamente, e uma renderização no servidor que aguarda a conclusão de vários serviços internos lentos pode ser mais lenta até o primeiro byte do que uma renderização no cliente que exibe o conteúdo imediatamente. Quando as dependências são lentas, transmitir as partes que já estão prontas enquanto o restante é processado preserva a vantagem.

A decisão deve ser baseada no conteúdo e no público-alvo, e não em modismos de frameworks. Páginas com muito conteúdo, que precisam ter um bom posicionamento nos mecanismos de busca e carregar rapidamente mesmo em conexões lentas, se beneficiam consideravelmente. Já aplicativos altamente interativos que exigem autenticação, onde a visibilidade nos mecanismos de busca é irrelevante e os usuários já carregaram o aplicativo, se beneficiam muito menos e podem não justificar a complexidade. Muitos produtos, sensatamente, utilizam abordagens diferentes para cada seção.

Como a escolha afeta simultaneamente a infraestrutura, a entrega e o desempenho da busca, trata-se de uma decisão arquitetural, e não de uma preferência de front-end. Na prática, ela é avaliada dentro de desempenho na web trabalho com base em dados de campo medidos, implementado por meio de desenvolvimento de produtose as implicações da pesquisa são avaliadas com serviços de marketing, visto que o comportamento de indexação é frequentemente o argumento mais forte a favor da mudança.