Core Web Vitals: LCP, INP e CLS pelo Google

Digite “core web vitals” no Google. No topo, a Visão geral criada por IA resume o assunto em duas linhas. São métricas do Google para a experiência da página, e elas influenciam o ranqueamento. ¹

Desça pela primeira página. Um guia de hospedagem chama as métricas de fator de ranqueamento e promete mais chances a quem tem bons números. Um texto de empresa de rede, em português, ainda lista o FID entre as três. O FID saiu da lista em março de 2024. ²

A página do Google que responde quanto isso pesa diz duas coisas na mesma resposta. As métricas são usadas pelos sistemas de classificação. E a busca mostra o conteúdo mais relevante mesmo quando a experiência da página é ruim. ¹⁷

Este texto anda com a documentação aberta, conferida em 14 de setembro de 2026.

Um recorte antes de seguir. A velocidade vista por quem visita já tem texto próprio, sobre velocidade do site. Lá estão o teste contra a visita real e o que deixa um site lento. Aqui ficam as três métricas por dentro, os limites, a origem dos dados e o peso na busca. O resto do território técnico, do rastreamento à marcação, está em SEO técnico.

O que são as Core Web Vitals

Pense em três momentos de uma visita. A página aparece. Você toca num botão, e ela responde. Você lê, e o texto fica parado no lugar.

O Google mede cada momento com um número, tirado de visitas reais. Isso se chama Core Web Vitals.

A definição da documentação cabe numa frase. É um conjunto de métricas da experiência real de carregamento, de interatividade e de estabilidade visual da página. ³ O time do Chrome apresentou as métricas em 2020. ¹⁰ O conjunto pode mudar com o tempo, e cada métrica estável muda no máximo uma vez por ano. ⁴

Hoje são três: LCP, INP e CLS. ⁴ O que a página declara ao Google, do título à marcação, fica no texto de SEO on page. As três métricas medem outra coisa: a entrega.

LCP: quando o principal aparece

Pense numa loja de porta de aço. O cliente não espera a loja inteira ficar pronta. Ele espera a porta subir e a vitrine aparecer.

Na página, a vitrine é o maior elemento que cabe na tela: uma imagem, um bloco de texto ou um vídeo. ⁵ O tempo até ele aparecer, contado a partir do momento em que a pessoa pediu a página, se chama Largest Contentful Paint. A sigla é LCP. ⁵

A conta começa cedo. Entram o redirecionamento, a conexão e a espera pelo primeiro byte do servidor. ⁵ Por isso o número medido com visitantes reais pode sair diferente do número de um teste.

Os limites são estes. Até 2,5 segundos é bom. Até 4 segundos precisa melhorar. Acima de 4 segundos é ruim. ⁵ ⁶

INP: quando a página responde

Você aperta o botão do elevador, e a luz não acende. Aperta de novo, sem saber se o primeiro toque valeu.

O Interaction to Next Paint, ou INP, mede esse intervalo na página. Ele observa cliques, toques e teclas durante a visita inteira. ⁷ Para cada interação, conta o tempo até o navegador pintar o próximo quadro na tela, a primeira resposta visível. ⁷

O valor final é a interação mais lenta da visita. Em páginas com muitas interações, o cálculo ignora uma a cada 50, para um tropeço isolado não decidir tudo. ⁷ Rolar a página e passar o mouse não contam. ⁷

Os limites: até 200 milissegundos é bom. Até 500 precisa melhorar. Acima de 500 é ruim. ⁷ ⁶

A troca do FID pelo INP

Antes do INP, a vaga era do First Input Delay, o FID. Ele media só o atraso da primeira interação da visita. ⁸ O resto da visita ficava sem régua.

O INP nasceu experimental em maio de 2022 e virou pendente em 2023. ⁹ Em 12 de março de 2024, virou Core Web Vital oficial e tomou o lugar do FID. ⁹ ⁴ O Google tinha anunciado que, com a troca, o relatório do Search Console deixaria de mostrar o FID. ¹⁰ O Chrome encerrou o suporte ao FID nas ferramentas em 9 de setembro de 2024. ⁸

Texto que ainda lista o FID entre as três foi escrito antes dessa data, ou não foi revisto depois.

