Core Web Vitals

TL;DR — Core Web Vitals são três pontuações que o Google usa para medir como uma página é percebida por usuários reais: a velocidade de carregamento (LCP), a rapidez de resposta quando você toca ou clica (INP) e o quanto as coisas pulam enquanto carregam (CLS). “Bom” significa LCP abaixo de 2,5 segundos, INP abaixo de 200 milissegundos e CLS abaixo de 0,1. Eles dão um pequeno empurrão nos rankings — mas um bom conteúdo importa muito mais.

O que são Core Web Vitals

O Google quer recompensar páginas agradáveis de usar, então reduziu a “boa experiência na página” a três coisas mensuráveis. Juntas, elas são os Core Web Vitals (frequentemente abreviados como CWV):

• Largest Contentful Paint (LCP) — carregamento. Quanto tempo até que o maior elemento na tela (geralmente uma imagem de destaque ou uma manchete) apareça. Bom é ≤ 2,5 segundos.
• Interaction to Next Paint (INP) — responsividade. Quando você toca em um botão ou digita, quanto tempo até a página reagir. Bom é ≤ 200 milissegundos.
• Cumulative Layout Shift (CLS) — estabilidade visual. Quanto a página pula enquanto carrega (um anúncio empurra o texto para baixo exatamente quando você vai tocar). Bom é ≤ 0,1.

De onde vêm as pontuações

As pontuações que o Google realmente usa vêm de pessoas reais visitando seu site no Chrome — não de um teste que você executa. O Google coleta esses dados, e uma página é avaliada pelo que 75% dos visitantes experimentaram. Portanto, você não pode “passar” obtendo um resultado rápido em sua própria máquina; a maioria dos seus visitantes reais precisa ter uma boa experiência. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

É por isso que uma pontuação perfeita em uma ferramenta de teste de velocidade não garante que você passe. Essas ferramentas (como PageSpeed Insights e Lighthouse) executam um único teste de laboratório em um celular simulado — ótimas para encontrar problemas, mas não fornecem os números pelos quais o Google ranqueia.

Eles afetam os rankings?

Um pouco. O Google diz que Core Web Vitals são usados por seus sistemas de ranqueamento — mas não há um peso ou percentual oficial associado a eles, e o Google é explícito que conteúdo relevante ainda pode superar uma página com experiência abaixo do ideal. Se seu conteúdo não for relevante, ser rápido e estável não vai salvá-lo. Como disse John Mueller, do Google, “it’s not going to make your site’s rankings jump up.” (tradução) «isso não vai fazer os rankings do seu site dispararem.»

Minha opinião honesta depois de anos trabalhando com isso: a maioria dos sites não verá um grande benefício de ranqueamento por perseguir esses números. Mas não há nada de errado em deixar seu site mais rápido e estável — seus visitantes percebem, e isso ajuda as conversões mesmo quando não move os rankings.

Uma coisa que as pessoas entendem errado

Alerta sobre o nome antigo: você ainda pode ver FID (First Input Delay) mencionado como um Core Web Vital. Ele acabou — o INP substituiu o FID em 12 de março de 2024. Se uma ferramenta ou artigo ainda está dizendo para você otimizar o FID, está desatualizado.

Quer a versão mais aprofundada — limites exatos, dados de campo versus laboratório, quanto isso realmente pesa para o ranqueamento e qual ferramenta usar em cada caso? Mude para a aba Avançado.

TL;DR — Core Web Vitals são três métricas de UX medidas em campo: LCP (carregamento, “bom” ≤ 2,5 s), INP (responsividade, ≤ 200 ms) e CLS (estabilidade visual, ≤ 0,1), cada uma avaliada no percentil 75 de usuários reais do Chrome (CrUX) em uma janela móvel de 28 dias. Os limites são os mesmos no celular e no desktop, mas o Google avalia cada dispositivo separadamente e espera que as três métricas sejam boas — não apenas uma. O INP substituiu o FID em 12 de março de 2024. O Google diz que seus sistemas de ranqueamento usam Core Web Vitals, mas não há um peso oficial nem um percentual de “desempate” associado — uma boa pontuação não garante rankings melhores, e a relevância ainda pode vencer. Pontuações de laboratório (Lighthouse/PSI) são medições de diagnóstico e frequentemente não coincidem com dados de campo. TTFB e FCP são “outros Web Vitals” de diagnóstico; TBT e Speed Index são proxies de laboratório.

O que conta como Core Web Vital

O Google define Core Web Vitals como “the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Existem exatamente três, e cada um mede uma dimensão diferente de como uma página é percebida: «o subconjunto de Web Vitals que se aplica a todas as páginas da web, deve ser medido por todos os proprietários de sites e será exibido em todas as ferramentas do Google.»

