Google mostra como corrigir LCP Core Web Vitals

Barry Pollard, defensor do desenvolvedor de desempenho da Web do Google Chrome, explicou como encontrar as causas reais de uma pontuação mais baixa no Contentful Paint e como corrigi-las.

Maior pintura com conteúdo (LCP)

LCP é uma métrica básica de web vitals que mede quanto tempo leva para o maior elemento de conteúdo ser exibido na janela de visualização dos visitantes do site (a parte que um usuário vê em um navegador). Um elemento de conteúdo pode ser uma imagem ou texto.

Para LCP, os maiores elementos de conteúdo são elementos HTML em nível de bloco que ocupam o maior espaço horizontalmente, como parágrafo

títulos (H1 – H6) e imagens (basicamente a maioria dos elementos HTML que ocupam uma grande quantidade de espaço horizontal).

1. Saiba quais dados você está vendo

Barry Pollard escreveu que um erro comum que editores e SEOs cometem depois de ver que o PageSpeed ​​​​Insights (PSI) sinaliza uma página com uma pontuação LCP baixa é depurar o problema na ferramenta Lighthouse ou por meio do Chrome Dev Tools.

Pollard recomenda continuar com o PSI porque ele oferece várias dicas para entender os problemas que causam um baixo desempenho do LCP.

É importante entender quais dados o PSI está fornecendo a você, especialmente os dados derivados do Relatório de experiência do usuário do Chrome (CrUX), que são provenientes de pontuações anônimas de visitantes do Chrome. Existem dois tipos:

1. Dados em nível de URL
2. Dados em nível de origem

As pontuações em nível de URL são aquelas da página específica que está sendo depurada. Os dados em nível de origem são pontuações agregadas de todo o site.

O PSI mostrará dados em nível de URL se houver tráfego medido suficiente para um URL. Caso contrário, mostrará dados em nível de origem (a pontuação agregada de todo o site).

2. Revise a pontuação TTFB

Barry recomenda dar uma olhada na pontuação TTFB (Time to First Byte) porque, em suas palavras, “TTFB é a primeira coisa que acontece com sua página”.

Um byte é a menor unidade de dados digitais para representar texto, números ou multimídia. O TTFB informa quanto tempo levou para um servidor responder com o primeiro byte, revelando se o tempo de resposta do servidor é o motivo do baixo desempenho do LCP.

Ele diz que concentrar esforços na otimização de uma página da web nunca resolverá um problema que está enraizado em uma ferida de TTFB.

Barry Pollard escreve:

“Um TTFB lento significa basicamente uma de duas coisas:

1) Demora muito para enviar uma solicitação ao seu servidor
2) Seu servidor demora muito para responder

Mas o que é (e por quê!) pode ser difícil de descobrir e há algumas razões possíveis para cada uma dessas categorias.”

Barry continuou sua visão geral de depuração do LCP com testes específicos descritos abaixo.

3. Compare o TTFB com o teste de laboratório do Lighthouse

Pollard recomenda testar com o Lighthouse Lab Tests, especificamente a auditoria “Tempo inicial de resposta do servidor”. O objetivo é verificar se o problema do TTFB é repetível para eliminar a possibilidade de os valores do PSI serem um acaso.

Os resultados do laboratório são sintéticos e não baseados em visitas reais de usuários. Sintético significa que eles são simulados por um algoritmo baseado em uma visita acionada por um teste Lighthouse.

Os testes sintéticos são úteis porque são repetíveis e permitem ao usuário isolar uma causa específica de um problema.

Se o Lighthouse Lab Test não replicar o problema, significa que o problema não é o servidor.

Ele aconselhou:

“Uma coisa importante aqui é verificar se o TTFB lento é repetível. Então role para baixo e veja se o teste de laboratório do Lighthouse correspondeu a esse lento TTFB do usuário real quando testou a página. Procure a auditoria “Tempo de resposta inicial do servidor”.

Neste caso foi muito mais rápido – isso é interessante!”

4. Dica de especialista: como verificar se o CDN está ocultando um problema