Um detalhe do INP confunde muita gente. Ele pode vir vazio. Acontece quando ninguém clicou, quando a pessoa só rolou a página ou quando quem visitou foi um robô. ⁷ Ferramentas que só observam o carregamento também não medem INP. Nelas, o Total Blocking Time, o tempo total de bloqueio, serve de aproximação, sem substituir a métrica. ⁷

CLS: quando a página fica parada

Pense numa notícia aberta no celular. Você está no terceiro parágrafo. Um anúncio carrega em cima, o texto desce, e o seu dedo toca no link errado.

Esse pulo tem nome. Isso se chama deslocamento de layout, e a métrica que mede esses pulos é o Cumulative Layout Shift, ou CLS. ¹¹

A soma tem regra. O web.dev junta os deslocamentos que acontecem com menos de 1 segundo entre eles, numa janela de até 5 segundos. O CLS da página é a maior dessas rajadas. ¹¹ Deslocamento que acontece até meio segundo depois de um toque, clique ou tecla fica fora da conta. O próprio visitante provocou, então ele espera. ¹¹

As causas mais comuns estão na mesma página: imagem ou vídeo sem dimensão declarada, fonte que muda de tamanho ao carregar, anúncio ou widget que se redimensiona. ¹¹

O CLS não tem unidade. É uma pontuação. Até 0,1 é bom. Até 0,25 precisa melhorar. Acima de 0,25 é ruim. ¹¹ ⁶

Uma ressalva de fonte. A ajuda do relatório do Search Console ainda descreve o CLS como a soma de todos os deslocamentos da vida inteira da página. O web.dev registra essa fórmula como a de antes. ⁶ ¹¹ Para a definição, fique com o web.dev.

O percentil 75, a régua dos três números

O dono de uma pizzaria promete entrega em 40 minutos. Ele não se guia pela entrega mais rápida da noite. Nem pela mais atrasada, a do motoboy que furou o pneu. Ele olha o tempo em que chegaram três de cada quatro pedidos.

O Google faz a mesma conta com as visitas. Isso se chama percentil 75. ¹²

A regra do web.dev é direta. Se pelo menos 75% das visitas ficam no bom, a página é boa naquela métrica. Se pelo menos 25% caem no ruim, a página é ruim. ¹² Um LCP de 2 segundos no percentil 75 é bom. Um de 5 segundos é ruim. ¹²

O motivo do 75 também está escrito. Ele garante que a maioria das visitas, três de cada quatro, chegou ao nível pedido ou melhor. ¹² E aguenta pontos fora da curva. Num site com 100 visitas, seriam necessárias 25 visitas desastrosas para mexer no número. ¹²

A conta é separada para celular e para computador. A página passa quando as três métricas estão boas no percentil 75. ⁴

Métrica	O que mede	Bom	Precisa melhorar	Ruim
LCP	carregamento do principal	até 2,5 s	até 4 s	acima de 4 s
INP	resposta a clique, toque e tecla	até 200 ms	até 500 ms	acima de 500 ms
CLS	estabilidade visual	até 0,1	até 0,25	acima de 0,25

De onde vêm os dados

Imagine uma pesquisa de satisfação que ninguém precisa preencher. O navegador anota como a visita foi, sem nome, e manda para uma base comum.

O Chrome faz isso com quem aceitou. Isso se chama Chrome UX Report, ou CrUX. ¹³ É o conjunto oficial de dados do programa das métricas. A documentação do Chrome diz que a Busca do Google usa esses dados na avaliação de experiência da página. ¹³

Nem toda visita entra. O usuário precisa ter as estatísticas de uso e a sincronização do histórico ligadas. ¹⁴ Contam o Chrome de computador e o Chrome no Android. O Chrome no iPhone fica fora, e também navegadores como o Edge. ¹⁴ A janela é sempre dos últimos 28 dias. ¹⁵

Nem toda página entra. Ela precisa ser pública, responder normalmente e não estar marcada com noindex. ¹⁴ E precisa ter visitas suficientes. O número mínimo não é divulgado, e não há como inscrever o site. ¹⁴