O Google avalia os três limites “bons” no percentil 75: LCP em 2,5 segundos, INP em 200 milissegundos e CLS em 0,1. Uma página só é considerada “boa” no conjunto quando os três ultrapassam seus limites no p75 — não apenas um ou dois. Os próprios limites são os mesmos para celular e desktop, embora o Google avalie e informe cada classe de dispositivo separadamente. Evidence for this claim Core Web Vitals are assessed at the 75th percentile, with good thresholds of 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS. Scope: Current stable Core Web Vitals definitions from the Chrome team. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

Tudo mais que você já ouviu — TTFB, FCP, TBT e Speed Index — não é um Core Web Vital. Mais sobre eles abaixo.

LCP — carregamento

LCP “reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Na prática, o elemento LCP geralmente é uma imagem de destaque, uma imagem de fundo grande ou o bloco da manchete. Observe que é o maior elemento visível — tamanhos diferentes de viewport podem ter elementos LCP diferentes, o que é uma das razões pelas quais os números de campo e de laboratório divergem. «informa o tempo de renderização da maior imagem, bloco de texto ou vídeo visível no viewport, em relação ao momento em que o usuário navegou pela primeira vez para a página.»

INP — responsividade

INP “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Ele mede a interação completa: atraso de entrada → processamento do manipulador de evento → tempo até pintar o próximo quadro. «avalia a responsividade geral de uma página às interações do usuário observando a latência de todas as interações de clique, toque e teclado que ocorrem durante toda a visita do usuário à página.»

Esta é a grande melhoria em relação à métrica que substituiu. O INP melhora o FID ao observar todas as interações, não apenas a primeira — o FID media apenas o atraso de entrada da primeira interação. O INP se tornou um Core Web Vital em 12 de março de 2024, substituindo o First Input Delay (FID). Evidence for this claim INP became a Core Web Vital and replaced FID on March 12, 2024. Scope: Chrome and Google tooling transition from FID to INP. Confidence: high · Verified: 2026-07-14 web.dev: INP launch O FID foi removido do Search Console naquele dia. Ele está totalmente aposentado — não o otimize.

Vale guardar uma nuance: o INP não é sua pior interação individual, mas um percentil alto de todas elas. Um único clique travado não vai derrubar uma página que, de resto, é boa.

CLS — estabilidade visual

CLS “is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» O “burst” (janela de sessão) agrupa mudanças que acontecem dentro de 1 segundo umas das outras, até uma janela total de 5 segundos. Os culpados habituais nomeados pelo Google são: “images or videos with unknown dimensions,” (tradução) «imagens ou vídeos com dimensões desconhecidas» “fonts that render larger or smaller than its initial fallback,” (tradução) «fontes renderizadas maiores ou menores que a alternativa inicial» e “third-party ads or widgets that dynamically resize themselves.” (tradução) «anúncios ou widgets de terceiros que se redimensionam dinamicamente» «é uma medida do maior conjunto de pontuações de mudanças de layout para cada mudança de layout inesperada que ocorre durante todo o ciclo de vida de uma página.» «imagens ou vídeos com dimensões desconhecidas», «fontes que são renderizadas maiores ou menores que seu fallback inicial» e «anúncios ou widgets de terceiros que redimensionam a si mesmos dinamicamente».

Dados de campo versus dados de laboratório — medição e diagnóstico

Esta é a distinção que mais causa confusão, então seja preciso com ela.

• Dados de campo (CrUX) são “data collected from the real users visiting your site.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Eles são informados no percentil 75, em uma janela móvel de 28 dias, segmentados entre celular e desktop. Core Web Vitals representam esse tipo de experiência do mundo real e são usados pelos sistemas de ranqueamento do Google. Eles refletem dispositivos, redes, estados de cache e o back/forward cache reais.
• Dados de laboratório são “data collected in a controlled environment with predefined device and network settings” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» — um único celular emulado, cache frio, nenhum usuário real. Lighthouse e a seção de laboratório do PageSpeed Insights produzem esses dados. É uma ferramenta de diagnóstico para encontrar problemas, não uma medição de campo. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data «dados coletados de usuários reais que visitam seu site.» «dados coletados em um ambiente controlado com configurações predefinidas de dispositivo e rede».

A orientação do próprio Google: “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» E a pontuação de desempenho do Lighthouse “often does not correlate with field Core Web Vitals.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Digo o mesmo no meu guia de Core Web Vitals: dados de laboratório são mais úteis para testar e iterar, porque os dados de CWV de campo são uma média móvel de 28 dias — você não verá sua correção refletida por semanas. «se você tiver dados de campo e dados de laboratório para uma determinada página, deve usar os dados de campo para priorizar seus esforços.» «frequentemente não se correlaciona com Core Web Vitals de campo.»

A regra do p75 e por que ela importa

Uma página só passa se 75% dos usuários reais atingirem o limite “bom”. É um limite deliberadamente tolerante, mas real: a maioria dos seus visitantes (3 de 4) teve uma boa experiência, sem que você fique refém de alguns pontos fora da curva em conexões ruins. É também por isso que seu celular mostrar um carregamento de 1,8 s não significa nada sozinho — o seu p75 entre todos é o que conta.

