Idiomas

Relatório Core Web Vitals (Google Search Console)

Como funciona o relatório Core Web Vitals do Google Search Console — dados de campo do CrUX agrupados por dispositivo, status e conjuntos de URLs semelhantes, por que ele não coincide com o PageSpeed Insights, o que significa "No data available" e como corrigir e validar problemas.

Publicado pela primeira vez: 3 de jul. de 2026 · Última atualização: 22 de ago. de 2026 · Avançado
Idiomas
AIEscrito porAI v2

O relatório Core Web Vitals é o relatório do Google Search Console (na seção Experiência) que mostra como suas URLs indexadas se comportam em LCP, INP e CLS usando dados de campo de usuários reais do CrUX — não as métricas em si e sem dados de laboratório. Ele agrupa URLs por dispositivo (abas Mobile/Desktop separadas), por status (Ruim, Precisa melhorar, Bom) e por conjuntos de páginas semelhantes chamados grupos de URLs, nos quais a pior métrica define o status do grupo. Ele reflete uma janela móvel de 28 dias no percentil 75, portanto as correções levam cerca de um mês para aparecer; diagnostique mais rápido no PageSpeed Insights. Sites novos ou com pouco tráfego veem "No data available" porque o CrUX precisa de tráfego suficiente para ser preenchido. É para triagem do site inteiro, no nível do template, não para consultas de uma única URL. O FID foi removido deste relatório em 12 de março de 2024, quando o INP se tornou um Core Web Vital — e o GSC o removeu imediatamente, ao contrário do período de carência de seis meses do PSI/CrUX.

TL;DR — O relatório Core Web Vitals expõe dados de campo do CrUX (janela móvel de 28 dias, percentil 75) para suas URLs indexadas — ele não calcula nada novo. Agrupa URLs por dispositivo (abas Mobile/Desktop independentes), status (Ruim / Precisa melhorar / Bom, a pior métrica vence) e grupo de URLs (conjuntos de páginas com templates semelhantes que compartilham um status). Somente URLs indexadas aparecem, e ele mostra uma amostra, não todas as URLs. Quando um grupo de URLs é pequeno demais para ser reportado de forma privada, o Google recorre a um grupo de origem de nível mais alto — e, se nem ele consegue atingir o limite, você recebe “No data available”. Ele não coincidirá com o PageSpeed Insights (grupo versus URL individual; o GSC mantém os parâmetros de URL distintos, enquanto o PSI os remove). É para triagem do site inteiro, não para consultas de uma única URL. O FID foi removido em 12 de março de 2024 quando o INP se tornou um Core Web Vital — o GSC o removeu imediatamente, ao contrário do período de carência de seis meses do PSI/CrUX. Corrija primeiro o status “Ruim”, valide com Iniciar rastreamento e espere os dados de campo acompanharem ao longo de aproximadamente um mês.

Evidence for this claim Search Console's Core Web Vitals report groups URL performance using real-world CrUX data and may lack data for low-traffic URLs or origins. Scope: Current Search Console Core Web Vitals report. Confidence: high · Verified: Google Search Console: Core Web Vitals report Evidence for this claim The current Core Web Vitals are LCP, INP, and CLS, evaluated at the 75th percentile over field data. Scope: Current web.dev metric set and assessment method. Confidence: high · Verified: web.dev: Web Vitals

É um relatório, não uma redefinição das métricas

A estrutura mais útil para este artigo é: o relatório Core Web Vitals é uma visão de dados que já existem, não uma medição nova. O Google é explícito: “the data for the Core Web Vitals report comes from the CrUX report. The CrUX report gathers anonymized metrics about performance times from actual users visiting your URL (called field data). The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco»

Evidence for this claim Search Console's Core Web Vitals report groups URL performance using real-world CrUX data and may lack data for low-traffic URLs or origins. Scope: Current Search Console Core Web Vitals report. Confidence: high · Verified: Google Search Console: Core Web Vitals report

Portanto, o relatório tem zero dados de laboratório — nenhuma pontuação do Lighthouse, nenhum teste sintético. São 100% dados de campo: usuários reais do Chrome, janela móvel de 28 dias, avaliados no percentil 75 e divididos por dispositivo. As definições das métricas, os limites e o peso como sinal de ranqueamento ficam no glossário Core Web Vitals e no tópico de web-vitals — não vou rederivá-los aqui. O assunto aqui é a ferramenta.

Apenas URLs indexadas, e apenas uma amostra

Há três regras de escopo que as pessoas não percebem. Primeiro, e mais fundamental: um grupo de URLs só aparece depois de atingir um limite de dados para LCP e CLS — se um grupo não tiver dados de relatório suficientes para ambos, ele é omitido do relatório inteiro, não marcado como aprovado. Segundo: “Only indexed URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web Vitals.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Portanto, não o leia como uma auditoria exaustiva. Terceiro, um detalhe sutil que confunde quem está acostumado a outros relatórios do GSC: “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» A maior parte dos relatórios do Search Console consolida os dados na canonical; este não.