Aqui mora a pergunta do site pequeno. Se a página não tem visitas suficientes, o PageSpeed Insights mostra os dados do site inteiro, a origem. Se nem a origem tem, não aparece dado de visitante nenhum. ¹⁵ No Search Console, a tela avisa que não há dados disponíveis. ⁶

Nesse caso, o que sobra é o teste de laboratório. Ele ajuda a achar o problema. Ele não conta como dado de campo. O detalhe dessa diferença está no texto sobre velocidade do site.

A medição de hoje, numa página nossa

Em 14 de setembro de 2026, às 6h20 de Brasília, rodei a página inicial do seogenome.com no PageSpeed Insights. ¹⁶

O botão Este URL veio desativado. A página inicial sozinha não tinha dado de visitante. O relatório mostrou a origem, o site inteiro. ¹⁶ ¹⁵

No celular, a avaliação das Core Web Vitals saiu aprovada. LCP de 2,4 segundos, CLS de 0,02 e INP sem valor, marcado como N/A. ¹⁶ No computador, também aprovada: LCP de 2 segundos, CLS de 0,01 e INP sem valor. ¹⁶

Um aprovado assim pede três leituras.

O INP ficou sem dado. Pela regra do PageSpeed Insights, a origem passa com LCP e CLS bons quando falta INP. ¹⁵ O aprovado de hoje não diz nada sobre a resposta ao toque.

No celular, o LCP está a 0,1 segundo do limite. A ajuda do Search Console explica esse caso. Página na beira do limite muda de faixa com uma mudança pequena no site inteiro, como um pico de visitas. ⁶

E tem a janela. Os 28 dias começam em meados de agosto, e o site novo da SEO Genome entrou no ar em 2 de setembro. ¹⁶ O número de hoje mistura o site antigo com o novo.

No mesmo relatório, a nota de desempenho no topo do diagnóstico era 98. Essa nota é de laboratório, com um celular simulado. ¹⁶ ¹⁵ O dado de campo fica no bloco de cima, o de experiência dos usuários.

O relatório de Core Web Vitals no Search Console

O PageSpeed Insights olha uma página ou uma origem. O Search Console olha o site. O relatório de Core Web Vitals usa o mesmo dado de campo do CrUX. ⁶

Ele mostra só URLs indexadas, e numa amostra. Celular e computador ficam separados. ⁶

A parte que mais confunde é o agrupamento. O relatório junta URLs parecidas num grupo, e o grupo inteiro recebe o mesmo status. A ajuda explica a suposição: páginas do mesmo molde tendem a ter o mesmo problema pelo mesmo motivo. ⁶ O status do grupo é o da pior métrica. CLS ruim com INP bom dá grupo ruim. ⁶

Três regras da ajuda economizam horas de dúvida:

Grupo sem dado de LCP e de CLS fica fora do relatório. Quando falta dado, o Search Console monta um grupo maior, com a origem inteira. ⁶
O dado vai para a URL real. Nos outros relatórios, em geral, ele vai para a canônica. ⁶
O valor do grupo é o do percentil 75. Vale para as visitas dos últimos 28 dias. ⁶

A ordem de trabalho também está na ajuda. Tudo o que está em ruim vem primeiro. Depois, os problemas que atingem mais URLs ou as URLs mais importantes. ⁶ Essa régua de peso vezes alcance entra no exame da auditoria de SEO, junto com os outros relatórios.

Depois da correção, você pede a validação no próprio relatório. O Search Console abre um período de 28 dias de observação. ⁶ Se uma única URL ainda tiver o problema, a validação falha. E a validação não pede reindexação nenhuma. Ela só reinicia o relógio. ⁶

O relatório e o PageSpeed Insights podem discordar. Um fala do grupo, o outro da URL. O PageSpeed Insights também apaga os parâmetros do endereço antes de medir. ⁶

Quanto pesa na busca, pelo que o Google escreve

A página do Google sobre experiência na página responde à pergunta em tom de perguntas frequentes. Eu separo o que ela diz, frase a frase. ¹⁷

As Core Web Vitals são usadas pelos sistemas de classificação. O Google recomenda alcançar bons números, para o sucesso na busca e para a experiência do usuário. ¹⁷ ³

Não existe um sinal único de experiência na página. Os sistemas olham vários sinais. ¹⁷