Nível da página versus nível da origem — não se deixe enganar

Muitas ferramentas mostram por padrão uma pontuação no nível da origem (média do site inteiro), que pode ser muito mais otimista que a das suas páginas individuais. No meu estudo de dados de CWV (CrUX mais 5,2 milhões de páginas do Ahrefs Site Audit), apenas 21,2% das páginas individuais passaram nos três limites, contra 33% no nível da origem. A documentação de experiência na página do Google diz que seus sistemas geralmente avaliam as páginas individualmente, embora também executem avaliações mais amplas do site inteiro — portanto, uma origem que “passa” ainda pode esconder muitas páginas individuais que falham. Quando uma ferramenta oferece as duas visões, não presuma que a média no nível da origem informa o que uma página específica está fazendo; verifique também o número no nível da página.

Uma armadilha relacionada: páginas sem tráfego suficiente não têm nenhum dado de campo do CrUX, e o CrUX inclui apenas usuários do Chrome que aceitaram participar das estatísticas de uso (sem Chrome no iOS, sem outros navegadores). Isso é uma lacuna de elegibilidade de dados, não uma reprovação — dados de campo ausentes não são o mesmo que uma pontuação ruim. A forma exata como cada ferramenta agrupa páginas semelhantes ou faz fallback para URLs com pouco tráfego (PSI, Search Console, API do CrUX) é documentada por aquele produto específico, não por uma regra universal.

Quanto Core Web Vitals realmente importa para o ranqueamento?

Eles são um sinal de ranqueamento confirmado — o Google diz que seus sistemas de ranqueamento usam Core Web Vitals. O que a documentação atual do Google não faz é atribuir um peso, percentual ou rótulo oficial de “desempate” a esse sinal, portanto tenha cuidado ao repetir essas descrições como se fossem palavras do próprio Google.

Do lado do “é real”: a documentação do Google diz que Core Web Vitals “along with other page experience aspects, aligns with what our core ranking systems seek to reward,” (tradução) «junto com outros aspectos da experiência na página, alinham-se ao que nossos principais sistemas de ranqueamento procuram recompensar», e John Mueller afirmou publicamente que são “more than a tie-breaker, but it also doesn’t replace relevance.” (tradução) «mais que um critério de desempate, mas também não substituem a relevância».

Do lado do “não exagere”: Mueller também disse “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that,” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» e, na atualização da documentação de março de 2024, acrescentou via LinkedIn que “it’s not going to make your site’s rankings jump up.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» A documentação de experiência na página do próprio Google é direta: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» A documentação de 2024 ainda alerta que “trying to get a perfect score just for SEO reasons may not be the best use of your time.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» Evidence for this claim Google says Core Web Vitals are used by ranking systems, while page experience does not override more relevant content. Scope: Google Search ranking guidance; no fixed weight or ranking-position effect is promised. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search Google: Page experience «Core Web Vitals não são fatores gigantes no ranqueamento, e duvido que você visse uma grande queda apenas por causa disso»; «isso não vai fazer os rankings do seu site dispararem»; «a Pesquisa Google sempre busca mostrar o conteúdo mais relevante, mesmo que a experiência na página esteja abaixo do ideal»; «tentar obter uma pontuação perfeita apenas por razões de SEO talvez não seja o melhor uso do seu tempo».

Minha leitura pragmática: a relevância domina, o Google não atribuiu um número ao peso dos CWV e a maioria dos sites não verá um grande benefício por trabalhar neles para fins de ranqueamento. Dito isso, as melhorias de UX subjacentes valem a pena para usuários e conversões — e plataformas (WordPress, Cloudflare e frameworks) continuam absorvendo automaticamente boa parte da carga de otimização. Especialmente para pequenas empresas e negócios locais, isso geralmente não deveria estar no topo da lista.

Mais um esclarecimento da atualização de 2024: entre os sinais mais amplos de experiência na página, apenas Core Web Vitals têm confirmação de contribuição direta para o ranqueamento. HTTPS, compatibilidade com dispositivos móveis, ausência de intersticiais intrusivos e clareza do conteúdo são boas práticas, mas não aumentam diretamente o ranqueamento como a documentação já deu a entender.

Os “outros Web Vitals” — de diagnóstico, não Core

Eles aparecem constantemente e são classificados de forma errada. Nenhum deles é Core Web Vital:

• Time to First Byte (TTFB) — quanto tempo até o primeiro byte da resposta chegar. Ele “precedes every other meaningful loading performance metric” e alimenta o LCP, mas o Google é explícito: “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» (Bom ≤ 0,8 s.) De diagnóstico.
• First Contentful Paint (FCP) — tempo até qualquer conteúdo ser pintado. Um diagnóstico útil de carregamento (bom ≤ 1,8 s), mas não Core.
• Total Blocking Time (TBT) — um proxy de laboratório para INP. Ferramentas como Lighthouse “cannot measure INP” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» sem um usuário real, então informam TBT. Apenas laboratório.
• Speed Index — um proxy de laboratório para a velocidade de carregamento percebida. Exclusivo do Lighthouse. «precede todas as outras métricas significativas de desempenho de carregamento»; «como o TTFB não é uma métrica de Core Web Vitals, não é absolutamente necessário que os sites atinjam o limite de TTFB ‘bom’»; «não consegue medir INP».

