Novidades sobre Core Web Vitals: o que mudou e o que corrigir primeiro
Por Toy Wen Da, Cofundador · Atualizado em · 12 min de leitura
Traduzido do original em inglês. Ler em inglês
Se você está pesquisando novidades sobre Core Web Vitals, em geral o motivo é um alerta no Search Console ou uma mudança de métrica sobre a qual você ouviu falar. A resposta curta: o Interaction to Next Paint (INP) substituiu o First Input Delay (FID) como Core Web Vital oficial em 12 de março de 2024. Abra o relatório de Core Web Vitals no Search Console para ver quais URLs estão sinalizadas.
Antes de mexer em qualquer código, passe a página pelo Teste de velocidade do site gratuito. Ele traz as pontuações do Lighthouse e indica qual métrica dos Core Web Vitals está puxando a página para baixo. Assim, você descobre se está lidando com um problema de carregamento, de interação ou de layout antes de abrir uma única linha de código.
O que realmente mudou nos Core Web Vitals recentemente
As novidades sobre Core Web Vitals costumam chegar de dois jeitos: a troca de uma métrica ou um vazamento que confirma o quanto o Google depende do comportamento real dos usuários nos bastidores. Os dois aconteceram em 2024, e ambos ainda influenciam a forma como as equipes devem priorizar correções hoje.
A troca de FID para INP
Até 12 de março de 2024, o Google media a responsividade das páginas com o First Input Delay, ou FID. O FID olhava apenas para a primeira interação do visitante na página: um clique, um toque, uma tecla. Uma página podia passar no FID com facilidade e, mesmo assim, parecer lenta em todas as interações seguintes.
O Interaction to Next Paint corrigiu essa lacuna. O INP observa todos os cliques, toques e teclas pressionadas durante a visita inteira e informa a interação mais lenta que não tenha sido um caso isolado fora da curva. Isso importa porque os dados de uso do Chrome mostram que cerca de 90% do tempo que um visitante passa em uma página acontece depois que ela termina de carregar, e não durante o carregamento. O FID media uma fatia pequena da experiência. O INP mede a parte que os usuários realmente sentem.
Uma boa pontuação de INP fica em 200 milissegundos ou menos. Qualquer valor entre 200 e 500 milissegundos conta como "Needs improvement" (Precisa melhorar). Acima de 500 milissegundos, o Search Console marca como "Poor" (Ruim).
O vazamento da API do Content Warehouse
Em março de 2024, um conjunto de documentação interna de APIs do Google veio a público, e os comentaristas de busca passaram boa parte de 2025 analisando o material. Ele não reescreveu as regras dos Core Web Vitals. Confirmou algo que muitos profissionais de SEO já suspeitavam: as métricas públicas são um indicador indireto de um sistema de ranqueamento muito maior, baseado em cliques.
A documentação vazada, segundo relatos, faz referência a módulos ligados aos dados de uso do Chrome e a um sistema chamado NavBoost, que reordena os resultados usando cerca de 13 meses de comportamento de cliques acumulado de forma contínua. A ligação com os Core Web Vitals é uma simples relação de causa e efeito. Uma página lenta ou instável gera mais "cliques ruins": visitas em que alguém clica em um resultado, se frustra e volta direto para a página de resultados de busca. Corrigir seus Core Web Vitals não serve só para agradar um placar. Serve para eliminar um motivo para os visitantes voltarem ao Google logo de cara.
A linha do tempo mais longa
Os Core Web Vitals não surgiram do nada em 2020. O Google vem construindo esse caminho há mais de uma década:
| Ano | Mudança | Por que importa hoje |
|---|---|---|
| 2011 | A atualização Panda mira conteúdo de baixa qualidade | Estabeleceu que a qualidade percebida pelo usuário afeta o ranking, não apenas as palavras-chave |
| 2014 | O HTTPS se torna um fator de ranqueamento | Primeira vez em que um fator técnico, não relacionado ao conteúdo, foi confirmado como sinal |
| 2018 | Atualização de velocidade de página para dispositivos móveis (Mobile Page Speed) | A velocidade da página no celular ganha um sinal próprio e explícito |
| 2020 | Core Web Vitals anunciados oficialmente (atualização Page Experience) | LCP, FID e CLS se tornam o trio mensurável |
| 2024 | O FID é substituído pelo INP (12 de março) | A responsividade passa a ser medida ao longo de toda a visita, não só no primeiro clique |
Verifique seus Core Web Vitals no Google Search Console, passo a passo
O Search Console continua sendo o lugar gratuito e confiável para ver como os dados de campo do próprio Google avaliam suas páginas. Veja como abri-lo e interpretá-lo corretamente.
Abrindo o relatório
- Faça login no Google Search Console e selecione sua propriedade.
- Na barra lateral esquerda, em Experiência (Experience), clique em Core Web Vitals.
- Você verá dois gráficos de resumo: Dispositivos móveis (Mobile) e Computador (Desktop). Clique em Abrir relatório (Open report) em qualquer um deles.
- Cada relatório mostra grupos de URLs organizados por status: Ruim (Poor), Precisa melhorar (Need improvement) e Bom (Good).
Lendo os grupos de URLs
Por padrão, o Search Console não informa URLs individuais: ele agrupa páginas semelhantes, geralmente por template. Isso é proposital. Se todas as suas páginas de produto compartilham o mesmo layout, é provável que compartilhem também o mesmo problema de Core Web Vitals.
Ao clicar em um grupo "Poor", você verá:
- Qual métrica específica está falhando (LCP, INP ou CLS)
- Uma amostra das URLs afetadas
- O número de URLs naquele grupo
É aqui que uma página que ainda mostra uma avaliação de Core Web Vitals "Failed" (reprovada) costuma ser diagnosticada: por template, e não no palpite sobre uma única página.
Depois de corrigir algo
Depois de publicar uma correção, volte ao relatório e clique em Validar correção (Validate fix) no grupo de URLs afetado. O Google rastreia novamente uma amostra dessas URLs nos dias seguintes e atualiza o status quando chegam dados reais de usuários em quantidade suficiente. Isso pode levar de duas a quatro semanas, porque os dados de campo dos Core Web Vitals precisam de uma amostra real de visitas, e não de um único rastreamento.
As três métricas e seus limites
| Métrica | O que mede | Bom | Precisa melhorar | Ruim |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Tempo até o maior elemento visível ser renderizado | 2,5 segundos ou menos | 2,5–4 segundos | Mais de 4 segundos |
| INP (Interaction to Next Paint) | Atraso entre uma ação do usuário e a resposta visual seguinte | 200ms ou menos | 200–500ms | Mais de 500ms |
| CLS (Cumulative Layout Shift) | Quanto o conteúdo visível se move de forma inesperada | 0,1 ou menos | 0,1–0,25 | Mais de 0,25 |
O Google avalia as três no percentil 75 dos carregamentos de página, segundo a documentação de Core Web Vitals do web.dev. Isso significa que pelo menos três em cada quatro visitas reais precisam atingir o nível "Good" (Bom) para que a página seja aprovada no geral.
Quando o Google Search Console basta e quando não basta
Esta é a parte honesta que a maioria dos guias pula. O relatório de Core Web Vitals do Search Console é gratuito, usa dados de visitantes reais e, para muitos sites, é realmente suficiente. Mas ele tem limites reais.
Onde o Search Console resolve
- Você cuida de um único site com poucos templates. A visualização por grupos de URLs mostra exatamente qual template está com problema.
- Você está verificando uma queda pontual. Se uma única página passa a aparecer como "Poor" de repente depois de uma atualização de conteúdo, os dados de campo do Search Console somados ao Teste de velocidade do site gratuito costumam apontar a causa.
- Você só precisa de dados de campo, não de um rastreamento da causa raiz. O Search Console informa o que está acontecendo com os usuários reais. Ele não diz qual script ou imagem causou o problema.
Onde você precisa de mais do que o Search Console
- Uma página tem tráfego baixo demais para gerar dados de campo. O Google precisa de um volume mínimo de visitas reais antes de informar uma pontuação. Páginas com pouco tráfego aparecem como "sem dados", mesmo que sejam realmente lentas.
- Você precisa rastrear a causa real. O Search Console informa a métrica e o template. Ele não mostra qual script de terceiros está bloqueando a thread principal. Para isso, você precisa do Chrome DevTools ou de uma ferramenta de laboratório como o Lighthouse.
- O problema se repete a cada versão publicada. Se todo deploy reintroduz uma mudança de layout, você precisa de monitoramento no seu pipeline de build, e não de uma checagem mensal de um relatório do GSC.
- Você está em uma plataforma com causas no nível dos plugins. No Shopify, por exemplo, um app de terceiros costuma ser a origem real de uma pontuação ruim de INP, e corrigir isso significa saber quais apps do Shopify realmente ajudam nos Core Web Vitals, em vez de simplesmente adicionar mais peso de rastreamento.
Resumindo: o Search Console avisa que algo está errado e, mais ou menos, onde. Raramente diz exatamente por quê, até o nível do script ou da folha de estilo.
Causas comuns e correções por métrica
| Métrica | Causa típica | Primeira coisa a verificar | Quem costuma corrigir |
|---|---|---|---|
| LCP | A imagem principal ou o bloco de texto principal carrega tarde | O elemento LCP pode ser encontrado no HTML bruto? | Desenvolvedor front-end ou provedor de hospedagem |
| LCP | Resposta lenta do servidor (TTFB alto) | Tempo de resposta do servidor e cache | Equipe de hospedagem ou de back-end |
| INP | Uma tarefa longa de JavaScript bloqueia a thread principal | Qual ação do usuário parece atrasada? | Desenvolvedor front-end |
| INP | Scripts pesados de terceiros (anúncios, widgets de chat, rastreadores) | Auditar quais scripts rodam durante a interação | Marketing e desenvolvimento, em conjunto |
| CLS | Imagens ou anúncios sem dimensões reservadas | O layout se mexe depois do carregamento? | Desenvolvedor front-end ou equipe de conteúdo |
| CLS | Fontes da web causando reorganização do texto | Uma fonte alternativa está configurada corretamente? | Desenvolvedor front-end |
Erros comuns das equipes com as novidades sobre Core Web Vitals
A maioria dos erros vem de tratar os Core Web Vitals como uma única pontuação a ser maximizada, em vez de três problemas distintos e independentes.
- Buscar um 100 perfeito no PageSpeed Insights. O Google só se importa se você atingiu o limite "Good". Além disso, você está gastando orçamento em ganhos invisíveis.
- Testar apenas a página inicial. Sua página inicial pode estar ótima enquanto todas as páginas de produto falham. Use a visualização por grupos de URLs, e não uma checagem pontual.
- Ignorar os dados de dispositivos móveis. Os Core Web Vitals no computador costumam ser melhores do que no celular. É no celular que acontece a maior parte das visitas e do abandono.
- Corrigir todos os avisos amarelos de uma vez. Priorize primeiro as páginas ligadas a receita ou a leads. Um arquivo lento do blog pode esperar.
- Pular o teste real de interação para o INP. Uma página pode parecer rápida ao carregar e ainda assim falhar no INP no momento em que alguém toca em um menu suspenso ou em um filtro.
- Fechar o ticket antes de os dados se atualizarem. Os dados de campo precisam de visitas reais depois que a correção vai ao ar, em geral algumas semanas, antes de o status mudar.
Os Core Web Vitals também ficam ao lado de outro sinal de qualidade que o Google vem defendendo há anos: a acessibilidade. Uma página com contraste de cores ruim ou sem texto alternativo costuma falhar nos mesmos critérios definidos nas Diretrizes de Acessibilidade para Conteúdo Web (WCAG) do W3C, o padrão oficial por trás da maioria das auditorias de acessibilidade, e muitas vezes tem as mesmas causas de raiz de uma página com problemas de mudança de layout. Esse é um dos motivos pelos quais corrigir problemas de acessibilidade tende a melhorar o SEO ao mesmo tempo. Se você não tem certeza de onde está sua exposição legal, vale a pena revisar o que a lei de acessibilidade realmente exige que você corrija primeiro junto com a sua limpeza dos Core Web Vitals.
Novidades sobre Core Web Vitals para publishers e sites de notícias
Se o seu site funciona como um veículo de notícias, as novidades sobre Core Web Vitals trazem uma complicação extra: problemas de velocidade e estabilidade se somam a problemas de indexação. Um template lento não corre apenas o risco de gerar uma pontuação "Poor" de CLS, ele pode atrasar a velocidade com que os novos artigos são rastreados logo de início.
Se você busca indexação rápida e uma pontuação limpa de Core Web Vitals ao mesmo tempo, algumas correções relacionadas costumam andar juntas:
- Corrija os erros do sitemap do Google News para que os novos artigos apareçam rapidamente.
- No WordPress, confirme que a configuração do Yoast News SEO não está adicionando scripts que bloqueiam a renderização aos templates de artigos.
- Revise o guia mais amplo sobre como fazer artigos de notícias serem indexados e ranqueados rapidamente, já que um template de artigo pesado muitas vezes falha ao mesmo tempo no INP e nas verificações de velocidade de rastreamento.
E se o seu negócio também aparece na busca local, vale acompanhar as mudanças recentes no Google Business Profile junto com o seu trabalho em Core Web Vitals. Ambos alimentam o mesmo quadro geral de experiência de página que o Google está construindo sobre a sua marca.
Por que isso se conecta ao comportamento de cliques
Lembre-se do mecanismo do NavBoost mencionado antes: o Google acompanha os cliques que voltam direto para a página de resultados como um sinal negativo. Uma página lenta ou instável produz mais deles. Melhorar seus Core Web Vitals, na prática, protege o seu desempenho de taxa de cliques. Se você quer entender a matemática por trás do que conta como um resultado forte, vale uma leitura rápida na fórmula da taxa de cliques (CTR) e nos benchmarks: uma página rápida e estável é uma das formas mais baratas de proteger esse número.
Priorizando as correções: um roteiro simples
Em vez de corrigir cada URL sinalizada na ordem em que o Search Console as lista, siga esta sequência:
- Escolha primeiro os templates ligados a receita ou a leads: páginas de produto, páginas de serviço, landing pages.
- Confira os dados de campo antes dos dados de laboratório. O relatório do Search Console e os dados de campo do CrUX refletem visitas reais; ferramentas de laboratório como o Lighthouse simulam apenas uma execução.
- Identifique a métrica específica que está falhando. LCP, INP e CLS exigem correções diferentes, e um ticket genérico de "deixar mais rápido" desperdiça o tempo do desenvolvedor.
- Teste uma URL representativa do grupo antes de mudar o template inteiro.
- Valide em uma ferramenta de laboratório antes de publicar e, depois, valide a correção no Search Console.
- Monitore por algumas semanas. Os dados de campo levam tempo para refletir uma correção publicada.
Perguntas frequentes
Quais são as últimas novidades sobre Core Web Vitals em 2026?
A maior mudança recente continua sendo a troca do First Input Delay pelo Interaction to Next Paint em 12 de março de 2024. Desde então, a maior parte das "novidades" tem sido análise da documentação vazada do Google que confirma como o comportamento de cliques e os Core Web Vitals interagem, e não uma nova métrica oficial.
O Google removeu os Core Web Vitals do ranqueamento?
Não. O Google já disse várias vezes que os Core Web Vitals são um entre muitos sinais e que a relevância e a qualidade do conteúdo ainda pesam mais. Core Web Vitals ruins não impedem uma página de ranquear, mas podem fazer com que uma página, em situação de empate, perca para um concorrente mais rápido.
Quanto tempo leva para uma correção aparecer no Search Console?
Os dados de campo precisam de uma amostra nova de visitas reais depois que você publica a correção, o que normalmente leva de duas semanas a um mês até o status ser atualizado no relatório de Core Web Vitals.
O PageSpeed Insights é o mesmo que o relatório de Core Web Vitals do Search Console?
Não. O PageSpeed Insights testa uma URL por vez e combina dados de laboratório e de campo. O relatório do Search Console agrupa muitas URLs por template usando apenas dados de campo de visitas reais, o que é melhor para priorizar correções em um site inteiro.
O INP substitui os Core Web Vitals por completo ou apenas uma métrica?
O INP substituiu apenas o FID. LCP e CLS continuam iguais. Os três Core Web Vitals atuais são LCP, INP e CLS.
O que fazer com isso agora
Abra hoje o relatório de Core Web Vitals no Search Console, ordene por status e escolha o grupo de URLs "Poor" ligado ao template de maior tráfego. Passe uma página desse grupo pelo Teste de velocidade do site gratuito para confirmar qual das três métricas, LCP, INP ou CLS, está de fato falhando antes de passar a demanda para um desenvolvedor. Se preferir ver o que uma revisão técnica completa e de Core Web Vitals do seu site revelaria, fale com a equipe e receba um relatório de amostra montado com as suas próprias URLs. Essa é a novidade prática sobre Core Web Vitals que de fato move o ranking: não uma nova métrica para perseguir, mas um template corrigido.
Recursos / Referências
Fontes
Sobre o autor
O SearchBlueprint pesquisou, escreveu e avaliou este artigo com o mesmo pipeline de conteúdo que nossos clientes usam nos próprios sites. A nota que aparece na assinatura é a que nosso mecanismo de conteúdo deu a esta página antes de ela ser publicada. Nada aqui passa por revisão manual, e esse é justamente o ponto: é o resultado do produto, publicado onde qualquer pessoa pode conferir.