Server Side Rendering (SSR)

Olá! Neste artigo, estou iniciando um desafio pessoal de escrever três artigos consecutivos nas próximas duas semanas abordando a temática do Server Side Rendering, Client Side Rendering e finalizando com a comparação entre Server Side Rendering X Client Side Rendering.

Neste artigo, irei discorrer um pouco mais sobre esse tema, que gera dúvidas em diversos desenvolvedores e arquitetos de sistemas. Vou levantar os prós e contras de cada implementação e, por fim, fazer uma breve reflexão sobre o uso dessas técnicas.

Introdução ao Server Side Rendering

Server Side Rendering (SSR) é uma estratégia de implementação frontend amplamente utilizada no mercado. Ao adotar o SSR, é possível aumentar a velocidade do seu site e melhorar os WebVitals. (componentes de métricas de renderização da sua tela, clique aqui para mais detalhes).

Antes de explicar como o SSR funciona, vamos passar por uma etapa conceitual sobre como uma página é renderizada em um navegador.

Quando um site é acessado, o navegador faz uma solicitação ao Sistema de Nomes de Domínios (DNS). Em seguida, é feita uma requisição HTTP para obter o recurso do endereço acessado. Com o recurso em mãos, o navegador constrói uma representação em árvore com as tags HTML recebidas, chamada de Document Object Model (DOM). O DOM é uma representação estruturada do conteúdo do site.

Após a estruturação do DOM, o navegador processa as tags de recursos externos (como links, scripts, imagens, folhas de estilo) de forma paralela. Com as informações disponíveis, o navegador inicia a renderização gráfica da experiência do cliente. Em seguida, a etapa de interatividade e eventos é ativada, permitindo que o usuário interaja com a tela.

Quando utilizamos a abordagem do SSR, atuamos diretamente na etapa de construção do DOM. Por realizar a maior parte do processamento no servidor, já recebemos todas as informações prontas logo na primeira interação com o servidor, sem a necessidade de processamento dinâmico. Isso proporciona uma renderização mais fluída do conteúdo, sem a necessidade de carregar dados por meio de APIs no lado do frontend.

A imagem abaixo ilustra o processo de carregamento de uma tela dentro do navegador utilizando SSR.

Vantagens

Assim como qualquer abordagem, o SSR possui vantagens e desvantagens que devemos considerar ao escolher essa estratégia. Nesta parte, vou abordar algumas das vantagens de utilizar o SSR.

• Fácil indexação de conteúdo: Devido ao fato de o conteúdo ser renderizado diretamente no servidor, sem a necessidade de processamento no frontend, o uso do SSR facilita a indexação do seu site por ferramentas de busca, uma vez que geralmente essas ferramentas não executam scripts.
• Baixo tempo de carregamento: Como o SSR já carrega todo o conteúdo de uma vez, seu uso possibilita um carregamento mais rápido da página.
• Ideal para sites estáticos: Devido às suas principais renderizações serem realizadas antes do navegador baixar imagens, CSS e scripts, o SSR é excelente para fornecer experiências estáticas.
• Métricas de usuários mais precisas: Por não precisar carregar informações em tempo de execução, o SSR fornece métricas de carregamento mais precisas.

Desvantagens

Abaixo estão algumas desvantagens da adoção do modelo SSR:

• Problemas de compatibilidade com navegadores: Ao trazer a página pré-processada, há o risco de incluir componentes que não sejam compatíveis com determinados navegadores, uma vez que o servidor não tem acesso aos dados do navegador. Isso pode resultar em erros no frontend durante a renderização.
• Alto uso de processamento no backend: Ao realizar a renderização no servidor, pode haver um impacto significativo no processamento do servidor, resultando em um maior consumo de recursos de processamento e memória da aplicação.
• Custo de infraestrutura: Ao trazer o processamento para o servidor, pode ser necessário aumentar a escalabilidade dos componentes do backend, o que gera uma maior carga de processamento no lado do servidor e pode resultar em um maior custo de infraestrutura.
• Estratégia de cache ineficiente: Nessa abordagem, uma camada de cache mal implementada pode resultar em um maior custo para a aplicação. Como as páginas são estáticas, a renderização de dados do usuário pode prejudicar a efetividade da estratégia de cache.
• Inatividade na renderização da página: Devido ao SSR trazer a maior parte das informações prontas e possibilitar uma exibição mais rápida da tela, há o risco de um JavaScript grande demorar muito tempo para ser baixado, resultando em um tempo significativo de inatividade da tela antes que o usuário possa interagir efetivamente com ela.

Conclusão

Em suma, o Server Side Rendering (SSR) é uma estratégia amplamente utilizada no mercado, com vantagens e desvantagens a serem consideradas. Facilitando a indexação de conteúdo, proporcionando um carregamento mais rápido da página e sendo ideal para sites estáticos, o SSR oferece benefícios significativos. No entanto, é importante estar ciente das desvantagens, como problemas de compatibilidade de navegador, alto uso de processamento no backend, custo de infraestrutura, estratégias de cache ineficientes e possíveis períodos de inatividade na renderização da página.

Ao decidir adotar o SSR, é essencial ponderar cuidadosamente sobre as necessidades e requisitos específicos do projeto. Uma análise aprofundada dos benefícios e desafios pode ajudar a determinar se o SSR é a melhor abordagem para o desenvolvimento do frontend.

Lembrando que o SSR não é a única opção disponível. É importante explorar outras estratégias, como o Client Side Rendering (CSR) e até mesmo a combinação de ambas em abordagens híbridas, dependendo do contexto e das necessidades do projeto.

Em última análise, a escolha entre SSR, CSR ou uma combinação de ambas depende dos objetivos, requisitos e restrições específicas do projeto. Ao considerar todos esses aspectos, os desenvolvedores e arquitetos de sistemas podem tomar decisões informadas para fornecer uma experiência de usuário otimizada e eficiente.

Gostou deste artigo sobre Server Side Rendering (SSR)? Compartilhe sua opinião nos comentários abaixo! Adoraríamos ouvir suas experiências e perspectivas sobre o assunto. Se achou o conteúdo útil, não se esqueça de curtir e compartilhar com seus colegas desenvolvedores. Além disso, se quiser receber mais conteúdos relacionados é só nos seguir. Obrigado pelo apoio!