Use-os para depurar. Não os informe como Core Web Vitals nem trate seus limites como barreiras de ranqueamento.

Um mito para aposentar

Você pode ver “Engagement Reliability” sendo apresentado como um novo Core Web Vital. Não há nenhum anúncio oficial do Google sobre essa métrica — ela circula apenas em conteúdo de terceiros. Os Core Web Vitals são LCP, INP e CLS. Até que o Google diga o contrário, essa é a lista.

Como medir — e qual ferramenta usar para cada coisa

Associe a ferramenta ao trabalho:

• Relevante para o ranqueamento (dados de campo): PageSpeed Insights (mostra dados de campo do CrUX no nível da página e da origem), relatório Core Web Vitals do Google Search Console (agrupa páginas semelhantes e expõe padrões do site inteiro), API do CrUX / BigQuery (análise personalizada e por país) e a biblioteca JS web-vitals (colete seu próprio RUM).
• Depuração (dados de laboratório): Lighthouse, painel Performance do Chrome DevTools e a seção de laboratório do PSI. Eles encontram a causa; não decidem seu ranqueamento.

O fluxo que sugiro: use o GSC para descobrir quais grupos de páginas estão falhando em campo, confirme com o PageSpeed Insights no nível da página e depois entre no Lighthouse / DevTools para diagnosticar e iterar — sabendo que os números de campo podem levar até 28 dias para serem atualizados.

Para onde ir agora: o cluster de desempenho web

Este hub é o mapa. Cada tópico abaixo é um aprofundamento próprio.

Os três Core Web Vitals

• Largest Contentful Paint — a métrica de carregamento: o que conta como elemento LCP, a meta de ≤ 2,5 s e como fazê-lo ser pintado mais cedo.
• Interaction to Next Paint — a métrica de responsividade que substituiu o FID: atraso de entrada, processamento do evento e atraso de apresentação, e como reduzir cada um.
• Cumulative Layout Shift — a métrica de estabilidade visual: janelas de sessão, as causas habituais (mídia dimensionada, fontes, anúncios injetados) e como atingir ≤ 0,1.

Métricas de suporte e diagnóstico

• Time to First Byte — latência do servidor/resposta que alimenta o LCP; útil para depurar, não é um Core Web Vital.
• First Contentful Paint — quando o primeiro conteúdo é pintado; um diagnóstico de carregamento.
• Total Blocking Time — o proxy de laboratório que o Lighthouse usa para aproximar o INP.
• Speed Index — o proxy de laboratório para a velocidade percebida de carregamento.

Como são medidos

• PageSpeed Insights — dados de campo (CrUX) mais um relatório de laboratório do Lighthouse em um só lugar.
• Google Lighthouse — o mecanismo de laboratório/diagnóstico por trás do PSI e do DevTools.
• Chrome UX Report (CrUX) — o conjunto de dados de usuários reais em que se baseia a avaliação do Google.

Para ver o cluster inteiro, consulte o hub de desempenho web. Cada tópico irmão aponta para este automaticamente assim que é publicado.

Resumo de IA

Uma versão condensada da versão Advanced:

• Core Web Vitals = três métricas de campo: LCP (carregamento, bom ≤ 2,5 s), INP (responsividade, ≤ 200 ms), CLS (estabilidade visual, ≤ 0,1). Todo o resto (TTFB, FCP, TBT, Speed Index) não é Core.
• Avaliados com dados de campo: usuários reais do Chrome via CrUX, no percentil 75, em uma janela móvel de 28 dias. Os limites são os mesmos no celular e no desktop, mas são avaliados separadamente, e o Google espera que as três métricas sejam boas, não apenas uma.
• O INP substituiu o FID em 12 de março de 2024. O FID está totalmente aposentado; o INP mede todas as interações, não apenas a primeira.
• Ferramentas de laboratório (Lighthouse/PSI) são de diagnóstico, não medições de campo, e frequentemente não coincidem com os CWV de campo. Use-as para encontrar causas; os números de campo têm atraso de até 28 dias.
• Nível da página versus nível da origem importa: cerca de 21,2% das páginas passam contra cerca de 33% das origens (meu estudo de CWV). O Google usa o nível da página — médias da origem escondem páginas que falham.
• Peso no ranqueamento: usado, mas sem peso definido. O Google diz que seus sistemas de ranqueamento usam Core Web Vitals, sem percentual oficial nem rótulo de “desempate”; a relevância domina e uma boa pontuação não é garantia de ranqueamento. Mueller: “not giant factors in ranking.” Apenas CWV (não HTTPS, compatibilidade com dispositivos móveis ou intersticiais) contribui diretamente segundo a documentação de 2024.
• Mito a ignorar: “Engagement Reliability” não é um Core Web Vital confirmado.
• Ferramentas: campo = PSI, relatório de CWV do GSC, API do CrUX, web-vitals.js; depuração = Lighthouse, DevTools, seção de laboratório do PSI.

