Como o The Economic Times ultrapassou os limites das Principais métricas da Web e melhorou a taxa de rejeição em 43%

A otimização das Core Web Vitals no site do The Economic Times melhorou significativamente a experiência do usuário e reduziu substancialmente a taxa de rejeição em todo o site.

Anshu Sharma
Anshu Sharma
Prashant Mishra
Prashant Mishra
Sumit Gugnani
Sumit Gugnani

Como a velocidade da Internet melhora a cada dia, os usuários esperam que os sites respondam e se comportem mais rápido do que nunca. O The Economic Times lida com 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.

Avaliação do impacto

Focamos na Maior exibição de conteúdo (LCP) e na Mudança de layout cumulativa (CLS), que são os itens mais importantes para oferecer uma ótima experiência de leitura aos usuários. Depois de implementar várias correções de desempenho, conforme descrito abaixo, o The Economic Times conseguiu melhorar significativamente as métricas do relatório de experimentos do usuário (CrUX, na sigla em inglês) do Chrome em alguns meses.

No geral, a CLS melhorou em 250%, de 0,25 para 0,09. No geral, a LCP melhorou em 80%, de 4,5 segundos para 2,5 segundos.

Além disso, os valores de LCP no intervalo "Ruim" foram reduzidos em 33% de outubro de 2020 a julho de 2021:

Distribuições de LCP agrupadas por mês, a partir de outubro de 2020 e terminando em julho de 2021. A quantidade de valores de LCP classificados como "Ruim" foi reduzida de 15,03% para 10,08%.

Além disso, os valores de CLS no intervalo "Ruim" foram reduzidos em 65% e os valores de CLS no intervalo "Bom" aumentaram em 20% no mesmo período:

Distribuições de CLS agrupadas por mês, começando em outubro de 2020 e terminando em julho de 2021. A quantidade de valores de CLS classificados como "Ruim" foi reduzida de 25,92% para 9%, e a quantidade de valores de CLS classificados como "Bom" aumentou de 62,62% para 76,5%.

Como resultado, o The Economic Times, que antes não atingia os limites das Core Web Vitals, passou a ultrapassar os limites em toda a origem e reduziu as taxas de rejeição em 43% no geral.

Uma animação de antes e depois da página de artigo do The Economic Times.

O que é a LCP e como melhoramos ela?

O elemento maior é o mais relevante para melhorar a experiência do usuário e reconhecer a velocidade de carregamento. Métricas de desempenho, como a Primeira exibição de conteúdo (FCP, na sigla em inglês), capturam apenas a experiência inicial de 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, estas são algumas das técnicas que abordamos 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 essencial primeiro. Para carregar uma página da Web complexa, precisamos fazer o download de recursos como elementos de cabeçalho, CSS, recursos de JavaScript, imagem principal, corpo do artigo, comentários, outras notícias relacionadas, rodapé e anúncios. Avaliamos quais elementos eram necessários para a LCP e demos a preferência de carregar esses itens primeiro para melhorar a LCP. Também adiamos as chamadas que não faziam parte da renderização inicial da página.

Aparência do texto

Fizemos experimentos com a propriedade font-display, já que isso afeta a LCP e CLS. Tentamos font-display: auto; e depois mudamos para font-display: swap;. Isso renderiza o texto inicialmente na fonte correspondente e disponível e alterna para a fonte quando o download é concluído. Isso resultou na renderização do texto rápida, independentemente da velocidade da rede.

Melhor compressão

O Brotli é um algoritmo de compactação alternativo ao Gzip e ao Deflate desenvolvido pelo Google. Substituímos nossas fontes e recursos e mudamos a compactação do servidor de Gzip para o Brotli, o que ocupa um espaço menor:

  • Os arquivos JavaScript são 15% menores do que os do Gzip.
  • Os arquivos HTML são 18% menores do que os do Gzip.
  • Arquivos de fonte e CSS são 17% menores do que com o Gzip.

Pré-conexão a domínios de terceiros

O preconnect precisa ser usado com cuidado, porque ainda pode consumir um tempo de CPU valioso e atrasar outros recursos importantes, especialmente em conexões seguras.

No entanto, se souber que vai ocorrer uma busca de um recurso em um domínio de terceiros, preconnect será um padrão. Se isso só acontecer ocasionalmente em um site de tráfego intenso, o preconnect poderá acionar um trabalho desnecessário de TCP e TLS. Assim, o dns-prefetch era mais adequado para recursos de terceiros, como mídias sociais, análises etc., para realizar buscas DNS com antecedência.

Dividir código em partes

No cabeçalho do site, carregamos somente os recursos que contêm uma parte essencial da lógica de negócios ou que são 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 aprimorado

