A otimização das Core Web Vitals no site do The Economic Times melhorou significativamente a experiência do usuário e reduziu significativamente a taxa de rejeição em todo o site.
Com a melhoria das velocidades de Internet, os usuários esperam que os sites respondam e se comportem mais rápido do que nunca. O The Economic Times tem mais de 45 milhões de usuários ativos por mês. Ao otimizar as Core Web Vitals em todo o domínio, em páginas AMP e não AMP, conseguimos reduzir significativamente as taxas de rejeição e melhorar a experiência de leitura.
Como medir o impacto
Focamos em Largest Contentful Paint (LCP) e Cumulative Layout Shift (CLS), já que eles são os mais importantes para oferecer uma ótima experiência de leitura aos nossos usuários. Depois de implementar vários correções de desempenho, conforme descrito abaixo, o The Economic Times conseguiu melhorar significativamente as métricas de relatório do Chrome User Experiments (CrUX) em poucos meses.
No geral, o CLS melhorou em 250%, de 0,25 para 0,09. No geral, o LCP melhorou em 80%, de 4,5 segundos para 2,5 segundos.
Além disso, os valores de LCP na faixa "Ruim" foram reduzidos em 33% de outubro de 2020 a julho de 2021:
Além disso, os valores de CLS na faixa "Ruim" foram reduzidos em 65%, e os valores de CLS na faixa "Bom" aumentaram em 20% no mesmo período:
O resultado foi que o The Economic Times, que antes não atendia aos limites das Core Web Vitals, agora passou por todos os limites das Core Web Vitals em toda a origem e reduziu a taxa de rejeição em 43% no geral.
O que é LCP e como melhoramos?
O maior elemento é o mais relevante para melhorar a experiência do usuário e reconhecer a velocidade de carregamento. Métricas de desempenho como a First Contentful Paint (FCP) capturam apenas a experiência inicial do carregamento da página. Por outro lado, a LCP informa o tempo de renderização da maior seção de imagem, texto ou vídeo visível para o usuário.
Além de mudar para um provedor de DNS mais rápido e otimizar imagens, confira algumas das técnicas que aplicamos para melhorar a LCP.
Solicitações críticas primeiro
Como todos os navegadores modernos limitam o número simultâneo de solicitações, os desenvolvedores precisam priorizar o carregamento do conteúdo mais importante. Para carregar uma página da Web complexa, precisamos fazer o download de recursos como elementos de cabeçalho, CSS, recursos JavaScript, imagem principal, corpo do artigo, comentários, outras notícias relacionadas, rodapé e anúncios. Avaliamos quais elementos eram necessários para o LCP e oferecemos a preferência de carregar esses itens primeiro para melhorar o LCP. Também adiamos as chamadas que não faziam parte da renderização inicial da página.
Aparência do texto
Testamos a propriedade font-display, porque ela afeta a LCP e a CLS. Tentamos font-display: auto; e depois mudamos para font-display: swap;. Isso renderiza o texto inicialmente na fonte mais adequada e disponível e, em seguida, muda para a fonte quando ela é transferida por download. Isso resultou em uma renderização rápida do texto, independente da velocidade da rede.
Melhor compressão
O Brotli é um algoritmo de compactação alternativo ao Gzip e Deflate desenvolvido pelo Google. Substituímos nossas fontes e recursos e mudamos a compactação do servidor de Gzip para Brotli para reduzir o impacto ambiental:
- Os arquivos Javascript são 15% menores do que com o Gzip.
- Os arquivos HTML são 18% menores do que com o Gzip.
- Os arquivos CSS e de fontes são 17% menores do que com o Gzip.
Pré-conectar a domínios de terceiros
O preconnect precisa ser usado com cuidado, porque pode ocupar um tempo valioso da CPU e atrasar outros recursos importantes, especialmente em conexões seguras.
No entanto, se for sabido que uma busca por um recurso em um domínio de terceiros vai ocorrer, preconnect é bom. Se isso acontecer apenas ocasionalmente em um site com tráfego intenso, o preconnect poderá acionar trabalhos TCP e TLS desnecessários. Portanto, dns-prefetch era mais adequado para recursos de terceiros, como mídias sociais, análises etc., para realizar pesquisas DNS com antecedência.
Dividir o código em partes
Na cabeça do site, carregamos apenas os recursos que contêm uma parte essencial da lógica de negócios ou que eram essenciais para a renderização da página acima da dobra. Além disso, dividimos nosso código em partes com a divisão de código. Isso nos ajudou a melhorar ainda mais a LCP da página.
Armazenamento em cache melhor
Para todas as rotas front-end, adicionamos uma camada Redis que servia modelos do cache. Isso reduz o tempo de computação no servidor e cria toda a interface em cada solicitação, diminuindo o LCP em solicitações subsequentes.
Resumo das metas e conquistas do LCP
Antes de iniciar o projeto de otimização, a equipe comparou a pontuação da LCP em 4,5 segundos (para a 75ª percentila dos usuários, com base nos dados de campo do relatório do CrUX). Após o projeto de otimização, ele foi reduzido para 2,5 segundos.
O que é o CLS e como ele foi melhorado?
Você já notou algum movimento inesperado do conteúdo da página ao navegar em um site? Uma das causas é o carregamento assíncrono de mídia (imagens, vídeos, anúncios etc.) na página com dimensões desconhecidas. Assim que os recursos de mídia são carregados, eles mudam o layout da página.
Vamos abordar as medidas que tomamos para melhorar o CLS no site do The Economic Times.
Usar marcadores de posição
Usamos um marcador de posição estilizado para blocos de anúncios e elementos de mídia de dimensões conhecidas para evitar mudanças de layout quando a biblioteca de anúncios carrega e renderiza anúncios na página. Isso garante que as mudanças de layout sejam eliminadas ao reservar espaço para o anúncio.
Dimensões de contêineres definidas
Especificamos dimensões explícitas para todas as imagens e contêineres para que o mecanismo do navegador não precise calcular a largura e a altura dos elementos do DOM quando eles estiverem disponíveis. Isso evitou mudanças desnecessárias no layout e trabalho extra de pintura.
Resumo das metas e conquistas de CLS
Antes de iniciar o projeto de otimização, a equipe comparou a pontuação de CLS com 0,25. Conseguimos reduzir significativamente o valor para 90% a 0,09.
O que é o First Input Delay (FID) e como ele foi melhorado?
O First Input Delay é a métrica que rastreia a capacidade de resposta de um site à entrada do usuário. A principal causa de uma pontuação FID ruim é o trabalho pesado de JavaScript que mantém a linha de execução principal do navegador ocupada, o que pode atrasar as interações do usuário. Melhoramos o FID de várias maneiras.
Dividir tarefas longas do JavaScript
Tarefas longas são aquelas com 50 milissegundos ou mais. Tarefas longas ocupam a linha de execução principal do navegador e impedem que ele responda à entrada do usuário. Dividimos as tarefas de execução longa em tarefas menores sempre que possível, o que ajudou a reduzir o inchaço do JavaScript.
Adiar o JavaScript não usado
Priorizamos o conteúdo da página em vez de scripts de terceiros, como o Google Analytics, para que a página seja mais responsiva. No entanto, há algumas limitações em algumas bibliotecas, já que elas precisam ser carregadas no documento <head> para rastrear com precisão a jornada do usuário.
Reduzir polyfills
Reduzimos nossa dependência de alguns polyfills e bibliotecas, já que os navegadores oferecem suporte a APIs modernas e menos usuários estão usando navegadores legados, como o Internet Explorer.
Anúncios de carregamento lento
O carregamento lento de anúncios abaixo da dobra ajudou a reduzir o tempo de bloqueio da linha de execução principal e, assim, melhorou o FID.
Resumo das metas e conquistas do FID
Com experimentos de rotina, conseguimos reduzir nosso FID de 200 ms para menos de 50 ms hoje.
Como evitar regressões
A Economics Times planeja introduzir verificações de desempenho automatizadas na produção para evitar regressões de desempenho da página. Eles planejam avaliar o Lighthouse-CI para automatizar os testes de laboratório, o que pode evitar regressões na ramificação de produção.