Documentação oficial

Documentação de fonte primária do Google.

web.dev (equipe do Chrome)

• Web Vitals — a iniciativa, as três métricas, a regra do p75 e por que TTFB/FCP são “outros” Web Vitals.
• Largest Contentful Paint (LCP) — definição, limites e elementos LCP elegíveis.
• Interaction to Next Paint (INP) — definição, limites e a decomposição em atraso de entrada → processamento → apresentação.
• Cumulative Layout Shift (CLS) — definição, janelas de sessão e causas comuns.
• Definindo os limites das métricas Core Web Vitals — por que cada limite “bom” e o percentil 75 foram escolhidos.
• Diferenças entre dados de laboratório e de campo — por que os números de campo (CrUX) e de laboratório (Lighthouse) divergem.
• Fluxos de trabalho / ferramentas de Core Web Vitals — qual ferramenta informa dados de campo versus laboratório.
• INP avança para Core Web Vitals (maio de 2023) — o anúncio de que o INP substituiria o FID.
• Interaction to Next Paint é oficialmente um Core Web Vital (12 de março de 2024) — a confirmação do lançamento.
• TTFB e FCP — os “outros Web Vitals” de diagnóstico.

Google Search Central

• Entendendo Core Web Vitals e os resultados da Pesquisa Google — como CWV se relaciona com o ranqueamento.
• Entendendo a experiência na página nos resultados da Pesquisa Google — o quadro mais amplo da experiência na página e a ideia de que “a relevância vence”.
• Introdução do INP nos Core Web Vitals (maio de 2023) — o anúncio da transição pelo Search Central.

Chrome for Developers

• Relatório de experiência do usuário do Chrome (CrUX) — o conjunto de dados de usuários reais, a elegibilidade e a janela de 28 dias.

Citações das fontes

Declarações registradas do Google. Cada link é um link profundo que salta até o trecho citado na página de origem.

Google — o que são Core Web Vitals

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» — Philip Walton, web.dev. Ir para a citação
• “LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» — web.dev (LCP). Ir para a citação
• “INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» — web.dev (INP). Ir para a citação
• “CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» — web.dev (CLS). Ir para a citação «“Core Web Vitals são o subconjunto de Web Vitals que se aplica a todas as páginas da web, deve ser medido por todos os proprietários de sites e será exibido em todas as ferramentas do Google.” “LCP informa o tempo de renderização da maior imagem, bloco de texto ou vídeo visível no viewport, em relação ao momento em que o usuário navegou pela primeira vez para a página.” “INP é uma métrica que avalia a responsividade geral de uma página às interações do usuário observando a latência de todas as interações de clique, toque e teclado que ocorrem durante toda a visita do usuário à página.” “CLS é uma medida do maior conjunto de pontuações de mudanças de layout para cada mudança de layout inesperada que ocorre durante todo o ciclo de vida de uma página.”»

Google — INP substituindo FID

• “Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).” — Rick Viscomi, web.dev (12 de março de 2024). Ir para a citação (tradução) «“Interaction to Next Paint (INP) agora é uma métrica estável de Core Web Vital, substituindo First Input Delay (FID).”»

Google — campo versus laboratório e ranqueamento

• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» — Philip Walton, web.dev. Ir para a citação
• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» — Chrome for Developers (documentação do CrUX). Ir para a citação «“Se você tiver dados de campo e dados de laboratório para uma determinada página, deve usar os dados de campo para priorizar seus esforços.” “O Chrome User Experience Report (também conhecido como Chrome UX Report, ou CrUX, abreviado) é um conjunto de dados que reflete como usuários reais do Chrome experimentam destinos populares na web.”»

John Mueller, Google

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» — via Search Engine Journal (Reddit, agosto de 2021). Leia a cobertura
• “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» — via Stan Ventures (2024). Leia a cobertura «“É um fator de ranqueamento e é mais que um desempate, mas também não substitui a relevância.” “Core Web Vitals não são fatores gigantes no ranqueamento, e duvido que você visse uma grande queda apenas por causa disso.”»

Checklist de Core Web Vitals

Uma verificação rápida para confirmar que você está medindo a coisa certa e corrigindo as páginas certas:

• Você está lendo dados de campo (CrUX), não apenas uma pontuação de laboratório, para as métricas que o Google usa no ranqueamento.
• Você está olhando os números no nível da página, não apenas a média no nível da origem.
• Os três estão sendo verificados: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 no p75.
• Celular e desktop são avaliados separadamente (o Google avalia cada um).
• Você não está otimizando o FID — ele foi aposentado em 12 de março de 2024 (use INP).
• O relatório Core Web Vitals do GSC foi revisado para grupos de páginas que falham, não casos isolados.
• Você entende que páginas com pouco tráfego podem não ter nenhum dado de campo do CrUX.
• Ferramentas de laboratório (Lighthouse/PSI) são usadas para diagnosticar, não como barreira de aprovação/reprovação — e você não está esperando uma pontuação de Performance perfeita.
• Você está permitindo até 28 dias para que correções de campo apareçam.
• Você não está perseguindo CWV antes da relevância do conteúdo e de ganhos de SEO maiores.

Os modelos mentais

1. Três dimensões, três métricas. LCP = carregamento, INP = responsividade, CLS = estabilidade visual. Se você consegue dizer em qual dimensão vive um problema, sabe qual métrica (e qual aprofundamento) abrir.

2. Campo serve para ranquear; laboratório serve para corrigir. O Google ranqueia usando dados de campo do CrUX no p75 ao longo de 28 dias. As pontuações de laboratório do Lighthouse/PSI encontram causas. Nunca trate uma pontuação de laboratório como seu número de ranqueamento — frequentemente elas nem sequer se correlacionam.

3. O nível da página supera o nível da origem. Uma origem que “passa” pode esconder páginas que falham. O Google usa dados no nível da página quando os tem. Quando uma ferramenta mostra os dois, confie na visão do nível da página.

4. Usado, mas sem peso definido. CWV é um sinal de ranqueamento confirmado ao qual o Google nunca atribuiu um peso oficial — a relevância ainda pode substituí-lo. Corrija CWV para usuários e conversões; não espere um salto nos rankings.

5. O teste “é Core mesmo?” Apenas LCP, INP e CLS são Core Web Vitals. TTFB e FCP são de diagnóstico; TBT e Speed Index são proxies de laboratório. “Engagement Reliability” não é confirmado de forma alguma.

Core Web Vitals — resumo rápido

Os três Core Web Vitals (dados de campo, p75)

Métricas de diagnóstico — NÃO são Core Web Vitals

Fatos rápidos

• Avaliação = dados de campo do CrUX, percentil 75, janela móvel de 28 dias, celular e desktop separadamente.
• O INP substituiu o FID em 12 de março de 2024. O FID está totalmente aposentado.
• Pontuações de laboratório (Lighthouse/PSI) são de diagnóstico, não medições de campo — e frequentemente não coincidem com os CWV de campo.
• O nível da página é o que o Google usa; médias no nível da origem podem enganar (cerca de 21,2% das páginas passam contra cerca de 33% das origens no meu estudo de CWV).
• Peso no ranqueamento: usado pelos sistemas de ranqueamento do Google, sem peso oficial declarado — a relevância domina e uma boa pontuação não é garantia.
• “Engagement Reliability” não é um Core Web Vital confirmado.

Qual Core Web Vital devo investigar primeiro?

Core Web Vitals regridem após um lançamento

1. Confirme o sinal. Separe campo de laboratório, URL de origem e celular de desktop. Se apenas uma execução de laboratório mudou, reproduza-a antes de declarar um incidente.
2. Identifique o vital que falha. LCP, INP e CLS representam problemas diferentes. Se vários mudaram, verifique primeiro alterações compartilhadas do lançamento e scripts de terceiros.
3. Relacione a regressão a uma implantação. Compare rastreamentos RUM ou de laboratório repetíveis antes e depois do lançamento. Se o momento não coincidir, inspecione a combinação de tráfego e dispositivos.
4. Diagnostique a métrica, não a pontuação. Para LCP, inspecione o elemento e suas subpartes; para INP, inspecione interações lentas e o trabalho da thread principal; para CLS, inspecione as fontes das mudanças.
5. Publique a menor correção atribuível. Valide-a imediatamente no laboratório. Se ela quebrar a funcionalidade ou piorar outro vital, faça rollback.
6. Observe usuários reais. Use RUM para o sinal principal e CrUX/Search Console para o veredito de campo móvel. Documente escopo e janela para que as partes interessadas não esperem um reset do CrUX no mesmo dia.

Erros de Core Web Vitals que desperdiçam trabalho

Otimizar a pontuação composta do Lighthouse

A avaliação de campo do Google usa LCP, INP e CLS de dados de usuários reais, não o número único de Performance do Lighthouse. Diagnostique a métrica de campo que falha e use o Lighthouse como um ambiente controlado de depuração.

Tratar Core Web Vitals como um atalho para o ranqueamento

CWV é um sinal de experiência na página ao qual o Google nunca atribuiu um peso oficial; a relevância ainda domina. Corrija a experiência ruim para os usuários, mas não prometa um salto no ranqueamento nem desloque trabalhos mais importantes de conteúdo e indexação sem evidências.

Misturar valores de URL, origem, celular e desktop

Escopos diferentes podem contar histórias diferentes. Identifique cada valor e não diga que uma página passou porque um fallback da origem ou um agregado de desktop está verde.

