Documentação
Core Web Vitals: LCP, INP e CLS de usuários reais, semana a semana
LCP, INP e CLS no percentil 75 por semana, obtidos da Chrome UX Report History API, para o site inteiro ou para uma página, avaliados com base nos limites do Google.
O relatório Core Web Vitals (intitulado Core Web Vitals History) mostra, semana a semana, como usuários reais do Chrome vivenciam o seu site. Ele lê a Chrome UX Report History API, os mesmos dados de campo que alimentam o relatório de Core Web Vitals do Search Console, e avalia cada métrica no percentil 75 em relação aos limites do Google. Use-o para saber se uma versão deixou suas páginas mais rápidas ou mais lentas, muito antes de um teste de laboratório indicar como os visitantes sentiram a diferença.
Execute o relatório
- Scope (Escopo): Whole site consulta a origem (por exemplo,
https://www.example.com), que agrega todas as páginas visitadas por usuários do Chrome. Single page consulta uma única URL. - Origin ou Page URL: já preenchido com a origem da sua propriedade; edite-o para verificar outro host ou página.
- Device: All devices, Phone, Desktop ou Tablet. Com All devices, o relatório também carrega cada dispositivo separadamente e adiciona uma tabela Summary by device.
- Clique em Run report.
Os resultados ficam em cache por um dia, já que os dados só mudam semanalmente. O relatório consulta a API com uma chave da CrUX API; o AutoPSEO fornece uma, então não há nada a configurar. O botão API Key leva às instruções do Google, caso você queira uma chave para suas próprias ferramentas.
O que você vê
A linha de veredicto informa se o escopo Passes Core Web Vitals: todas as métricas principais com dados estão classificadas como Good. Em seguida vêm cinco cartões, um por métrica, cada um com o valor mais recente no percentil 75, sua classificação, a variação em relação a quatro semanas antes e a parcela de carregamentos de página classificados como bons.
| Métrica | O que mede | Bom | Ruim |
|---|---|---|---|
| LCP, Largest Contentful Paint | Carregamento: quando o maior elemento visível é renderizado | 2,5 s ou menos | acima de 4 s |
| INP, Interaction to Next Paint | Capacidade de resposta: atraso após cliques, toques e teclas pressionadas | 200 ms ou menos | acima de 500 ms |
| CLS, Cumulative Layout Shift | Estabilidade visual: quanto o conteúdo se desloca durante o carregamento | 0,1 ou menos | acima de 0,25 |
| FCP, First Contentful Paint | Quando o primeiro texto ou imagem aparece | 1,8 s ou menos | acima de 3 s |
| TTFB, Time to First Byte | Com que rapidez o servidor começa a responder | 0,8 s ou menos | acima de 1,8 s |
LCP, INP e CLS são os Core Web Vitals; FCP e TTFB são métricas de apoio que ajudam a explicar um LCP ruim. Valores entre os dois limites precisam de melhoria. O Google avalia cada métrica no percentil 75 dos carregamentos de página, separadamente para dispositivos móveis e desktop (web.dev: Web Vitals). O INP substituiu o First Input Delay como Core Web Vital em 12 de março de 2024.
Uma tendência é considerada improving (em melhoria) ou worsening (em piora) quando o valor mais recente variou pelo menos 5% em relação a quatro semanas antes. Os gráficos mostram o percentil 75 semanal de cada métrica, com as parcelas boa, que precisa de melhoria e ruim, e a tabela lista todas as semanas com os cinco valores e a parcela de experiências de LCP boas.
Como ler o histórico
Cada ponto é um período de coleta semanal que resume os 28 dias anteriores de visitas, portanto uma correção aparece de forma gradual, ao longo de cerca de quatro semanas, e não da noite para o dia. Por padrão, a API retorna 25 períodos semanais, ou seja, aproximadamente os últimos seis meses (CrUX History API).
- Uma mudança abrupta que coincide com um deploy, um novo script do gerenciador de tags ou uma atualização de tema é o padrão mais comum; marque a data com uma anotação.
- Celular pior que desktop é comum, já que os celulares têm menos poder de processamento e, muitas vezes, conexões mais lentas. Pondere isso pela parcela do seu tráfego de busca que vem de dispositivos móveis.
- Origem boa, página ruim: a origem mistura todas as páginas, então verifique um a um os seus templates mais pesados.
Quando não há dados
O Chrome só publica um registro para uma origem ou URL pública com visitas reais suficientes no Chrome; caso contrário, o relatório exibe Not enough field data (metodologia do CrUX). Páginas novas ou com pouco tráfego muitas vezes não têm registro no nível da URL, mesmo quando a origem tem um. As APIs do CrUX também não oferecem detalhamento por país, então os números cobrem todos os seus visitantes no mundo inteiro.
Como o AutoPSEO ajuda
Os artigos entregues pelo AutoPSEO são renderizados pelo seu próprio site, portanto herdam o desempenho dos seus templates. Se o AutoPSEO hospeda uma seção para você, o renderizador hospedado serve as páginas dos artigos diretamente; execute o relatório em uma dessas URLs para verificá-las. Para uma explicação mais completa das três métricas, veja o que significam LCP, INP e CLS e como corrigir Core Web Vitals ruins.