Core Web Vitals em 2026: limites e o que mudou
As métricas não mudaram este ano. Boa parte das ferramentas ao redor delas, sim. Veja o que de fato é verdade agora.
Três métricas, e as mesmas três desde 2024. O Largest Contentful Paint deve ficar em 2,5 segundos ou menos, o Interaction to Next Paint em 200 milissegundos ou menos e o Cumulative Layout Shift em 0,1 ou menos. Cada uma é avaliada no percentil 75 dos carregamentos reais, separando celular e desktop.
Quais são os limites dos Core Web Vitals em 2026?
Eles vêm direto das páginas de cada métrica no web.dev, que é onde o Google publica as definições. Tudo é medido no percentil 75 dos carregamentos, ou seja, você passa quando três quartos dos seus visitantes reais têm um bom resultado, não quando o seu notebook tem.
| Métrica | O que mede | Bom | Precisa melhorar | Ruim |
|---|---|---|---|---|
| LCP | Carregamento: quando o maior elemento visível termina de renderizar | 2,5 segundos ou menos | 2,5 a 4,0 segundos | Acima de 4,0 segundos |
| INP | Responsividade em todas as interações da página | 200 ms ou menos | Acima de 200 ms até 500 ms | Acima de 500 ms |
| CLS | Estabilidade visual: a pior rajada de deslocamento inesperado | 0,1 ou menos | Acima de 0,1 até 0,25 | Acima de 0,25 |
Os Core Web Vitals mudaram mesmo em 2026?
Não. Nem o conjunto de métricas, nem um único limite. A última mudança estrutural foi em 12 de março de 2024, quando o Interaction to Next Paint se tornou um Core Web Vital estável e o First Input Delay foi aposentado, o que o web.dev anunciou no post INP becomes a Core Web Vital. De lá para cá são três métricas estáveis, sem nenhuma substituta experimental ou pendente anunciada. A regra do próprio Google é que os Core Web Vitals estáveis não mudam mais de uma vez por ano, e 2025 e 2026 passaram sem nenhuma mudança.
O que mexeu foi a camada de medição. As notas de versão do Chrome UX Report, no Chrome for Developers, registram que as subpartes de imagem do LCP e os tipos de recurso do LCP chegaram à API do CrUX em janeiro de 2025, que a dimensão ECT foi retirada do BigQuery na mesma leva e que o antigo CrUX Dashboard foi descontinuado no fim de novembro de 2025. À parte disso, o trabalho de soft navigations chegou ao Chrome 151, permitindo que aplicações de página única atribuam LCP, INP e CLS a cada mudança de rota, e não a uma única visualização infinita. A documentação diz de forma explícita que ainda não está decidido como as soft navigations serão reportadas no CrUX, então isso ainda não afeta os seus números no Search Console.
Se disseram a você que uma métrica nova entrou este ano, pergunte qual. Não existe.
Como corrigir um LCP lento
Quase todo LCP ruim é um problema de descoberta do recurso. O guia das principais correções do web.dev coloca três coisas à frente: garantir que o recurso do LCP apareça no HTML de origem em vez de ser injetado por script, marcá-lo com fetchpriority="high" e reduzir o Time to First Byte com um CDN que armazene em cache o próprio documento. Além disso, busque navegações instantâneas com o cache de avanço e retorno ou com regras de especulação, para que a próxima página já esteja pronta quando vier o clique.
Como corrigir um INP alto
O INP se divide em três partes: o atraso de entrada antes de o seu handler rodar, a duração do processamento desse handler e o atraso de apresentação até o próximo quadro ser pintado. A pontuação relatada é, grosso modo, a pior interação da página, ignorando um ponto fora da curva a cada cinquenta interações. As correções recomendadas são ceder o controle com frequência, para que tarefas longas parem de bloquear a thread principal, entregar menos JavaScript já de saída e manter as atualizações de renderização pequenas, com um DOM enxuto e contenção de CSS. Audite o seu gerenciador de tags. Costuma estar ali.
Como corrigir deslocamento de layout
O CLS olha para a pior rajada de deslocamento, definida como deslocamentos separados por menos de um segundo dentro de uma janela de no máximo cinco segundos. Defina largura e altura explícitas ou uma proporção em toda imagem e todo embed, reserve espaço para o que é injetado tarde, como banners e barras de consentimento, mantenha a página elegível para o cache de avanço e retorno e anime com transform em vez de propriedades que forçam layout.
Onde medir os Core Web Vitals?
Dados de campo primeiro, sempre. As ferramentas de laboratório servem para pegar regressões antes de publicar, e o web.dev é direto ao dizer que elas não substituem usuários reais em aparelhos reais. O Chrome User Experience Report é o conjunto de dados de campo. O PageSpeed Insights e o relatório de Core Web Vitals no Search Console leem dele, e a biblioteca JavaScript web-vitals entrega os seus próprios números com muito menos atraso que uma janela móvel de 28 dias. O Chrome DevTools e o Lighthouse cobrem o lado de laboratório. Use os dois, mas só o dado de campo decide se você passa.
Os Core Web Vitals ainda afetam o ranqueamento no Google?
O Google Search Central ainda documenta os Core Web Vitals como parte da experiência na página, descrevendo-os como métricas que medem a experiência real do usuário e dizendo que se alinham ao que os seus sistemas centrais de ranqueamento buscam recompensar. Isso é deliberadamente mais suave que um fator de ranqueamento. Trate como critério de desempate entre páginas equivalentes e como algo que claramente afeta conversão, faça a busca o que fizer. A mesma lógica vale para o resto da sua base técnica, que é o que o nosso verificador de prontidão para IA analisa.
Uma coisa que vale dizer a quem persegue a nota perfeita: passar nos três limites no percentil 75 é a linha de chegada. Não existe faixa de bônus acima disso. Depois que estiver tudo verde, a próxima hora rende mais investigando se os rastreadores conseguem chegar à página, o que é uma checagem de cinco minutos no seu robots.txt.