Resultado bom no relatório do Search Console ou em ferramenta de terceiros não garante o topo. ¹⁷ E correr atrás de nota perfeita só por SEO pode não ser o melhor uso do seu tempo. ¹⁷

A busca sempre procura mostrar o conteúdo mais relevante, mesmo com experiência abaixo do ideal. Em muitas buscas, há muito conteúdo útil disponível. Nesses casos, a boa experiência pode contribuir para o sucesso. ¹⁷

Além das Core Web Vitals, os outros aspectos de experiência não ajudam de forma direta a subir na busca. ¹⁷ A avaliação costuma ser por página, com algumas avaliações do site inteiro. ¹⁷

Uma ressalva de tradução. A versão em português da página apaga uma palavra da pergunta de autoavaliação. O inglês pergunta se as páginas têm Core Web Vitals bons. O português pergunta só se elas têm Core Web Vitals. ¹⁷ Fique com o original.

Na minha leitura, o texto do Google coloca as métricas na conta e diz quando elas decidem. Entre páginas que respondem bem, a experiência desempata. Diante de uma página que responde melhor, ela não passa na frente. Nenhuma página do Google que li para este texto diz que o peso vai crescer.

O que a pessoa faz depois que a página carregou é outra leitura. Ela aparece, com o dado em cima da própria página, no texto sobre o Page Analytics.

A conferência de uma manhã

Separe a página que mais vende e abra duas telas: o Search Console e o PageSpeed Insights.

Abra o relatório de Core Web Vitals, versão celular. Anote os grupos em ruim e a métrica que derrubou cada um. ⁶
Se o relatório disser que não há dados, passe a página inicial no PageSpeed Insights e veja se a origem tem dado de campo. ¹⁵
No PageSpeed Insights, leia o bloco de cima primeiro. Anote se o dado é Este URL ou Origem. ¹⁵
Olhe o INP. Se vier N/A, o aprovado saiu só de LCP e CLS. ¹⁵
Meça a distância até o limite. Um LCP de 2,4 segundos passa hoje, na beira do limite. ⁶ ¹²
Mande ao desenvolvedor a URL de exemplo de cada grupo ruim, com a métrica e o valor do percentil 75. ⁶
Depois da correção, peça a validação e marque na agenda a data de 28 dias depois. ⁶

A partir de agora, quando alguém mostrar uma nota de velocidade, você vai fazer três perguntas. É dado de visitante ou de teste? É da página ou do site inteiro? E quão perto do limite está o percentil 75?

Abra hoje o PageSpeed Insights, cole o endereço da página que mais vende e veja se o botão Este URL acende.

Perguntas frequentes

Core Web Vitals é fator de ranqueamento?

O Google escreve que as métricas são usadas pelos sistemas de classificação. ¹⁷ Na mesma página, diz que resultado bom não garante o topo e que o conteúdo mais relevante aparece mesmo com experiência abaixo do ideal. ¹⁷

Qual nota do PageSpeed Insights preciso para passar?

A nota de 0 a 100 é de laboratório. ¹⁵ A avaliação das Core Web Vitals fica no bloco de cima, com dado de visitantes. Ela passa quando LCP, INP e CLS estão bons no percentil 75. Sem dado de INP, passa com LCP e CLS bons. ¹⁵

Por que o Search Console mostra que não há dados?

A propriedade pode ser nova, ou falta dado no Chrome UX Report. ⁶ A página precisa ser pública e ter visitas suficientes, e o mínimo não é divulgado. ¹⁴

O FID ainda conta?

Não. O INP tomou o lugar do FID em 12 de março de 2024. ⁹ O Chrome encerrou o suporte ao FID nas ferramentas em 9 de setembro de 2024. ⁸

Quanto tempo leva para o relatório mostrar a correção?

O dado é dos últimos 28 dias. ⁶ A validação pedida no relatório também acompanha o site por 28 dias. ⁶

Notas e fontes

