À medida que mais empresas adotam iniciativas digitais, os negócios precisam trabalhar arduamente não apenas para encontrar uma audiência para seu site, mas também para manter os usuários engajados e interessados. No entanto, competir por cliques está se tornando cada vez mais desafiador, deixando pouco espaço para baixa performance em velocidade e SEO, e aumentando a importância das mídias sociais para direcionar tráfego e obter conversões. É por isso que ferramentas como geração de site estático (SSG) e renderização do lado do servidor (SSR) estão ganhando (ou no caso do SSR, reconquistando) popularidade como forma de otimizar a performance, SEO, compartilhamento em mídias sociais e outros impulsionadores de negócios.
Aprender sobre SSR e SSG e quando usá-los pode ajudar negócios digitais a pesar todas as opções possíveis para melhorar a experiência do usuário e impulsionar seus resultados. Este post explicará os fundamentos de SSR e SSG, seus prós e contras, e os vários fatores que as empresas devem considerar ao determinar como renderizar páginas web.
O que são SSR e SSG?
SSR e SSG são opções de renderização para gerar HTML antes de ser entregue ao navegador do cliente, permitindo que os usuários vejam a página mais rapidamente do que fariam durante a renderização do lado do cliente, onde os usuários veem apenas uma página em branco enquanto esperam o navegador compilar e renderizar JavaScript. Além de onde o conteúdo é renderizado, SSR e SSG diferem do CSR em quando, como e que tipo de conteúdo é renderizado.
- No SSR, um cliente solicita 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 entregue mediante solicitação do cliente.
- No CSR, o cliente solicita conteúdo e o servidor retorna uma página HTML em branco para o navegador do cliente, que compila e executa JavaScript e faz chamadas de API.
Embora o CSR tenha sido o método de renderização mais frequentemente usado desde a introdução dos frameworks JavaScript, páginas web cada vez mais complexas com uso intenso de conteúdo dinâmico extraído de numerosas APIs resultaram em tempos de carregamento cada vez mais longos, frustrando usuários com expectativas de performance cada vez mais altas. Além disso, o CSR pode impactar negativamente os rankings de mecanismos de busca e o compartilhamento em mídias sociais, dois riscos que muitas empresas não podem se dar ao luxo de correr enquanto enfrentam forte concorrência pelo engajamento do usuário medido por visualizações de página.
Como a renderização impacta os resultados dos websites?
Direcionando tráfego
Fazer a escolha certa entre SSR, SSG e CSR pode desempenhar um papel enorme em um dos maiores determinantes do tráfego orgânico: os rankings de SEO. Estatísticas citadas em um post do blog da Forbes de 2017 afirmaram que a primeira página dos resultados de mecanismos de busca pode capturar até 92% do tráfego web, e apenas 15% dos usuários clicarão em um anúncio ou tentarão uma busca diferente se estiverem insatisfeitos com os resultados da primeira página. Os algoritmos que determinam os rankings de SEO levam em conta não apenas a qualidade e relevância do conteúdo, mas fatores como velocidade, segurança, adaptação para dispositivos móveis e, 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 busca.
Infelizmente, a rastreabilidade pode ser difícil de alcançar com CSR. Como o Google Developers explica em “Rendering on the Web”, “os rastreadores podem entender JavaScript, mas frequentemente há limitações que vale a pena conhecer em como eles renderizam. A renderização do lado do cliente pode funcionar, mas geralmente não sem testes e trabalho adicional.”
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 direcionar tráfego. Quando os links são compartilhados em mídias sociais, uma pré-visualização deve aparecer com uma imagem e título para atrair os usuários para o site. Essas pré-visualizações são geradas por rastreadores de sites de mídia social que escaneiam o HTML em busca de meta tags que descrevem como a pré-visualização deve parecer. No entanto, com a renderização do lado do cliente, um arquivo HTML em branco será enviado do servidor, resultando em uma pré-visualização genérica que é a mesma para cada página do site ou nenhuma pré-visualização, tornando o link menos atraente para os visualizadores.
Interação do usuário
Dadas as altas expectativas dos usuários atuais, mesmo pequenas 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”, descobriu que uma melhoria de 0,1s na velocidade móvel proporcionou melhorias nas conversões, taxas de rejeição, engajamento do cliente e tamanho dos pedidos em várias indústrias. Além disso, afirmou que sites lentos tornaram mais de 40% dos usuários de e-commerce menos propensos a fazer uma compra, e mais de 30% menos propensos a retornar ao site.
Embora a necessidade de velocidade seja óbvia para a maioria dos proprietários de sites, o que constitui a velocidade da página é um pouco mais complicado. Tipo de dispositivo, localização do usuário, conexão com a Internet e condições de rede desempenham um papel na velocidade experimentada pelo usuário, resultando em métricas que podem variar significativamente de usuário para usuário, especialmente quando a renderização é feita do lado do 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 os processos do lado do servidor iniciarem. Essas métricas incluem:
- TTFB, ou Time to First Byte: o tempo entre solicitar uma página e o primeiro byte carregado por um servidor ou outro recurso de rede.
- FP, ou First Paint: o tempo que leva para qualquer pixel carregar na tela de um usuário após solicitar uma página web.
- FCP, ou First Contentful Paint: o tempo que leva para qualquer elemento do conteúdo solicitado da página carregar na tela de um usuário.
- TTI, ou Time To Interactive: o tempo desde quando uma página começa a carregar até quando pode reagir de forma confiável à entrada do usuário.
Embora a renderização do lado do cliente tenha um TTFB rápido, FCP e TTI podem levar muito tempo, um problema que é agravado para sites com muito conteúdo dinâmico ou chamadas de API, e usuários com uma conexão de Internet ruim. Como resultado, as experiências móveis sofrerão e usuários impacientes podem navegar para longe da página web antes de interagir ou mesmo visualizar o conteúdo que solicitaram.
Quais são os prós e contras de SSR e SSG?
Embora o CSR forneça um TTFB rápido e grande flexibilidade para aplicações web, sites que dependem de SEO, compartilhamento em mídias sociais e usuários móveis para tráfego podem querer considerar um método de renderização diferente. Se SSR ou SSG é melhor para o seu site depende em grande parte dos requisitos específicos do site. Como em toda tecnologia web, existem prós e contras para ambos os métodos.
SSR
Embora o SSR seja um método de renderização mais antigo que o CSR, ele ganhou recentemente popularidade renovada. Além de ser melhor para SEO e mídias sociais, o SSR aproveita a conexão confiável de Internet do servidor para renderizar a maior parte do conteúdo do site, resultando em um FCP mais rápido, especialmente para usuários com conectividade ruim. O conteúdo em sites renderizados no servidor também é o mais atualizado possível, tornando o SSR ótimo tanto para sites dinâmicos quanto para sites que atualizam durante as sessões do usuário, como sites de notícias.
A desvantagem do SSR é que a renderização no servidor pode ser cara e intensiva em recursos. O HTML dinâmico não pode ser armazenado em cache por CDNs estáticas, resultando em viagens mais longas de ida e volta ao servidor e um TTFB mais lento. Os tempos de segundo carregamento, ou o tempo que leva para carregar uma nova página no mesmo site, também são mais lentos, já que o servidor precisa recuperar e compilar PHP e entregar HTML para cada nova página. Uma nova técnica, a renderização universal, evita esse problema com uma combinação de renderização do lado do servidor e do cliente, mas requer que o JavaScript seja renderizado no navegador após o HTML ser entregue, o que significa que usuários com conectividade ruim podem experimentar uma longa espera entre quando o conteúdo está visível e quando está interativo.
Prós do SSR:
- Amigável para mídias sociais.
- Amigável para SEO.
- FCP e FP rápidos.
- Conteúdo atualizado.
Contras do SSR:
- TTFB lento.
- Cargas de trabalho intensivas para o servidor.
- Não pode ser armazenado em cache por CDNs tradicionais.
- Navegar pelo site é lento sem renderização universal.
- TTI é mais longo que FTP com renderização universal.
SSG
A geração de site estático é outra alternativa ao CSR que pode parecer um retorno a métodos de desenvolvimento mais antigos, mas melhorias recentes nos SSGs estão tornando-os uma opção cada vez mais popular. Embora a atualização de sites gerados estaticamente tenha sido uma tarefa árdua, a automação facilitou significativamente esse ônus de manutenção. Novas ferramentas como NextJS e GatsbyJS permitem que os desenvolvedores adicionem mais funcionalidades ricas para o cliente aos sites, e a ampla variedade de SSGs de hoje suporta muitas linguagens e frameworks diferentes. E gerar no momento da compilação produz tempos de carregamento incrivelmente rápidos, tornando os SSGs ideais para acompanhar as altas expectativas de performance dos usuários atuais. Finalmente, os SSGs não dependem de bancos de dados, melhorando sua segurança e permitindo que vivam inteiramente em CDNs para escalabilidade massiva durante picos de performance.
Embora existam claras vantagens no SSG, renderizar no momento da compilaçã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 purga o conteúdo, ele pode nem sempre estar atualizado. Finalmente, arquivos HTML individuais devem ser gerados para cada URL em um site com cada compilação do site, então um site com milhares de páginas terá velocidades de compilação muito lentas, tornando o SSG uma escolha impraticável.
Prós do SSG:
- Tempos de carregamento rápidos.
- Seguro.
- Amigável para mídias sociais.
- Amigável para SEO.
- Amigável para dispositivos móveis.
- Escalabilidade.
Contras do SSG:
- Problemático para sites com muitas páginas.
- Sem personalização.
- O conteúdo pode estar desatualizado.
Entendendo SSR e SSG em edge computing
Mudanças no comportamento do usuário e técnicas de desenvolvimento renovaram o interesse na Renderização do Lado do Servidor (SSR) e Geração de Site Estático (SSG) como alternativas à renderização do lado do cliente. Cada abordagem vem com compensações, mas aproveitar edge computing pode ajudar a mitigar alguns dos desafios associados ao SSR e SSG.
Para SSR, cargas de trabalho intensivas do servidor podem ser reduzidas usando edge functions para pré-renderizar páginas no node de edge mais próximo antes de entregá-las ao cliente solicitante. Essa abordagem melhora os tempos de resposta e reduz a carga nos servidores de origem. Além disso, as capacidades do Edge Cache permitem o cache dinâmico, permitindo que o conteúdo acessado com frequência seja entregue de forma mais eficiente, levando a tempos de carregamento mais rápidos.
Com SSG, armazenar em cache conteúdo estático na edge melhora tanto a performance quanto a escalabilidade. Ao armazenar páginas pré-geradas mais próximas dos usuários, a latência é reduzida e as velocidades de entrega são aprimoradas. Opções flexíveis de cache e purga garantem que o conteúdo permaneça atualizado enquanto mantém os benefícios da distribuição na edge.
Integrar essas técnicas em um ambiente de edge computing permite que os desenvolvedores otimizem estratégias de renderização para velocidade, eficiência e custo-benefício, adaptando-se às demandas modernas de performance web.