À medida que as empresas adotam iniciativas digitais, elas precisam trabalhar intensamente não apenas para encontrar um público para seu site, mas também para manter os usuários engajados e interessados. Competir por cliques, no entanto, além de estar se tornando cada vez mais desafiador, pois não há mais espaço para baixa performance de velocidade e de SEO, também está promovendo a importância das mídias sociais na geração de tráfego e obtenção de conversões. É por isso que ferramentas como SSG e SSR, do inglês static site generation e server-side rendering, estão ganhando ou, no caso do SSR, recuperando popularidade como uma forma de otimizar o desempenho, o SEO, o compartilhamento em mídias sociais e outros fomentadores de negócios.
Por isso, conhecer melhor o SSR e o SSG e quando usá-los pode ajudar as empresas digitais a considerarem todas as opções possíveis para melhorar a experiência do usuário e alavancar seus resultados financeiros. Neste post, você encontra os conceitos básicos de SSR e SSG, seus prós e contras, bem como os vários fatores que as empresas deveriam considerar ao decidir como renderizar as páginas da web.
O que são SSR e SSG?
O SSR e o SSG são opções de renderização para gerar o HTML antes de ele ser entregue ao navegador do cliente, o que permite aos usuários visualizarem a página mais rapidamente do que se fosse durante uma renderização no cliente – ou CSR, do inglês client-server rendering. Em uma CSR, os usuários visualizam apenas uma página em branco enquanto aguardam até o navegador compilar e renderizar o JavaScript. Além do local onde o conteúdo é renderizado, o SSR e o SSG também diferem do CSR em relação a quando, como e que tipo de conteúdo é renderizado.
- No SSR, um cliente requisita o conteúdo, o HTML dinâmico é pré-renderizado no servidor e a página é entregue ao navegador do cliente.
- No SSG, o HTML estático é renderizado no momento da compilação a partir de templates e conteúdo fornecidos pelo desenvolvedor e, então, será entregue mediante a requisição do cliente.
- No CSR, o cliente requisita o conteúdo e o servidor retorna uma página HTML em branco ao navegador do cliente, que compila e executa o JavaScript e faz as chamadas de API.
Embora o CSR tenha sido o método de renderização usado com mais frequência desde a introdução das estruturas em JavaScript, o aumento da complexidade das páginas da web, com uso intenso de conteúdo dinâmico extraído de várias APIs, resultou em tempos de carregamento muito elevados, causando frustração entre os usuários que possuíam expectativas de desempenho cada vez maiores. Além disso, o CSR pode impactar negativamente as classificações dos mecanismos de busca e o compartilhamento em mídias sociais – dois riscos que muitas empresas sequer pensam em correr, já que enfrentam uma forte concorrência para o engajamento de usuários medido por visualizações de página.
Como a renderização impacta os resultados dos sites?
Aumentando o tráfego
O simples fato de fazer a escolha certa entre SSR, SSG e CSR pode fazer uma imensa diferença em um dos maiores determinantes do tráfego orgânico: as classificações do SEO. As estatísticas apresentadas em umpost da Forbes de 2017 mostraram que a primeira página de resultados do mecanismo de pesquisa pode capturar até 92% do tráfego da web, e apenas 15% dos usuários irão clicar em um anúncio ou tentar uma pesquisa diferente caso fiquem insatisfeitos com a primeira página de resultados. Os algoritmos que determinam as classificações de SEO levam em consideração não apenas a qualidade e a relevância do conteúdo, mas também fatores como velocidade, segurança, compatibilidade com dispositivos móveis e, o mais importante, rastreabilidade. Se os bots não podem rastreá-lo, eles não podem indexá-lo, e isso significa que seu site não aparecerá nos resultados de pesquisa.
Infelizmente, pode ser difícil alcançar a rastreabilidade com o CSR. Como explica o Google Developers no artigoA renderização na web, “os rastreadores podem entender JavaScript, mas geralmente há limitações que vale a pena entendermos a forma como eles renderizam. A renderização no cliente pode funcionar, mas muitas vezes precisam de testes adicionais e trabalho manual”.
Além disso, o CSR não gera pré-visualizações de links precisas – um problema real para sites que dependem do compartilhamento em mídias sociais para aumentar o tráfego. Quando os links são compartilhados nas mídias sociais, deveria aparecer uma pré-visualização com uma imagem e um título para atrair os usuários para o site. Essas pré-visualizações são geradas por rastreadores de sites de mídias sociais que escaneiam o HTML em busca de metatags que descrevem como a pré-visualização deveria aparecer. Com a renderização no cliente, entretanto, um arquivo HTML em branco será enviado do servidor, o que resultará em uma pré-visualização genérica, que é igual para todas as páginas do site, ou absolutamente nenhuma pré-visualização, tornando o link menos atraente para quem os visualizar.
Interação do usuário
Devido às altas expectativas dos usuários de hoje, até mesmo mínimas diferenças na velocidade da página podem ter um grande impacto na interação do usuário. O relatório da Deloitte de 2020, Milliseconds Make Millions, apontou que um aumento de 0,1s na velocidade móvel gerou melhorias nas conversões, nos bounce rates, no envolvimento do cliente e no tamanho dos pedidos em vários segmentos da indústria. Além disso, o relatório afirmou que sites lentos tornaram mais de 40% dos usuários de comércio eletrônico menos propensos a efetuar uma compra, e mais de 30% apresentaram menor probabilidade de retornar ao site.
Em vista disso, embora a necessidade de velocidade seja óbvia para a maioria dos proprietários de sites, o que está por trás da velocidade da página é um pouco mais complicado. Fatores como o tipo de dispositivo, a localização do usuário, a conexão com a internet e as condições de rede desempenham um papel na velocidade experienciada pelo usuário, resultando em métricas que podem variar significativamente de usuário para usuário, especialmente quando a renderização é feita no cliente. Além disso, a velocidade pode ser dividida em várias subcategorias, que refletem não apenas a rapidez com que os usuários podem visualizar o conteúdo, mas o tipo de conteúdo que podem visualizar, se podem interagir com ele e o tempo que leva para que os processos no servidor sejam iniciados. Essas métricas incluem:
- TTFB, ou Time to First Byte: o tempo entre requisitar uma página e o primeiro byte carregado por um servidor ou por outro recurso de rede;
- FP, ou First Paint: o tempo que leva para carregar qualquer pixel na tela de um usuário depois de requisitar uma página da web;
- FCP, ou First Contentful Paint: o tempo que leva para carregar qualquer elemento do conteúdo da página requisitado na tela de um usuário;
- TTI, ou Time to Interactive: o tempo desde quando a página começa a carregar até o momento em que ela pode responder de forma confiável ao input do usuário.
Apesar de a renderização no cliente ter um TTFB rápido, o FCP e o TTI podem demorar muito, um problema que se agrava no caso de sites com uma grande quantidade de conteúdo dinâmico ou chamadas de API e de usuários com uma conexão de internet lenta. Com isso, as experiências móveis serão prejudicadas e os usuários impacientes podem desistir de navegar e sair de uma página antes de interagir ou até mesmo visualizar o conteúdo que solicitaram.
Quais são os prós e os contras do SSR e do SSG?
Mesmo que o CSR forneça um TTFB rápido e grande flexibilidade para aplicações web, os sites que dependem de SEO, compartilhamento em mídias sociais e usuários móveis para gerar mais tráfego talvez queiram avaliar um método de renderização diferente. Se o SSR ou o SSG é a melhor opção para o seu site, vai depender em grande parte dos requisitos específicos daquele site. Isso porque, assim como acontece com toda tecnologia web, existem prós e contras para ambos os métodos.
SSR
Ainda que o SSR seja um método de renderização mais antigo do que o CSR, ele recentemente renovou sua popularidade. Além de ser melhor para o SEO e mídias sociais, o SSR aproveita a conexão de internet confiável do servidor para renderizar a maior parte do conteúdo do site. Como resultado, obtém-se um FCP mais rápido, especialmente para usuários com conectividade mais lenta. Outra vantagem é que o conteúdo em sites renderizados no servidor é o mais atualizado possível, o que torna o SSR excelente tanto para sites dinâmicos quanto para os que são atualizados durante as sessões do usuário, como os sites de notícias.
A desvantagem do SSR, porém, é que a renderização no servidor pode ser cara e consumir muitos recursos. Já que o HTML dinâmico não pode ser armazenado em cache por CDNs estáticas, consequentemente há um aumento no percurso de e para o servidor, além de um TTFB mais lento. Igualmente, o segundo tempo de carregamento – ou seja, o tempo que leva para carregar uma nova página no mesmo site – também é mais lento, já que o servidor precisa recuperar e compilar o PHP para entregar o HTML de cada nova página. Por sua vez, uma nova técnica, a renderização universal, evita esse problema com uma combinação de renderização no servidor e no cliente, mas requer que o JavaScript seja renderizado no navegador depois de o HTML ser entregue – isto é, os usuários com conectividade lenta podem vivenciar uma longa espera entre o momento em que o conteúdo está visível e quando está interativo.
Prós do SSR:
- promoção em mídias sociais;
- SEO friendly;
- FCP e FP rápidos;
- conteúdo atualizado.
Contras do SSR:
- TTFB lento;
- workloads intensivos no servidor;
- não pode ser armazenado em cache por CDNs tradicionais;
- a navegação em um site é lenta sem renderização universal;
- o TTI é maior do que o FTP com renderização universal.
SSG
A criação de sites estáticos é outra alternativa ao CSR que, de certo modo, pode parecer um retorno a métodos de desenvolvimento mais antigos. Porém, as recentes melhorias aos SSGs estão tornando-os uma opção cada vez mais popular. Embora a atualização de sites criados estaticamente já tenha sido uma tarefa complicada, a automação facilitou significativamente essa carga de manutenção. Novas ferramentas, como NextJS e GatsbyJS, permitem que os desenvolvedores adicionem mais funcionalidades ricas no client-side dos sites, e a grande variedade de SSGs de hoje suporta muitas linguagens e estruturas diferentes. Além disso, criar no momento da construção produz tempos de carregamento incrivelmente rápidos, tornando os SSGs ideais para acompanhar as expectativas de alto desempenho dos usuários de hoje. Finalmente, os SSGs não dependem de bancos de dados, melhorando sua segurança e permitindo que eles vivam integralmente em CDNs para escalabilidade massiva durante os picos de desempenho.
Apesar das claras evidências sobre as vantagens do SSG, também é fato que a renderização no momento da construção apresenta alguns problemas. Não é uma boa escolha para sites personalizados, já que o conteúdo é gerado antes que os usuários o solicitem. Dependendo de como um site armazena em cache e limpa o conteúdo, nem sempre ele está atualizado. Finalmente, arquivos HTML individuais devem ser gerados para cada URL de um site com cada construção de site, assim um site com milhares de páginas terá velocidades de construção muito lentas, tornando o SSG uma escolha impraticável.
Prós do SSG:
- tempo de carregamento rápido;
- seguro;
- promoção em mídias sociais;
- SEO friendly;
- compatível com dispositivos móveis;
- escalabilidade.
Contras do SSG:
- problemático para sites com muitas páginas;
- sem personalização;
- possibilidade de conteúdo desatualizado.
SSR e SSG com a Azion
As mudanças nos hábitos do usuário e as técnicas de desenvolvimento reconquistaram o interesse em SSR e SSG como alternativas à renderização no cliente. No entanto, mesmo que a escolha entre um método de renderização e outro sempre envolva algum tipo de tradeoff em termos de prós e contras – quando você precisa optar por um ou outro –, a Plataforma de Edge da Azion pode minimizar as desvantagens do SSG e do SSR.
Os desenvolvedores podem reduzir workloads de SSR intensivos no servidor com o Azion Edge Functions, pois permite pré-renderizar as páginas no edge node mais próximo antes de enviá-las ao cliente que as solicitou. Você ainda conta com o poder do Edge Cache da Azion, um multiplicador de força quando se trata de entregar conteúdo rapidamente por meio de cache dinâmico para obter tempos de carregamento mais rápidos. Além disso, nosso modelo de serverless computing também reduz os custos e o uso porque executa os workloads apenas quando requisitados, assim a cobrança é calculada conforme o uso.
Os clientes da Azion que usam o SSG podem beneficiar-se tanto do desempenho e das vantagens dos custos de armazenamento em cache de seu conteúdo no edge quanto da variedade de opções de armazenamento em cache e limpeza do conteúdo para garantir que esteja o mais atualizado possível.
