Core Web Vitals em 2026: guia prático para corrigir LCP, INP e CLS antes que o Google puna seu site

Desde que o Google tornou o Interaction to Next Paint (INP) um Core Web Vital oficial, substituindo o antigo First Input Delay, o PageSpeed Insights e o relatório de Core Web Vitals do Search Console passaram a avaliar a responsividade do seu site de um jeito mais rigoroso. Na prática, isso significa que sites que pareciam "rápidos o suficiente" pelas métricas antigas podem estar reprovando silenciosamente nos testes atuais — e isso afeta tanto a experiência do visitante quanto o posicionamento nas buscas.

Se você nunca parou para medir esses três indicadores no seu site, loja virtual ou projeto de cliente, este guia mostra o que cada um significa, quais são os limites considerados bons pelo Google e, principalmente, o que fazer na prática para corrigir cada um.

Os três indicadores e o que o Google considera "bom"

O Core Web Vitals é composto por três métricas. Para um site ser aprovado, pelo menos 75% das visitas reais precisam cair na faixa "boa" de cada uma:

LCP (Largest Contentful Paint) — mede quanto tempo leva para o maior elemento visível da página (geralmente uma imagem de destaque ou bloco de texto) terminar de carregar. Bom: até 2,5 segundos. Precisa melhorar: entre 2,5 e 4 segundos. Ruim: acima de 4 segundos.

INP (Interaction to Next Paint) — mede quanto tempo a página demora para responder visualmente depois que alguém clica, toca ou digita algo. Bom: até 200 milissegundos. Acima disso, a experiência começa a parecer "travada".

CLS (Cumulative Layout Shift) — mede o quanto os elementos da página "pulam" de lugar enquanto ela carrega (por exemplo, quando um banner carrega depois e empurra o texto para baixo). Bom: até 0,1. Precisa melhorar: entre 0,1 e 0,25. Ruim: acima de 0,25.

Passo 1: meça antes de sair alterando qualquer coisa

Antes de qualquer ajuste, rode o PageSpeed Insights (nas versões mobile e desktop separadamente) e confira o relatório de "Core Web Vitals" do Google Search Console, que mostra o histórico real de visitantes nos últimos meses — não apenas um teste pontual. Isso evita o erro comum de otimizar para o que o teste de laboratório mostra e ignorar o que os usuários reais estão vivenciando.

Passo 2: como melhorar o LCP

• Comprima e redimensione imagens antes de subir para o site — especialmente a imagem de destaque de posts e banners de topo.
• Use formatos modernos (WebP ou AVIF) em vez de PNG/JPEG pesados.
• Carregue a imagem principal da página sem lazy loading (ela precisa aparecer primeiro) e aplique lazy loading apenas nas imagens abaixo da dobra.
• Evite fontes customizadas que bloqueiam a renderização do texto; quando usar, adicione font-display: swap.
• Verifique o tempo de resposta do servidor (TTFB). Se a hospedagem demora para responder antes mesmo do navegador começar a desenhar a página, nenhuma otimização de frontend resolve sozinha — esse é o momento de avaliar se o plano de hospedagem atual ainda atende ao volume de acessos do site.

Passo 3: como melhorar o INP

• Reduza a quantidade de plugins ativos no WordPress — cada script adicional compete por processamento no navegador do visitante.
• No Elementor, evite empilhar muitas animações e efeitos de JavaScript na mesma página, especialmente em pop-ups que disparam ao carregar.
• Quebre tarefas de JavaScript longas em pedaços menores (se você tem acesso a desenvolvimento) para que o navegador consiga responder a cliques no meio da execução.
• Adie scripts de terceiros (chat, pixels de anúncio, analytics) para carregar depois da interação inicial do usuário, não junto com o restante da página.

Passo 4: como melhorar o CLS

• Sempre defina altura e largura (ou aspect-ratio) em imagens e vídeos, mesmo que o layout seja responsivo.
• Reserve um espaço fixo para anúncios, banners de cookies e pop-ups antes que eles carreguem, em vez de deixá-los "empurrar" o conteúdo.
• Evite inserir conteúdo dinamicamente acima do que o usuário já está lendo, salvo em resposta a uma ação dele.

Erros comuns que atrasam a correção

Um erro frequente é tentar resolver tudo só no frontend quando o problema de fundo é a infraestrutura: servidor sem cache adequado, sem CDN ou com recursos insuficientes para o tráfego do site. Outro erro é testar apenas na página inicial e esquecer páginas de produto, posts e landing pages, que podem ter elementos pesados próprios (carrosséis, vídeos incorporados, formulários complexos).

Se depois de otimizar imagens, scripts e layout o site de hospedagem continuar lento, vale considerar migrar para um plano com mais recursos ou para uma hospedagem otimizada para o seu tipo de projeto — seja um site com Elementor Pro, uma loja digital ou um site estático em HTML&JS, caso do produto Pages da Rockfy. A migração, quando feita com acompanhamento técnico e sem downtime, não deveria ser motivo para postergar essa correção.

Checklist rápido antes de publicar a próxima página

1. Imagem principal otimizada e sem lazy loading?
2. Fontes customizadas com font-display: swap?
3. Scripts de terceiros carregando depois da interação inicial?
4. Dimensões fixas em imagens, vídeos e espaços de anúncio?
5. Tempo de resposta do servidor testado sob carga real, não só em horário de baixo tráfego?

Fontes consultadas

Google / web.dev — "Interaction to Next Paint is officially a Core Web Vital" (web.dev/blog/inp-cwv-launch); CoreWebVitals.io — páginas de referência sobre thresholds de LCP e CLS (corewebvitals.io).

Imagem de capa: ilustração gerada por inteligência artificial para fins editoriais.