Leitura ao vivo da página de resultados do Google Brasil para “core web vitals”, 14 de setembro de 2026, endereço https://www.google.com.br/search?q=core+web+vitals&hl=pt-BR&gl=br&pws=0, em aba própria do navegador do autor. A Visão geral criada por IA dizia que as Core Web Vitals “são métricas criadas pelo Google para medir a experiência real de carregamento, interatividade e estabilidade visual de uma página web. Elas ajudam a garantir que um site seja agradável de usar e influenciam o ranqueamento na busca do Google”. Orgânicos da primeira página, na ordem: Google Search Central, web.dev, Cloudflare, web.dev, SpeedVitals, Semrush, Locaweb e Akamai. Acesso em 14 de setembro de 2026.
Levantamento da SEO Genome, 14 de setembro de 2026, sobre textos da primeira página da nota 1 e do retrato do Semrush (base Brasil), baixados e lidos no mesmo dia. HostGator, “Core Web Vitals (CWV): o que é e como melhorar?”, publicado em 9 de abril de 2026 e modificado em 12 de maio de 2026, https://www.hostgator.com.br/blog/core-web-vitals/: “o Core Web Vitals é um fator de ranqueamento do Google”, com “mais chances” para sites com bons números. Cloudflare, “O que são os Core Web Vitals (CWV)?”, https://www.cloudflare.com/pt-br/learning/performance/what-are-core-web-vitals/: lista “Largest Contentful Paint (LCP), First Input Delay (FID) e Cumulative Layout Shift (CLS)” e não menciona o INP. Conversion, “Core Web Vitals: o que é, como melhorar e SEO com UX”, 12 de julho de 2025, https://www.conversion.com.br/blog/core-web-vitals/: chama as métricas de “fatores de classificação diretos” e escreve que o “peso destas métricas aumentará progressivamente”, sem fonte. Semrush, https://www.semrush.com/blog/core-web-vitals/, modificado em 19 de março de 2024: “Google also considers the Core Web Vitals in its ranking factors”. Locaweb, https://www.locaweb.com.br/blog/temas/marketing-e-seo/core-web-vitals/, 8 de abril de 2024. Acesso em 14 de setembro de 2026.
Google Search Central, “Understanding Core Web Vitals and Google search results”, https://developers.google.com/search/docs/appearance/core-web-vitals, página atualizada em 10 de dezembro de 2025; versão em português atualizada em 18 de dezembro de 2025. Acesso em 14 de setembro de 2026. Trechos: “Core Web Vitals is a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page”; “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally”; “This, along with other page experience aspects, aligns with what our core ranking systems seek to reward”.
Philip Walton, “Web Vitals”, web.dev, https://web.dev/articles/vitals, publicado em 4 de maio de 2020 e atualizado em 31 de outubro de 2024. Acesso em 14 de setembro de 2026. Trechos: “The metrics that make up Core Web Vitals will evolve over time”; “Stable Core Web Vitals metrics won’t change more than once per year”; “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices”; “Tools that assess Core Web Vitals compliance should consider a page passing if it meets the recommended targets at the 75th percentile for all three of the Core Web Vitals metrics”; e “INP became a stable Core Web Vital metric in 2024”, com LCP, CLS e INP como as três métricas estáveis.
Philip Walton e Barry Pollard, “Largest Contentful Paint (LCP)”, web.dev, https://web.dev/articles/lcp, atualizado em 4 de setembro de 2025. Acesso em 14 de setembro de 2026. Trechos: “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”; “LCP includes any unload time from the previous page, connection set up time, redirect time, and other Time To First Byte (TTFB) delays”; “sites should strive to have Largest Contentful Paint of 2.5 seconds or less”; e, no texto da imagem dos limites, “poor values are greater than 4.0 seconds, and anything in between needs improvement”.
Ajuda do Search Console, “Core Web Vitals report”, https://support.google.com/webmasters/answer/9205520, versão em inglês (a versão em português traz aviso de tradução por IA). Acesso em 14 de setembro de 2026. Trechos: o relatório se baseia em “real world usage data (sometimes called field data)”; “Only indexed URLs can appear in this report”; “It shows a sample of pages”; “Data is assigned to the actual URL, not the canonical URL”; “the URL group’s status is its most poorly performing metric”; “If a URL group does not have a minimum amount of reporting data for both LCP and CLS, the URL is omitted from the report”; “It is assumed that these groups have a common framework and the reasons for any poor behavior of the group will likely be caused by the same underlying reasons”; o grupo de origem para grupos sem dados; “75% of page requests” “in the last 28 days”; a tabela de limites (LCP <=2.5s, <=4s, >4s; INP <=200ms, <=500ms, >500ms; CLS <=0.1, <=0.25, >0.25); “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”; “We recommend fixing everything labeled ‘Poor’ first, then prioritize your work either by issues that affect the most URLs, or by issues that affect your most important URLs”; a validação, “Click Start Tracking to start a 28-day monitoring session”, “The presence of that issue in any URL is enough to mark the issue as not fixed” e “Start tracking does not trigger re-indexing or any other active behavior from Google”; o caso de “a borderline status for many pages”; “PageSpeed Insights strips all parameter data from the URL”; e a definição de CLS, “CLS measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page”. Os rótulos em inglês são Good, Need improvement e Poor; a tradução “bom, precisa melhorar e ruim” é do autor.
Jeremy Wagner e Barry Pollard, “Interaction to Next Paint (INP)”, web.dev, https://web.dev/articles/inp, atualizado em 2 de setembro de 2025. Acesso em 14 de setembro de 2026. Trechos: INP observa “the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page”; “The final INP value is the longest interaction observed, ignoring outliers”; “we ignore one highest interaction for every 50 interactions”; a latência vai até “the moment the browser is next able to paint a frame”; “hovering, zooming, or scrolling” não são observados; os limites “below or at 200 milliseconds” (bom), “above 200 milliseconds and below or at 500 milliseconds” (precisa melhorar) e “above 500 milliseconds” (ruim); INP vazio quando “the user never clicked, tapped, or pressed a key”, quando houve só rolagem ou quando “The page is being accessed by a bot”; e “some lab tools won’t report a page’s INP because they only observe the loading of a page without any interactions. In such cases, Total Blocking Time (TBT) may be a reasonable proxy metric for INP, but it’s not a substitute for INP in and of itself”.
web.dev, “First Input Delay (FID)”, https://web.dev/articles/fid, página atualizada em 6 de outubro de 2024. Acesso em 14 de setembro de 2026. Trechos: “FID measures the time from when a user first interacts with a page”; “FID only measures the ‘delay’ in event processing”; e o aviso “First Input Delay (FID) is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric. As a consequence, support for FID ended on September 9, 2024.”
Jeremy Wagner e Rick Viscomi, “Interaction to Next Paint becomes a Core Web Vital on March 12”, web.dev, 31 de janeiro de 2024, https://web.dev/blog/inp-cwv-march-12. Acesso em 14 de setembro de 2026. Trechos: o Chrome “introduced Interaction to Next Paint (INP) as an experimental metric in May 2022. Last year, INP became a pending metric”; e “INP will officially become a Core Web Vital and replace FID on March 12 of this year”.
Google Search Central Blog, “Introducing INP to Core Web Vitals”, 10 de maio de 2023, https://developers.google.com/search/blog/2023/05/introducing-inp; e Google Search Central, “Latest Google Search documentation updates”, https://developers.google.com/search/updates, entrada de 12 de março de 2024. Acesso em 14 de setembro de 2026. Trechos: “In early 2020, Google’s Chrome Team introduced the Core Web Vitals”; “When INP replaces FID in March 2024, the Search Console report will stop showing FID metrics and use INP as the new metric for responsiveness”; e, no registro de 12 de março de 2024, “Additionally updated to reflect that INP is now a Core Web Vital”.
Milica Mihajlija e Philip Walton, “Cumulative Layout Shift (CLS)”, web.dev, https://web.dev/articles/cls, página atualizada em 12 de abril de 2023. Acesso em 14 de setembro de 2026. Trechos: “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”; “one or more individual layout shifts occur in rapid succession with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration”; “Previously CLS measured the sum total of all individual layout shift scores that occurred during the entire lifespan of the page”; “Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations”; as causas “images or videos with unknown dimensions, fonts that render larger or smaller than its initial fallback, or third-party ads or widgets that dynamically resize themselves”; e “Good CLS values are 0.1 or less. Poor values are greater than 0.25.”
web.dev, “Defining the Core Web Vitals metrics thresholds”, https://web.dev/articles/defining-core-web-vitals-thresholds, publicado em 21 de maio de 2020 e atualizado em 7 de maio de 2025. Acesso em 14 de setembro de 2026. Trechos: “if at least 75 percent of page views to a site meet the ‘good’ threshold, the site is classified as having ‘good’ performance for that metric. Conversely, if at least 25 percent of page views meet the ‘poor’ threshold, the site is classified as having ‘poor’ performance”; “a 75th percentile LCP of 2 seconds is classified as ‘good’, while a 75th percentile LCP of 5 seconds is classified as ‘poor’”; “most visits to the site (3 of 4) experienced the target level of performance or better”; e “for a site with 100 visits, 25 of those visits would need to report large outlier samples for the value at the 75th percentile to be affected by outliers”.
Chrome for Developers, “Overview of CrUX”, https://developer.chrome.com/docs/crux, página atualizada em 8 de fevereiro de 2024. Acesso em 14 de setembro de 2026. Trechos: “CrUX is the Google dataset of the Web Vitals program”; e os dados são “used by Google Search to inform the page experience ranking factor”.
Chrome for Developers, “CrUX methodology”, https://developer.chrome.com/docs/crux/methodology, página atualizada em 20 de junho de 2024. Acesso em 14 de setembro de 2026. Trechos: “A page must be publicly discoverable”, com status 200 e sem noindex; “An exact number is not disclosed” sobre o mínimo de visitantes; “At this time, you cannot manually submit pages or origins for inclusion”; o usuário precisa “Enable usage statistic reporting” e “Sync their browser history”; plataformas aceitas, Chrome de computador e Android; e as exceções “Chrome on iOS”, “Android apps using WebView” e “Other Chromium browsers (for example Microsoft Edge)”.
Google for Developers, “About PageSpeed Insights”, https://developers.google.com/speed/docs/insights/v5/about, página atualizada em 21 de outubro de 2024. Acesso em 14 de setembro de 2026. Trechos: dados reais “over the previous 28-day collection period”; “PSI’s data is updated daily”; “When this happens, PSI will fall back to origin-level granularity” e “Sometimes the origin may also have insufficient data, in which case PSI will be unable to show any real-user experience data”; “the aggregation passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are Good” e “If the aggregation has insufficient data for INP, then it will pass the assessment if both the 75th percentiles of LCP and CLS are Good”; e a nota de desempenho do Lighthouse, que “analyze the given URL in a simulated environment”, com 90 ou mais como bom.
Registro da SEO Genome, 14 de setembro de 2026. PageSpeed Insights, https://pagespeed.web.dev/, endereço https://seogenome.com/, relatório criado às 06:20:46 (horário de Brasília). Bloco de experiência dos usuários com o botão “Este URL” desativado e dados da origem, “Período dos últimos 28 dias”. Celular: avaliação das Core Web Vitals “aprovado”, LCP 2,4 s, INP N/A, CLS 0,02. Computador: “aprovado”, LCP 2 s, INP N/A, CLS 0,01. Diagnóstico de laboratório no celular (Lighthouse 13.4.1, Moto G Power emulado, 4G lenta): desempenho 98.O site novo está no ar desde 2 de setembro de 2026. Acesso em 14 de setembro de 2026.
Google Search Central, “Understanding page experience in Google Search results”, https://developers.google.com/search/docs/appearance/page-experience, página atualizada em 10 de dezembro de 2025; versão em português, “Como entender a experiência na página em resultados da Pesquisa Google”, atualizada em 18 de dezembro de 2025. Acesso em 14 de setembro de 2026. Trechos: “Core Web Vitals are used by our ranking systems”; “There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience”; “getting good results in reports like Search Console’s Core Web Vitals report or third-party tools doesn’t guarantee that your pages will rank at the top of Google Search results”; “trying to get a perfect score just for SEO reasons may not be the best use of your time”; “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results”; “Our core ranking systems generally evaluate content on a page-specific basis” e “However, we do have some site-wide assessments”; e “Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases.” Na autoavaliação, o inglês pergunta “Do your pages have good Core Web Vitals?”; a versão em português diz “Suas páginas têm Core Web Vitals?”.

Core Web Vitals: as três métricas do Google, uma a uma, e quanto elas pesam