Mobile e Desktop são conjuntos de dados independentes

O relatório divide tudo por dispositivo, e as duas abas são completamente separadas — nunca calculadas como média. Um grupo de URLs pode estar Bom no celular e Precisa melhorar no desktop simultaneamente, porque são conjuntos de dados CrUX diferentes, que refletem dispositivos, redes e classes de CPU diferentes. Sempre verifique as duas abas; um resumo “Bom” em uma pode esconder um grupo “Ruim” na outra.

Status: a pior métrica vence

Cada grupo de URLs cai em um de três grupos — Ruim, Precisa melhorar ou Bom — e o status do grupo é o da sua métrica com pior desempenho. Um grupo com LCP e INP bons, mas CLS ruim, é um grupo “Ruim”. Essa regra de que “a pior métrica vence” explica por que um único elemento de layout instável pode derrubar um template que, de resto, é rápido.

Os limites subjacentes (LCP ≤ 2,5 s / INP ≤ 200ms / CLS ≤ 0,1 para “Bom”, cada um no p75) são as definições das métricas, cobertas no glossário Core Web Vitals — e vale observar: na época da minha pesquisa, a documentação ativa do Search Central ainda listava esses números originais. Se você viu circular uma afirmação de que o Google reduziu silenciosamente o limite de LCP “Bom” para 2,0 segundos, ou de que alguma atualização principal do fim de 2025 tornou Core Web Vitals um fator de ranqueamento muito maior — não consegui verificar nenhuma das duas em uma fonte pertencente ao Google, e a documentação as contradiz. Trate-as como rumores.

Grupos de URLs — a mecânica central

Esta é a característica que define o relatório e a maior mudança de modelo mental para quem vem do hábito de usar o PageSpeed Insights com uma única URL. Google: “URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco»

John Mueller descreveu a mecânica em 2021: “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» E, de forma crucial, os dados do grupo podem substituir os de uma URL que não tenha nenhum dado próprio: “If we find a new URL that is also a part of this group, we don’t have to have data for that new URL. We can rely on the data for the group overall.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco»

É também por isso que o relatório pode parecer alarmante quando, na realidade, existe apenas um bug. Mueller novamente: “We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Uma falha de template, milhares de URLs sinalizadas.

É exatamente por isso que o agrupamento é útil, e não irritante. Como escrevi no guia de Core Web Vitals da Ahrefs, “This grouping of pages makes a lot of sense. This is because most of the changes to improve Core Web Vitals are done for a particular page template that impacts many pages.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» E no guia do PageSpeed Insights: “The benefit of GSC is that it buckets similar URLs. For the bucketed pages, you will likely be working in one system or template.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Corrija o template uma vez e corrija-o para o grupo inteiro. Ou, como expliquei em uma entrevista com a Outside Communications: “Basically, here are groups with issues that probably share the exact same theme. You fix it once, you fix that issue for all those pages.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco»

O limite de privacidade e o fallback para o grupo de origem

O agrupamento não é apenas uma conveniência — é uma exigência de privacidade. Google: “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Portanto, a cascata é: grupo de URLs → grupo de origem → nada. Quando nem a origem consegue atingir o limite, você recebe “No data available” (tradução) «em português, a citação confirma a explicação apresentada neste bloco». Essa é a razão mecânica pela qual sites com pouco tráfego veem agrupamentos amplos e pouco precisos ou nenhum dado.

Por que um grupo “Ruim” ainda pode conter páginas rápidas

Como o status se aplica ao grupo inteiro no percentil 75, uma URL individual rápida pode ser arrastada para um grupo lento. Estar em um grupo Ruim não prova que aquela URL é lenta — significa que o conjunto, tomado em sua totalidade, tem um problema. Não presuma que todo membro é culpado; o grupo é a unidade de análise.

Lendo o relatório: gráfico versus tabela

Um detalhe genuinamente confuso que a maioria dos guias de terceiros ignora. O gráfico inicial e a tabela de problemas contam de forma diferente: “The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Assim, uma URL com um problema Ruim e outro Precisa melhorar aparece uma vez (como Ruim) no gráfico, mas nas duas linhas da tabela. É por isso que os totais não fecham — é intencional, não um bug. Ao clicar em um problema, como descrevo, você “gives you a breakdown of page groups that are impacted” (tradução) «em português, a citação confirma a explicação apresentada neste bloco», com URLs de exemplo ordenadas por impressões.

Validando correções: o fluxo Iniciar rastreamento

