← Voltar ao blog
Resumir em: ChatGPT Google AI Claude Perplexity

Core Web Vitals nos sites dos seus clientes: como acompanhar dados de laboratório e de campo

· · Redigido com IA, revisado por Pavol Bincik · Como escrevemos

Resumo

As Core Web Vitals mudam sempre que um plugin, um tema ou uma tag muda, então uma auditoria do dia do lançamento fica desatualizada. O Lighthouse oferece uma medição de laboratório repetível, que mostra uma regressão na execução seguinte. O CrUX mostra o que usuários reais do Chrome vivenciaram, como média móvel de 28 dias, por isso reage devagar nos dois sentidos. O Google usa as Core Web Vitals no ranqueamento, mas diz que a relevância vem primeiro. Acompanhe os dois tipos de dados nas páginas que importam. Uma verificação de disponibilidade não faz nenhuma das duas coisas: ela mede a rapidez com que o servidor responde, não como a página é renderizada.

A maioria dos sites de clientes passa uma vez pelo PageSpeed Insights no lançamento, e ninguém olha de novo. Depois, uma atualização de plugin adiciona um script, o cliente envia uma imagem de destaque enorme, o marketing adiciona um widget de chat pelo gerenciador de tags. Nada disso dispara um alerta de disponibilidade, e tudo isso pode deixar a página mais lenta.

As três Core Web Vitals e seus limites

  • Largest Contentful Paint (LCP): quando a maior imagem ou o maior bloco de texto aparece. Bom: 2,5 segundos ou menos.
  • Interaction to Next Paint (INP): a rapidez com que a página reage a cliques, toques e teclas pressionadas. Bom: 200 milissegundos ou menos; ruim: mais de 500. O INP substituiu o First Input Delay como Core Web Vital em 12 de março de 2024.
  • Cumulative Layout Shift (CLS): quanto o layout pula durante o carregamento. Bom: 0,1 ou menos.

Uma página atinge um limite quando pelo menos 75% dos carregamentos da página o atingem, medido separadamente para dispositivos móveis e desktop.

Quanto elas pesam no ranqueamento

O Google afirma que seus sistemas de classificação usam as Core Web Vitals. Também diz que a Pesquisa continua mostrando a página mais relevante mesmo quando a experiência na página é ruim, e que bons resultados nos relatórios dele não garantem as primeiras posições. Para o site de um cliente, isso significa que velocidade não salva conteúdo fraco, mas uma página lenta abre mão de uma vantagem que não precisava perder.

Dados de laboratório e dados de campo são medições diferentes

Os dados de laboratório vêm do Lighthouse, o mecanismo por trás do PageSpeed Insights. Ele carrega a página uma vez em um ambiente controlado e simulado. Isso torna a medição repetível, boa para depuração e para detectar uma regressão logo depois de uma mudança. Ela tem limites:

  • Não consegue medir o INP, porque ninguém interage com a página. O Total Blocking Time (TBT) é uma aproximação razoável, mas não um substituto.
  • As pontuações variam entre execuções, por exemplo por causa de anúncios, testes A/B ou roteamento de rede, então observe a tendência, não um número isolado.
  • A pontuação de desempenho tem três faixas: 0 a 49 ruim, 50 a 89 precisa melhorar, 90 a 100 bom.

Os dados de campo vêm do Chrome UX Report (CrUX): usuários reais do Chrome que ativaram o envio de estatísticas de uso e a sincronização do histórico. Eles não vêm de rastreadores. Duas propriedades importam:

  • É uma média móvel de 28 dias, atualizada diariamente. Uma regressão publicada hoje aparece aos poucos nas próximas semanas, e uma correção leva o mesmo tempo para aparecer.
  • Uma página precisa de tráfego suficiente do Chrome para ter dados próprios. Sem isso, o PageSpeed Insights recorre aos dados da origem inteira, e um site pequeno pode não ter nenhum dado de campo.

Então os dados de laboratório mostram rapidamente que algo mudou; os dados de campo mostram o que os visitantes realmente sentiram.

Por que uma verificação de disponibilidade não ajuda aqui

Uma verificação de disponibilidade mede a rapidez com que o servidor responde à requisição. Ela não renderiza a página, não carrega imagens nem executa scripts, então não enxerga LCP, INP nem CLS.

Mas ela vê um fator: o tempo de resposta do servidor. O Time to First Byte vem antes do First Contentful Paint e do LCP, então um servidor que fica mais lento arrasta tudo o que vem depois. Um bom TTFB é de 0,8 segundo ou menos. Uma tendência de alta no tempo de resposta depois de uma mudança de hospedagem justifica uma execução do Lighthouse.

O que costuma deixar os sites de clientes lentos

Estes são os suspeitos de sempre, não medições:

  • Atualizações de plugins e temas que adicionam scripts, estilos ou fontes web.
  • Novas tags no gerenciador de tags: widgets de chat, pixels, mapas de calor.
  • Imagens e vídeos enviados pelo cliente em tamanho original.
  • Sliders e construtores de páginas que carregam em todas as páginas.
  • Mudanças de hospedagem: um plano mais barato, um servidor novo, um cache que falta.

Uma rotina que acompanha o ritmo

  1. Escolha duas ou três páginas por cliente: a página inicial e as páginas que trazem contatos ou vendas.
  2. Registre uma linha de base no PageSpeed Insights: a pontuação de laboratório, LCP, TBT e CLS, e os dados de campo, se houver.
  3. Execute o Lighthouse de novo depois de cada atualização e, nos intervalos, em uma programação fixa.
  4. Confira os dados de campo uma vez por mês. Lembre-se de que eles ficam semanas atrás das mudanças.
  5. A cada poucos meses, revise o gerenciador de tags com o cliente e remova o que ninguém usa.

Como o Baromio acompanha isso

  • Lighthouse em uma programação: ative Monitorar Velocidade da Página em um monitor HTTP ou de palavra-chave. O Baromio executa o Lighthouse pelo Google PageSpeed Insights (mobile) e registra a pontuação de desempenho, LCP, FCP, TBT, CLS, Speed Index e o peso da página por tipo de recurso. Free: 1 URL, semanal. Pro (9 EUR por mês): 5 URLs, diário. Business (29 EUR por mês): 15 URLs, diário. O histórico fica guardado por 7, 30 ou 90 dias, conforme o plano.
  • Alertas: você recebe um alerta quando a pontuação cai abaixo de 50, a faixa "ruim" do Lighthouse, e outro só se ela cair mais 15 pontos. Um alerta de recuperação chega quando a pontuação volta a 50 ou mais e está pelo menos 15 pontos mais alta.
  • Dados de campo do CrUX: para os mesmos monitores, o Baromio salva todos os dias um snapshot do CrUX para aquela URL exata, para celulares, desktops e todos os dispositivos juntos: p75 de LCP, FCP, CLS, INP e TTFB, cada um com sua divisão bom / precisa melhorar / ruim. Se o CrUX não tiver dados para a URL, nenhum snapshot é salvo e a aba Velocidade da Página informa isso; é normal em páginas com pouco tráfego.
  • A partir de um assistente de IA: os mesmos dados de campo estão disponíveis pelo servidor MCP do Baromio (get-crux-data).

Fontes

Usamos cookies para entender como o Baromio é usado e melhorar o produto. Você pode aceitar ou recusar os cookies analíticos a qualquer momento. Saiba mais