Barry deu uma dica excelente sobre redes de distribuição de conteúdo (CDNs), como Cloudflare. Uma CDN manterá uma cópia de uma página web em data centers, o que acelerará a entrega das páginas web, mas também mascarará quaisquer problemas subjacentes no nível do servidor.

A CDN não mantém uma cópia em todos os data centers do mundo. Quando um usuário solicita uma página da web, o CDN irá buscá-la no servidor e, em seguida, fará uma cópia dela no servidor mais próximo desses usuários. Portanto, a primeira busca é sempre mais lenta, mas se o servidor for lento para começar, a primeira busca será ainda mais lenta do que entregar a página da web diretamente do servidor.

Barry sugere os seguintes truques para contornar o cache do CDN:

• Teste a página lenta adicionando um parâmetro de URL (como adicionar “?XYZ” ao final do URL).
• Teste uma página que não é comumente solicitada.

Ele também sugere uma ferramenta que pode ser usada para testar países específicos:

“Você também pode verificar se são particularmente países que são lentos – especialmente se você não estiver usando um CDN – com CrUX e o Treo de @alekseykulikov.bsky.social é uma das melhores ferramentas para fazer isso.

Você pode realizar um teste gratuito aqui: treo.sh/sitespeed e rolar para baixo até o mapa e mudar para TTFB.

Se determinados países tiverem TTFBs lentos, verifique quanto tráfego vem desses países. Por motivos de privacidade, o CrUX não mostra volumes de tráfego (a não ser se tiver tráfego suficiente para mostrar), então você precisará analisar suas análises para isso.”

No que diz respeito às conexões lentas de áreas geográficas específicas, é útil compreender que o desempenho lento em certos países em desenvolvimento pode ser devido à popularidade dos dispositivos móveis de baixo custo. E vale a pena repetir que o CrUX não revela de quais países vêm as pontuações ruins, o que significa trazer o Analytics para ajudar a identificar países com tráfego lento.

5. Corrija o que pode ser repetido

Barry encerrou sua discussão informando que um problema só pode ser corrigido depois de verificado como repetível.

Ele aconselhou:

“Para problemas de servidor, o servidor está com pouca potência?

Ou o código é muito complexo/ineficiente?

Ou banco de dados precisando de ajuste?

Para conexões lentas de alguns lugares você precisa de um CDN?

Ou investigue por que tanto tráfego vindo de lá (campanha publicitária?)

Se nada disso se destacar, pode ser devido a redirecionamentos, principalmente de anúncios. Eles podem adicionar aproximadamente 0,5s ao TTFB – por redirecionamento!

Tente reduzir os redirecionamentos tanto quanto possível:
– Use o URL final correto para evitar a necessidade de redirecionar para www ou https.
– Evite vários serviços de encurtamento de URL.”

Conclusões: como otimizar para obter uma pintura com maior conteúdo

Barry Pollard, do Google Chrome, ofereceu cinco dicas importantes.

1. Os dados do PageSpeed ​​​​Insights (PSI) podem oferecer pistas para depurar problemas de LCP, além de outras nuances discutidas neste artigo que ajudam a entender os dados.

2. Os dados PSI TTFB (Time to First Byte) podem apontar por que uma página tem pontuações LCP baixas.

3. Os testes de laboratório do Lighthouse são úteis para depuração porque os resultados são repetíveis. Resultados repetíveis são essenciais para identificar com precisão a origem dos problemas de um LCP, o que permite a aplicação das soluções corretas.

4. Os CDNs podem mascarar a verdadeira causa dos problemas de LCP. Use o truque de Barry descrito acima para ignorar o CDN e obter uma pontuação de laboratório verdadeira que pode ser útil para depuração.

5. Barry listou seis causas potenciais para pontuações baixas no LCP:

• Desempenho do servidor
• redirecionamentos
• código
• banco de dados
• Conexões lentas específicas devido à localização geográfica
• Conexões lentas de áreas específicas devido a motivos específicos, como campanhas publicitárias.

Leia a postagem de Barry no Bluesky:

Algumas pessoas entraram em contato comigo recentemente pedindo ajuda com problemas de LCP

Imagem apresentada por Shutterstock/BestForBest