O relatório tem um ciclo de validação integrado que é fácil de ignorar. Google: “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Isso inicia uma sessão de monitoramento de 28 dias para o problema — o Google observa os dados de campo do grupo se acumularem durante essa janela, em vez de verificá-los novamente na hora. Três coisas importam sobre a forma como ele resolve o problema: uma única URL afetada que ainda falhe durante a janela pode impedir que o problema inteiro passe; os status que você verá são """""""Not started / Started / Looking good / Passed / N/A / Failed” (tradução) «Não iniciado / Iniciado / Parece bom / Aprovado / N/D / Reprovado»"""" «Não iniciado / Iniciado / Parece bom / Aprovado / N/D / Reprovado»”* «Não iniciado / Iniciado / Parece bom / Aprovado / N/D / Reprovado»”* «Não iniciado / Iniciado / Parece bom / Aprovado / N/D / Reprovado» no nível do problema, e Pending / Passed / Failed por URL; e clicar em Start Tracking não aciona reindexação nem outro comportamento ativo de rastreamento — é apenas um sinal de monitoramento sobre dados que o Google já coleta. Esta é a forma correta de confirmar que uma correção chegou aos dados de campo — não basta olhar o gráfico agregado e torcer.

Relatório Core Web Vitals versus PageSpeed Insights

Essas duas ferramentas extraem dados da mesma fonte CrUX, mas os apresentam de forma diferente, e regularmente discordam para uma URL. Há duas razões documentadas:

  • Grupo versus individual. Google: “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Uma única URL pode ser um ponto fora da curva no seu grupo, então o status do grupo e o número do PSI para aquela URL exata não coincidirão.
  • Parâmetros de URL. “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Isso por si só explica muitas reclamações de “por que essas duas ferramentas não concordam”.

Também há uma diferença de abrangência dos dados que vale manter clara, porque “dados de campo” e “dados de laboratório” são usados de modo impreciso. O relatório do GSC contém apenas dados de campo do CrUX, agrupados — nada além disso. O PageSpeed Insights combina três coisas separadas: dados de campo do CrUX no nível da URL, um fallback para dados de campo do CrUX no nível da origem quando a própria URL não tem o suficiente e uma execução de laboratório do Lighthouse ao vivo. Como observo no guia do PSI, “PageSpeed Insights also pulls in the page level data, as well as origin data and lab test data which comes from Lighthouse.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» O relatório do GSC não tem essa camada de laboratório — são dados de campo, ponto final.

Meu fluxo real, e a dica prática que a maioria dos artigos concorrentes não aborda: diagnostique e valide rapidamente nos dados de laboratório do PSI; confirme o que é lento e real no GSC. Do guia do PSI: “The CWV data will take longer to show the impact of any changes because it is a 28-day average, so use PSI or the PSI data in Ahrefs to check if the changes you made improved the lab test metrics.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Você recebe feedback instantâneo de que uma mudança ajudou; depois espera os dados de campo do GSC acompanharem nas semanas seguintes.

”No data available” e sites com pouco tráfego

A explicação do próprio Google: “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» O CrUX tem um limite de elegibilidade — uma URL ou origem precisa de tráfego suficiente do Chrome antes que qualquer dado de campo apareça.

Quão comum isso é? Muito. Em meu estudo de janeiro de 2022 comparando o CrUX com 43,66 milhões de páginas únicas do Site Audit, “We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» O estudo analisou o conjunto de dados bruto do CrUX (a mesma fonte que alimenta o relatório do GSC), não o próprio GSC, e o número é de janeiro de 2022 — portanto, trate-o como uma referência de escala, não como uma porcentagem atual. A conclusão permanece: a maioria das páginas na web simplesmente não recebe tráfego suficiente do Chrome para gerar dados de campo, exatamente por isso o relatório depende do agrupamento no nível da origem e tantos sites não veem nada. Se esse for o seu caso, isso não é um atestado de saúde — teste URLs individuais no PageSpeed Insights ou no Lighthouse.

O FID acabou — o que mudou em março de 2024

Entenda este ponto exatamente, porque tutoriais antigos ainda o mostram errado. O Interaction to Next Paint (INP) substituiu o First Input Delay (FID) como Core Web Vital em 12 de março de 2024. O detalhe específico do Search Console que quase ninguém aborda: segundo o anúncio do web.dev pela equipe do Chrome, “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Portanto, o GSC removeu o FID imediatamente, sem período de carência, enquanto PSI e CrUX continuaram a mostrá-lo por mais seis meses. Se você vir FID em uma captura de tela do Search Console, ela é anterior a março de 2024.

O que aconteceu com o relatório de Experiência na página?

Este é um ponto real de confusão que ainda aparece nas buscas. O Google removeu do Search Console, em 19 de abril de 2023, o relatório independente de Experiência na página — o antigo painel agregado que combinava Core Web Vitals com HTTPS e outros sinais de experiência do usuário. O que sobreviveu: o relatório Core Web Vitals e o relatório HTTPS continuam existindo como relatórios independentes. Apenas o resumo combinado desapareceu. Portanto, se você está procurando um painel de “Experiência na página” e não o encontra, esse é o motivo — os dois relatórios que ficavam abaixo dele ainda existem. (Relatórios irmãos, como o relatório de desempenho e o relatório de indexação de páginas, cobrem o restante da sua presença no Search Console.)

Priorizando e corrigindo o que o relatório encontra

O Google divide sua própria orientação entre trilhas não técnicas e de desenvolvimento — uma boa indicação de que este relatório é lido por públicos muito diferentes. A regra de priorização para todos é: corrija primeiro “Ruim”, depois “Precisa melhorar”. Para desenvolvedores, as URLs dentro de um grupo são ordenadas de forma decrescente por impressões, então as que estão no topo alteram mais o status do grupo.

As correções comuns no nível da página que o Google aponta são diretas, mas reais: “Reduce your page size: best practice is less than 500KB for a page and all its resources.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Além disso, o passo a passo para melhorar LCP, INP e CLS pertence aos tópicos de cada métrica — não vou duplicá-lo aqui. O trabalho do relatório é dizer quais templates você deve corrigir, não corrigi-los por você.

Por que meu status mudou quando eu não mexi em nada?

Isso é extremamente comum e geralmente não é um bug. A própria solução de problemas do Google diz: “If you didn’t make any changes in your site, but you see a big change in status for a lot of pages, it’s possible that you had a borderline status for many pages, and some site-wide event pushed your pages over the edge.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Mudanças na combinação do tráfego, uma alteração na latência de um CDN ou host de imagens e uma atualização de navegador adotada amplamente — qualquer uma delas pode empurrar de uma vez um lote de URLs que já estavam no limite para além de um limiar, porque o relatório é um agregado p75 de 28 dias.

E, às vezes, a contagem de URLs elegíveis simplesmente oscila. Durante um episódio de julho de 2025 em que caiu o número de URLs que mostravam dados elegíveis (especialmente no celular), John Mueller caracterizou esse movimento como uma variação normal do tamanho da amostra, não como um problema — esses relatórios se baseiam em amostras do que o Google sabe sobre um site, os tamanhos das amostras mudam e isso não indica um problema. Barry Pollard, do projeto Core Web Vitals do Google, reconheceu a queda e disse que uma correção estava sendo implementada. A lição: a contagem de URLs elegíveis e a qualidade da métrica subjacente são duas coisas diferentes — uma amostra que muda não significa que suas páginas ficaram mais lentas.

O relatório afeta os rankings?

O relatório reflete os mesmos dados de campo que os sistemas de ranqueamento do Google podem considerar, mas os representantes têm descrito de forma consistente Core Web Vitals como um sinal secundário, no nível de desempate, ao lado da relevância do conteúdo — a discussão mais completa sobre o peso no ranqueamento fica no glossário Core Web Vitals, então vou mantê-la em uma linha aqui. Minha opinião honesta: não acho que atingir esses limites mova muito a agulha hoje, embora o Google possa se apoiar mais nesse sinal com o tempo, como acabou fazendo com compatibilidade com dispositivos móveis e HTTPS. Há também uma razão não relacionada a rankings para se importar que costuma ser esquecida: páginas mais rápidas capturam mais dados registrados (CrUX e suas próprias análises), porque menos usuários saem antes de a página terminar de carregar. Melhorar essas métricas ajuda principalmente por ser um proxy de uma experiência genuinamente melhor.

Uma nota rápida sobre o Bing

Não há um equivalente direto no Bing — um relatório dedicado de Core Web Vitals no estilo CrUX, com agrupamento de URLs — dentro do Bing Webmaster Tools. O Bing concentra seus relatórios em um Performance Report (cliques/impressões) e uma auditoria técnica do Site Scan, em vez de uma divisão de Core Web Vitals por dados de campo. O Bing faz referência a métricas no estilo Core Web Vitals em sua orientação, mas ainda não lançou um relatório de dados de campo agrupados comparável ao do Google. As ferramentas do Bing mudam com frequência, então verifique a documentação atual do Bing Webmaster Tools se isso for importante para você.

Onde isso se encaixa

Este relatório é um entre vários do Google Search Console. O relatório de desempenho cobre seu desempenho real na busca (cliques, impressões, posição); o relatório de indexação de páginas cobre a parte de cobertura e indexação. As métricas expostas por este relatório — Core Web Vitals, CrUX e PageSpeed Insights como complemento de dados de laboratório — são análises aprofundadas próprias dentro do cluster de desempenho web.

Evidence for this claim Search Console's Core Web Vitals report groups URL performance using real-world CrUX data and may lack data for low-traffic URLs or origins. Scope: Current Search Console Core Web Vitals report. Confidence: high · Verified: Google Search Console: Core Web Vitals report

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.