Resumo: atraso de renderização
- O atraso de renderização é o intervalo entre o navegador receber o HTML e o utilizador ver a página concluída. Na quase totalidade dos sites modernos, é dominado pela execução de JavaScript, não pelo trânsito de rede.
- O maior culpado são os scripts de terceiros síncronos carregados no head: gestor de tags, analytics e widgets de chat que bloqueiam o commit da árvore de renderização.
- As métricas Web Vitals (LCP, FID, INP) medem os sintomas observáveis, mas não indicam qual script específico está a atrasar a sua página. A monitorização em sessão do tempo de execução dos scripts, essa sim, indica.
Se já visitou alguma página web moderna, terá reparado que, por vezes, alguns elementos no ecrã (como imagens ou campos de entrada) carregam antes de outras partes do site. As páginas web carregam frequentemente por etapas, com alguns elementos a surgir apenas após um atraso inicial. Este escalonamento pode ser intencional para melhorar o desempenho do site, mas também pode ser apenas um efeito secundário da forma como o navegador processa a página.
Se a parte lenta for o próprio download, verifique a unidade antes de comparar números. Um navegador que mostra MB/s e um plano de internet vendido em Mbps usam unidades diferentes; Mbps, Mb/s e MB/s exigem uma conversão de 8 para 1.
Lazy loading
Lazy loading é uma técnica usada por programadores web para atrasar o carregamento de elementos menos importantes na página. Coisas como imagens, vídeos e conteúdo incorporado normalmente carregam por último, ou só quando são realmente necessários pela página. Em vez de carregar tudo à partida (o que pode sobrecarregar o navegador com um monte de pedidos), o navegador espera para carregar o conteúdo fora do ecrã até o utilizador se aproximar dele ao percorrer a página. Ao não carregar todo este conteúdo, sempre, o carregamento inicial da página é muito mais rápido e parece mais leve.
Por exemplo, este artigo pode carregar primeiro o banner superior e o ícone do autor, mas atrasar o carregamento das imagens perto do rodapé do site até se rolar até lá. Isto acelera o carregamento inicial, uma vez que apenas a primeira imagem está a carregar.
Do ponto de vista da experiência do utilizador, o lazy loading é claramente benéfico: vê as coisas importantes mais depressa, e a largura de banda não é desperdiçada em imagens e vídeos que o utilizador poderá nunca sequer ver. Isto melhora o First Contentful Paint da página, uma métrica do navegador usada para medir a rapidez com que o primeiro elemento aparece no ecrã.
Podem existir implementações negativas de lazy loading, e no fim de contas depende do programador da página garantir que é usado corretamente. Por exemplo, qualquer coisa acima da dobra (ou seja, qualquer conteúdo visível sem ser preciso rolar a página) não deveria ser carregada com lazy loading. Outra preocupação é o layout shifting, que acontece quando o espaço de uma imagem não é reservado na página e esta carrega mais tarde, empurrando todo o conteúdo para baixo.
Renderização do lado do cliente e hidratação
As aplicações web modernas são hoje sobretudo JavaScript, o que significa que o conteúdo é frequentemente gerado e só depois exibido ao utilizador. Nas frameworks de renderização do lado do cliente (CSR), como React, Angular e Vue, o servidor envia uma página HTML muito básica, e depois espera que o navegador gere o conteúdo. Isto significa que, no primeiro carregamento de uma página, pode ver apenas um ecrã em branco ou um indicador de carregamento enquanto o navegador transfere e gera o conteúdo.
Esta implementação pode frequentemente levar a uma perceção negativa do desempenho do site, uma vez que os utilizadores podem pensar que nada está a carregar ou que está a demorar demasiado tempo. A métrica First Contentful Paint de que falámos antes pode ficar significativamente atrasada numa situação puramente CSR, porque nada de relevante aparece na página até muito, muito mais tarde.
Resolver isto com renderização do lado do servidor
Para mitigar alguns dos atrasos de espera da renderização do lado do cliente, muitas frameworks web utilizam a renderização do lado do servidor (SSR). Isto significa que um servidor envia ao navegador uma página web já completamente desenvolvida (para que se veja conteúdo de imediato), e depois hidrata-a mais tarde com elementos mais interativos.
A hidratação continua a exigir a geração desse conteúdo do lado do cliente no navegador, mas significa apenas que os utilizadores não ficam a olhar para um ecrã em branco entretanto. Por sua vez, isto melhora o desempenho percecionado da página e reduz aquele pensamento de “porque é que esta página está tão lenta?”.
Dito isto, o SSR e a hidratação ainda podem introduzir problemas num site se não forem implementados corretamente. O problema do content flickering ocorre quando o servidor não conhece o utilizador ou o contexto que este já tem (por exemplo, se um utilizador já está autenticado ou não), acabando por lhe apresentar uma versão genérica do site. Assim que o site é hidratado e percebe que o utilizador está autenticado, pode substituir partes da interface por conteúdo personalizado ou atualizado. Embora não seja tão mau como uma página completamente em branco, estas alterações de conteúdo a meio do processo podem ser distrativas e confundir momentaneamente o utilizador.
Do ponto de vista da experiência do utilizador, o objetivo é minimizar o atraso antes de os utilizadores verem conteúdo útil. Se estiver a usar CSR, mantenha o JavaScript enxuto e inclua um indicador de carregamento ou skeleton bem concebido, para que os utilizadores saibam que há conteúdo a caminho. Melhor ainda, usar SSR para a vista inicial garante que os utilizadores veem primeiro algo e recebem depois o seu conteúdo.
Veja isto no seu próprio site
O atraso de renderização é frequentemente atribuído à latência de rede, mas a causa real nos sites modernos é o JavaScript de terceiros não auditado a bloquear o caminho de renderização. O cside mostra exatamente que scripts estão a atrasar a sua página em cada sessão real de utilizador. Existe um plano gratuito disponível.
Recursos que bloqueiam a renderização
Nem todos os atrasos se devem a scripts; também podem resultar da forma como o navegador lida com recursos críticos como CSS e tipos de letra. Os navegadores não sabem, por natureza, priorizar estes recursos, ou podem só perceber que o conteúdo está estilizado mais tarde, levando a que o conteúdo apareça na página com o tipo de letra ou estilo errado.
O CSS é o exemplo mais clássico dos problemas de bloqueio de renderização. Normalmente, os navegadores atrasam a renderização do conteúdo da página até o CSS ser transferido e processado, mas se o seu ficheiro CSS for demasiado grande ou complexo, quaisquer elementos que dependam desse ficheiro CSS aparecerão tarde, até serem carregados. Manter o CSS otimizado e ter o estilo básico do layout já definido faz com que o conteúdo apareça mais cedo e melhora o tempo de carregamento percecionado pelo utilizador.
O tipo de letra de um site também pode atrasar o aparecimento do texto, embora muitas vezes de formas mais subtis. Quando um site usa um tipo de letra personalizado (através de @font-face, ou algo como o Google Fonts), os navegadores lidam com eles com cuidado para garantir que não aparece um tipo de letra de recurso. Os navegadores implementaram o “flash de texto invisível”, o que significa que o texto fica escondido até o ficheiro do tipo de letra ser carregado. O texto está, essencialmente, ali, na página, só que não se consegue vê-lo. E se o tipo de letra demorar demasiado tempo a carregar, o utilizador não verá palavra nenhuma.
Equilibrar desempenho e experiência
Os programadores web devem procurar oferecer a página mais rápida possível sem sobressaltar o utilizador com conteúdo sem estilo, texto em falta ou tempos de carregamento longos. Todo o elemento atrasado numa página deve ter uma boa razão para ser atrasado, e esse atraso deve ser gerido na interface através de indicadores de carregamento e placeholders.