Esperar o CrUX antes de verificar um lançamento

A janela móvel de 28 dias é lenta demais para QA de implantação. Valide o mecanismo imediatamente no laboratório e com RUM e depois use o CrUX para confirmar o resultado de campo mais longo.

Ferramentas para medir Core Web Vitals

Verifique com o Core Web Vitals History & Competitor Comparison:

1. Adicione um site (uma origem simples como example.com tem a maior quantidade de dados do CrUX; adicione até 5 para comparar).
2. Escolha celular ou desktop e execute a comparação.
3. Leia o scorecard de aprovação/reprovação de hoje para LCP, INP e CLS e depois o gráfico de tendência semanal para ver se cada métrica está se aproximando ou se afastando da faixa boa.

Dados de campo — medição de Core Web Vitals de usuários reais

• PageSpeed Insights — dados de campo do CrUX no nível da página e da origem, além de um relatório de laboratório do Lighthouse ao lado.
• Google Search Console — relatório Core Web Vitals — agrupa páginas semelhantes e expõe padrões de campo no site inteiro; a maneira mais rápida de encontrar grupos de páginas que falham.
• API do CrUX / BigQuery — análise personalizada e por país diretamente do conjunto de dados de origem.
• Biblioteca JavaScript web-vitals — colete seus próprios dados de usuários reais (RUM), por exemplo, enviando-os para a análise.

Dados de laboratório — para depuração (não para ranqueamento)

• Lighthouse — oportunidades de diagnóstico e a pontuação de Performance (que não serve para ranqueamento).
• Painel Performance do Chrome DevTools — depuração em nível de rastreamento de LCP, mudanças de layout e tarefas longas.
• Seção de laboratório do PageSpeed Insights — recomendações alimentadas pelo Lighthouse sob os dados de campo.

Regra prática: GSC para descobrir onde você está falhando em campo → PSI para confirmar no nível da página → Lighthouse / DevTools para diagnosticar e iterar.

Recursos que valem seu tempo

Textos relacionados meus

• Core Web Vitals: como melhorá-los (Ahrefs) — meu guia prático completo das três métricas e do que corrigir.
• Estudo de dados de Core Web Vitals (Ahrefs) — CrUX + 5,2 milhões de páginas; a descoberta sobre a taxa de aprovação no nível da página versus no nível da origem.
• Guia de Largest Contentful Paint (LCP) (Ahrefs).
• Guia de Cumulative Layout Shift (CLS) (Ahrefs).
• Guia do PageSpeed Insights (Ahrefs).
• Guia para iniciantes de SEO técnico — onde a experiência na página se encaixa no quadro maior.

Oficial

• web.dev — Web Vitals e os artigos de cada métrica vinculados em Documentação oficial.
• Google atualiza a documentação de experiência na página para esclarecer sinais de ranqueamento (Search Engine Land) — Barry Schwartz sobre a mudança na documentação de março de 2024.

Do setor

• Fator de ranqueamento do Google Core Web Vitals: mais que um desempate (Search Engine Journal) — cobertura da declaração de John Mueller no Reddit de que CWV é “mais que um desempate”, mas não substitui a relevância.
• Prioridade de Core Web Vitals do Google para pequenas empresas e negócios locais (Search Engine Roundtable) — comentário de Mueller no Mastodon de que o trabalho de CWV não deve ser prioridade máxima para pequenas empresas e negócios locais.
• Confirmado: Core Web Vitals não é um grande fator de ranqueamento (Stan Ventures) — a citação de Mueller sobre não serem fatores gigantes no ranqueamento, em contexto.
• Impacto de Core Web Vitals no SEO (RUMvision) — atualizado em novembro de 2025; compilação completa, em formato de FAQ, das citações de representantes e das nuances do sinal de ranqueamento.
• Atualização de experiência na página do Google: desempate (Search Engine Roundtable) — o enquadramento inicial de Mueller/Illyes como desempate, de antes do lançamento da atualização.

Estatísticas que vale citar

• Apenas cerca de 21,2% das páginas individuais passam nos três Core Web Vitals — contra cerca de 33% no nível da origem — segundo meu estudo de dados de CWV (CrUX + 5,2 milhões de páginas do Ahrefs Site Audit). Os sistemas do Google geralmente avaliam páginas individualmente, portanto uma média otimista no nível da origem ainda pode esconder muitas páginas que falham. Fonte
• Os sites têm mais dificuldade com LCP. O estudo encontrou sites avançando no antigo FID e no CLS, mas atrasados no LCP — e “almost no sites on 3G or slower connections are passing.” (tradução) «quase nenhum site em conexões 3G ou mais lentas é aprovado» Fonte
• Os limites “bons”: LCP ≤2,5 s, INP ≤200 ms, CLS ≤0,1, cada um no percentil 75 dos dados de campo — as metas documentadas de Core Web Vitals do Google. Fonte
• O INP substituiu o FID em 12 de março de 2024 — a data em que o FID deixou de ser um Core Web Vital e foi removido do Search Console. Fonte