Para todas as rotas de front-end, adicionamos uma camada do Redis que disponibilizava modelos do cache. Isso reduz o tempo de computação no servidor e cria toda a IU em cada solicitação, diminuindo a LCP nas solicitações subsequentes.

Resumo das metas e conquistas da LCP

Antes de iniciar o projeto de otimização, a equipe comparou a pontuação de LCP em 4,5 segundos (para o 75o percentil dos usuários, com base nos dados de campo do relatório do CrUX). Após o projeto de otimização, ela foi reduzida para 2,5 segundos.

Distribuições de LCP de setembro de 2020 a junho de 2021. No geral, o 75o percentil dos valores de LCP observados no Relatório de experiência do usuário do Chrome mostrou uma redução de 8,97% nos valores de LCP "Ruim". A redução geral no tempo de LCP no 75o percentil foi de 200 milissegundos, com 77,63% dos valores de LCP ficando no intervalo "Bom".
Fonte: relatório CrUX do The Economic Times LCP geral

O que é CLS e como o aprimoramos?

Você já notou algum movimento inesperado do conteúdo da página ao navegar em um site? Uma das causas para esse problema é 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, o layout da página é alterado.

Vamos abordar as medidas que tomamos para melhorar a 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 de página. Isso garante que as mudanças de layout sejam eliminadas ao reservar espaço para o anúncio.

Uma comparação lado a lado do site do The Economic Times em um smartphone. À esquerda, um marcador cinza é reservado para a imagem principal do artigo. À direita, o marcador é substituído pela imagem carregada.

Dimensões do contêiner definidas

Especificamos as dimensões explícitas de todas as imagens e contêineres para que o mecanismo do navegador não precise calcular a largura e a altura dos elementos DOM quando eles estiverem disponíveis. Isso evitou mudanças desnecessárias de layout e trabalhos extras de pintura.

Resumir as metas e conquistas da CLS

Antes de iniciar o projeto de otimização, a equipe comparou a pontuação de CLS como 0,25. Conseguimos reduzi-la significativamente em 90%, para 0,09.

Distribuições de CLS mostradas no Chrome User Experience Report. 76% dos valores de CLS são "Bom", 15% são "Razoáveis" e 9% são "Ruins". Em geral, o 75o percentil das experiências do usuário no site do The Economic Times apresentou um CLS de 0,09.

O que é latência na primeira entrada (FID, na sigla em inglês) e como o aprimoramos?

Latência na primeira entrada é a métrica que rastreia a capacidade de resposta de um site à entrada do usuário. A causa principal de uma pontuação de FID ruim é o trabalho pesado do JavaScript, que mantém a linha de execução principal do navegador ocupada, o que pode atrasar as interações do usuário. Melhoramos a FID de várias maneiras.

Dividir tarefas longas de JavaScript

Tarefas longas duram 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 tarefas de longa duração em tarefas menores sempre que possível mediante solicitação do usuário, o que ajudou a reduzir a sobrecarga do JavaScript.

Tempo de CPU detalhado por tipo de atividade no painel de desempenho do DevTools do Chrome. Foram gastos 143 milissegundos programando o carregamento de recursos. Foram gastos 4.553 milissegundos no JavaScript. Foram gastos 961 milissegundos no trabalho de renderização. Foram gastos 191 milissegundos nas operações de pintura. 1.488 milissegundos em tarefas do sistema, com 3.877 milissegundos de tempo de inatividade. O período total do intervalo foi 11.212 milissegundos.

Adiar JavaScript não utilizado

Priorizamos o conteúdo da página em vez de scripts de terceiros, como análises para manter a página mais responsiva. No entanto, algumas bibliotecas têm algumas limitações, 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 determinados polyfills e bibliotecas, já que os navegadores são compatíveis com APIs modernas e menos usuários usam navegadores legados, como o Internet Explorer.

Anúncios com 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 a FID.

Resumo das metas e conquistas da FID

Usando experimentos de rotina, conseguimos reduzir nossa FID de 200 ms para menos de 50 ms hoje.

Distribuições de FID exibidas no Chrome User Experience Report. 86% dos valores de CLS são &quot;Bom&quot;, 10% são &quot;Razoáveis&quot; e 4% são &quot;Ruins&quot;. Em geral, o 75o percentil das experiências do usuário no site do The Economic Times apresentou uma FID de 44 milissegundos.

Prevenção de regressões

O Economics Times planeja introduzir verificações de desempenho automatizadas na produção para evitar regressões de desempenho da página. A empresa pretende avaliar o Lighthouse-CI para automatizar os testes de laboratório, o que pode evitar regressões na ramificação de produção.