Fundamentos

Core Web Vitals em 2026: Limiares de LCP, INP e CLS Explicados

Core Web Vitals continuam sendo um sinal de ranking confirmado do Google em 2026. Este guia detalha os limiares exatos de LCP, INP e CLS, o que causa falhas e as correções mais rápidas para atingir pontuações 'Boas'.

Por Daniel MercerPublicado em 24 de maio de 20268 min de leitura

Core Web Vitals são as três métricas de experiência do usuário do Google usadas como sinal de ranking. Em 2026, as métricas são LCP (Largest Contentful Paint), INP (Interaction to Next Paint) e CLS (Cumulative Layout Shift). Atingir o limite de "Bom" em todos os três se correlaciona diretamente com melhor visibilidade na pesquisa e menores taxas de rejeição.

O Que São Core Web Vitals?#

Core Web Vitals são um subconjunto dos sinais de Experiência da Página do Google. Cada métrica quantifica uma dimensão distinta de como os usuários reais percebem uma página: velocidade de carregamento, capacidade de resposta à interação e estabilidade visual. O Google os mede usando dados de campo coletados de usuários do Chrome e exibe os resultados no Search Console, PageSpeed Insights e no Chrome UX Report (CrUX).

Qual É o Limiar de LCP em 2026?#

LCP mede quanto tempo leva para o maior elemento de conteúdo visível—normalmente uma imagem principal, um grande bloco de texto ou um pôster de vídeo—ser renderizado na tela. Os limiares são:

Bom: ≤ 2,5 segundos
Precisa Melhorar: 2,5 s – 4,0 s
Ruim: > 4,0 segundos

Esses limiares não mudaram desde que o LCP entrou no Core Web Vitals, e o Google não sinalizou nenhuma revisão para 2026. A barra de 2,5 segundos é deliberadamente agressiva: ela força os sites a servir imagens otimizadas, usar uma CDN rápida e eliminar recursos que bloqueiam a renderização.

O que causa um LCP lento?

Os assassinos de LCP mais comuns são:

Imagens principais não otimizadas — PNGs ou JPEGs grandes servidos sem formatos modernos como WebP ou AVIF.
Recursos que bloqueiam a renderização — scripts síncronos ou CSS que atrasam a primeira renderização do navegador.
Resposta lenta do servidor (TTFB) — um Time to First Byte acima de ~600 ms consome diretamente o tempo de LCP.
Lazy-loading do elemento LCP — loading="lazy" na imagem principal adia o recurso mais importante.
Nenhuma dica de preload — falha ao usar <link rel="preload"> para a imagem LCP.

Como corrigir o LCP

Identifique o elemento LCP usando o PageSpeed Insights ou a seção "Largest Contentful Paint" do Chrome DevTools.
Converta a imagem para WebP ou AVIF e sirva-a no tamanho de exibição correto.
Adicione <link rel="preload" as="image"> para a imagem LCP no <head>.
Mude para um host ou CDN com um TTFB abaixo de 200 ms no 75º percentil.
Remova ou adie quaisquer scripts que bloqueiem a renderização acima da dobra.

Qual É o Limiar de INP em 2026?#

O INP substituiu o First Input Delay (FID) como um Core Web Vital em março de 2024 e continua sendo a métrica de interatividade em 2026. O INP mede a latência de todas as interações do usuário—cliques, toques e eventos de teclado—durante todo o ciclo de vida da página e, em seguida, reporta o valor do pior caso no 98º percentil.

Bom: ≤ 200 milissegundos
Precisa Melhorar: 201 ms – 500 ms
Ruim: > 500 milissegundos

Ao contrário do FID, que media apenas a primeira interação, o INP penaliza qualquer interação lenta durante uma visita. Isso o torna muito mais representativo da frustração real do usuário.

O que causa um INP alto?

Tarefas longas na thread principal — JavaScript que bloqueia a thread principal por mais de 50 ms atrasa o processamento de entrada.
Handlers de eventos pesados — listeners onClick ou onChange que acionam atualizações DOM caras.
Scripts de terceiros — análises, widgets de bate-papo e scripts de anúncios que competem por tempo na thread principal.
Custo de hidratação em SPAs — sites React, Vue ou Angular que rehidratam grandes árvores de componentes no carregamento.