Teste seus conhecimentos: Core Web Vitals

Cinco perguntas rápidas sobre Core Web Vitals. Escolha uma resposta para cada pergunta e depois confira.

Prove que uma correção de LCP/INP/CLS realmente chegou

A armadilha de uma correção de performance é comemorar a pontuação de laboratório no dia do lançamento. O laboratório (Lighthouse) diz se a mudança pode funcionar; apenas os dados de campo (CrUX) dizem se ela funcionou para usuários reais — e eles avançam com um atraso móvel de 28 dias. Execute os dois, nessa ordem.

Teste 1 — A correção melhorou a métrica de laboratório

• Teste a executar — Passe a página pelo Core Web Vitals Checker (ou Lighthouse / PageSpeed Insights) antes e depois da mudança.
• Resultado esperado — A métrica de laboratório visada muda na direção certa — por exemplo, o elemento LCP é renderizado mais cedo, não há nova mudança de layout e o diagnóstico específico que você estava corrigindo é resolvido.
• Interpretação de falha — Nenhum movimento no laboratório significa que a mudança não tocou o caminho crítico (você otimizou um elemento que não era o elemento LCP ou um script que não estava bloqueando).
• Janela de monitoramento — Imediata — os testes de laboratório são executados sob demanda.
• Gatilho de rollback — Uma regressão em outra métrica (você corrigiu LCP, mas introduziu CLS, ou adicionou JS que prejudicou INP) — o laboratório captura isso antes dos usuários reais.

Teste 2 — Usuários reais realmente sentem a mudança (dados de campo)

• Teste a executar — Acompanhe o p75 de LCP, INP e CLS da página/origem no CrUX — no Core Web Vitals History & Competitor Comparison ou no relatório Core Web Vitals do GSC.
• Resultado esperado — O p75 da métrica corrigida entra em “Bom” e permanece lá (limites do Google: LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1).
• Interpretação de falha — O laboratório melhorou, mas o campo não — a correção ajudou um teste em conexão rápida, mas não a combinação real de dispositivo/rede, ou não há URLs suficientes no grupo compartilhando a correção.
• Janela de monitoramento — Móvel de 28 dias — o CrUX é uma janela móvel de 28 dias, portanto uma correção precisa de cerca de 4 semanas de dados de campo acumulados antes que o p75 seja confiável. Não tire essa conclusão na primeira semana.
• Gatilho de rollback — O p75 volta a ultrapassar o limite de “ruim” ou a contagem de URLs “Boas” no GSC cai depois de uma mudança de template — um forte sinal de que a implantação regrediu a performance para usuários reais.

O KPI permanente deste tópico

Separado da validação de uma correção específica, isto é o que você acompanha trimestre após trimestre para saber se a experiência na página está saudável. Existe aqui um benchmark defensável — o Google publica os limites — portanto nenhum número é inventado.

p75 de LCP, INP e CLS (dados de campo)

• Métrica — O valor no percentil 75 de cada Core Web Vital em visitas reais, por grupo de páginas e dispositivo.
• O que informa — Se 75% dos usuários reais têm uma boa experiência — o limite exato que o Google usa para classificar uma URL como aprovada. p75 (não a média) é o número que importa porque reflete a cauda mais lenta.
• Como obter — CrUX pelo Core Web Vitals History & Competitor Comparison, o relatório Core Web Vitals do GSC (dados de campo agrupados por padrão de URL) ou PageSpeed Insights para uma única URL.
• Benchmark / faixa realista — Os próprios limites do Google: LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1 para “Bom”; as faixas “Precisa melhorar” / “Ruim” são 2,5–4 s / >4 s, 200–500ms /

  500ms e 0,1–0,25 / >0,25. Estas são as linhas publicadas, não uma meta inventada.

• Periodicidade — Móvel de 28 dias, portanto faça a revisão mensalmente — verificar todos os dias apenas relê a mesma janela móvel. Trate as pontuações de laboratório como o indicador antecedente e o p75 do CrUX como o indicador atrasado.

Cobertura de “URLs Boas” no site

• Métrica — A proporção das suas URLs indexadas no grupo “Bom” do relatório Core Web Vitals do GSC (celular e desktop acompanhados separadamente).
• O que informa — Até que ponto as correções se propagaram — uma única página rápida não move o site; ganhos no nível do template movem.
• Como obter — GSC → relatório Core Web Vitals → contagem de URLs Boas / Precisa melhorar / Ruins ao longo do tempo.
• Benchmark / faixa realista — Situacional — depende dos seus templates e da combinação de tráfego, portanto estabeleça sua própria linha de base e aumente a proporção Boa ao longo do tempo, em vez de perseguir um percentual inventado.
• Periodicidade — Mensalmente, ou semanalmente logo após uma mudança de template/tema enquanto a janela de campo acompanha.

Registro de alterações