Como corrigir o INP

Abra Chrome DevTools → painel Desempenho → grave uma interação e identifique tarefas longas.
Divida tarefas longas em pedaços menores usando scheduler.yield() ou setTimeout(..., 0) para ceder ao navegador.
Audite scripts de terceiros com os painéis Coverage e Network; adie ou remova os não críticos.
Use startTransition (React) ou APIs de framework equivalentes para despriorizar atualizações de estado não urgentes.
Minimize o tamanho do DOM — páginas com dezenas de milhares de nós têm recálculo de estilo mais lento após cada interação.

Qual É o Limiar de CLS em 2026?#

O CLS mede mudanças visuais inesperadas—elementos pulando enquanto a página carrega. Ele é pontuado como um agregado sem unidade de todas as mudanças de layout não causadas pela entrada do usuário.

Bom: ≤ 0,1
Precisa Melhorar: 0,1 – 0,25
Ruim: > 0,25

Um CLS de 0,1 pode parecer abstrato, mas na prática significa que o impacto combinado das mudanças deve ser pequeno em relação ao viewport. Um único banner grande ou uma imagem sem tamanho pode levar uma página para a faixa "Ruim" instantaneamente.

O que causa um CLS alto?

Imagens sem atributos width e height — o navegador não pode reservar espaço antes que a imagem seja carregada.
Conteúdo injetado dinamicamente — anúncios, banners de cookies ou popups de newsletter que empurram o conteúdo para baixo.
Web fonts causando FOUT/FOIT — trocas de fontes que mudam os comprimentos de linha e reorganizam blocos de texto.
Embeds de carregamento tardio — iframes para YouTube ou Twitter que não têm um contêiner de proporção reservado.

Como corrigir o CLS

Sempre especifique width e height nas tags <img> ou use aspect-ratio em CSS.
Reserve espaço para blocos de anúncios com um contêiner de min-height mesmo antes que o anúncio seja carregado.
Use font-display: optional ou pré-carregue web fonts críticos para evitar trocas tardias.
Envolva iframes em um contêiner de proporção CSS (truque padding-top ou aspect-ratio: 16/9).
Evite inserir conteúdo acima do conteúdo existente após o carregamento inicial.

Como Os Core Web Vitals São Medidos?#

O Google usa dados de campo (medições de usuários reais do CrUX) como o sinal de ranking, não dados de laboratório. O PageSpeed Insights mostra ambos, mas apenas os dados de campo afetam os rankings. Uma página precisa passar em todas as três métricas no 75º percentil de carregamentos de página para ser considerada "Boa" para a Experiência da Página.

As ferramentas de laboratório—Lighthouse, WebPageTest—são inestimáveis para o diagnóstico, mas não podem substituir os dados do CrUX. Se o CrUX tiver tráfego insuficiente para um URL, o Google agrega no nível da origem.

Como Monitorar Core Web Vitals em Escala#

Para sites com centenas ou milhares de páginas, a verificação manual é impraticável. A abordagem correta:

Search Console → relatório Core Web Vitals — visualização agrupada de URLs Bons/Precisa Melhorar/Ruins por métrica.
CrUX API ou BigQuery — extraia dados de campo brutos programaticamente para painéis personalizados.
Real User Monitoring (RUM) — bibliotecas como web-vitals.js enviam LCP, INP e CLS de sessões reais para sua análise.
Auditorias automatizadas — ferramentas como SeoChatAI podem revelar problemas de Core Web Vitals juntamente com SEO técnico, acessibilidade e auditorias de prontidão para IA em uma única passagem.

A Aprovação nos Core Web Vitals Garante Melhores Rankings?#

Aprovar todas as três métricas no limite "Bom" é uma condição necessária, mas não suficiente, para os principais rankings. Os Core Web Vitals são um sinal de desempate: quando a qualidade, relevância e autoridade do conteúdo são iguais, a página com melhores sinais de experiência terá uma classificação mais alta. O Google nunca divulgou o peso exato, mas o sinal é real e documentado em sua documentação de sistemas de ranking.

A conclusão prática: corrija os Core Web Vitals para eliminar um limite de ranking e, em seguida, concentre-se no conteúdo e na autoridade para rompê-lo.

Core Web Vitals e IA Search em 2026#

Como as visões gerais geradas por IA (anteriormente SGE) agora aparecem nos resultados da Pesquisa do Google, os sinais de experiência da página influenciam se uma página é citada como fonte. É menos provável que as páginas que são lentas, visualmente instáveis ou não responsivas sejam apresentadas. Executar uma auditoria completa do site por meio do SeoChatAI oferece uma visão combinada de suas pontuações CWV, preparação de dados estruturados e elegibilidade para citação de IA—o que é cada vez mais relevante, pois os mecanismos de resposta de IA superam os cliques tradicionais de links azuis.

Referência Rápida: Limiares do Core Web Vitals 2026#

Métrica	Bom	Precisa Melhorar	Ruim
LCP	≤ 2,5 s	2,5 s – 4,0 s	> 4,0 s
INP	≤ 200 ms	201 ms – 500 ms	> 500 ms
CLS	≤ 0,1	0,1 – 0,25	> 0,25

Todos os limiares se aplicam no 75º percentil dos dados de campo. Uma única página com um punhado de carregamentos muito lentos pode puxar o agregado para o território "Ruim"—razão pela qual o monitoramento no nível do percentil importa mais do que as pontuações médias.

Core Web Vitals 2026: LCP, INP, and CLS Thresholds Explained — illustration 1

Partilhar este artigoX LinkedIn

Publicado em 24 de mai. de 2026

Perguntas frequentes

Quais são os limites do Core Web Vitals em 2026?

Em 2026, os limites 'Bons' são: LCP ≤ 2,5 segundos, INP ≤ 200 milissegundos e CLS ≤ 0,1. Todos os três são medidos no 75º percentil dos dados de campo do usuário real. As páginas devem passar em todos os três para serem consideradas 'Boas' para o sinal de Experiência da Página do Google.

O Google substituiu o FID por INP?

Sim. O Google substituiu oficialmente o First Input Delay (FID) por Interaction to Next Paint (INP) em março de 2024. O INP mede a latência de todas as interações durante uma visita à página, não apenas a primeira, tornando-a uma métrica de responsividade mais abrangente e representativa.

A aprovação no Core Web Vitals melhora os rankings do Google?

A aprovação no Core Web Vitals remove um limite de ranking, em vez de garantir as primeiras posições. O Google usa o sinal como um desempate entre páginas com qualidade e relevância de conteúdo semelhantes. Falhar no CWV pode suprimir os rankings; aprová-los desbloqueia todo o peso de seus sinais de conteúdo e autoridade.

Como verifico minha pontuação do Core Web Vitals?

Use o relatório Core Web Vitals do Google Search Console para dados de campo agrupados por URL. O PageSpeed Insights mostra dados de laboratório e de campo para páginas individuais. Para monitoramento de usuários reais em todas as páginas, implemente a biblioteca web-vitals.js ou use uma plataforma que agregue dados CrUX automaticamente.

Por que meu LCP está lento, mesmo que minhas imagens estejam otimizadas?

Imagens otimizadas são necessárias, mas não suficientes. Causas comuns negligenciadas incluem um TTFB lento (resposta do servidor acima de ~600 ms), aplicar lazy-loading à própria imagem LCP, perder uma dica de preload no head HTML e scripts de bloqueio de renderização que atrasam quando o navegador pode até começar a buscar a imagem.

O que é uma boa pontuação de INP e como faço para diminuí-la?

Um INP em ou abaixo de 200 ms é 'Bom'. Para reduzir o INP, divida tarefas longas de JavaScript em pedaços menores usando scheduler.yield(), audite e adie scripts de terceiros, minimize o tamanho do DOM e use APIs de framework como startTransition do React para despriorizar atualizações de IU não urgentes.

O CLS afeta páginas que carregam rápido?

Sim. CLS é independente da velocidade de carregamento. Uma página pode alcançar um LCP rápido, mas ainda ter um CLS ruim se as imagens não tiverem atributos de dimensão, os anúncios injetarem conteúdo acima da dobra ou as web fonts causarem reflow de texto. A estabilidade visual deve ser tratada separadamente das otimizações de tempo de carregamento.