Core Web Vitals: O Que São LCP, CLS e INP e Como Melhorar a Nota do Seu Site

O Google usa os Core Web Vitals como fator de ranking desde 2021. Isso significa que se o LCP do seu site está acima de 2,5 segundos ou o CLS acima de 0,1, você está perdendo posições para concorrentes mais rápidos — mesmo que o seu conteúdo seja melhor. Não é uma questão de opinião: é o algoritmo de busca funcionando contra você.

A boa notícia é que cada métrica tem causas específicas e soluções bem definidas. Este guia explica o que cada indicador mede, como diagnosticá-lo e quais ações têm o maior impacto prático.

O Que São os Core Web Vitals?

Core Web Vitals são três métricas definidas pelo Google para medir a experiência real do usuário em uma página web. Elas avaliam velocidade de carregamento, estabilidade visual e responsividade a interações.

LCP — Largest Contentful Paint (Maior Renderização de Conteúdo)

O LCP mede quanto tempo leva para o maior elemento visível da página — normalmente uma imagem principal, um banner ou um bloco de texto — ser totalmente renderizado na tela.

Thresholds:

✅ Bom: até 2,5 segundos
⚠️ Precisa melhorar: 2,5 s a 4,0 s
❌ Ruim: acima de 4,0 segundos

Um LCP alto é o problema de performance mais comum. Ele afeta diretamente a percepção de velocidade do usuário: a maioria das pessoas decide se vai esperar a página carregar nos primeiros 2 a 3 segundos.

O que costuma causar LCP alto:

Imagens sem otimização (PNG, JPEG grandes sem compressão)
Fontes web bloqueando a renderização
TTFB (Time to First Byte) lento por hosting inadequado ou sem CDN
Scripts de terceiros carregando antes do conteúdo principal

CLS — Cumulative Layout Shift (Deslocamento Cumulativo de Layout)

O CLS mede a instabilidade visual de uma página: o quanto os elementos "pulam" na tela enquanto o conteúdo carrega. Se você já tentou clicar em um botão e ele se moveu no último segundo fazendo você clicar em outro lugar, você experimentou um CLS alto.

Thresholds:

✅ Bom: abaixo de 0,1
⚠️ Precisa melhorar: 0,1 a 0,25
❌ Ruim: acima de 0,25

Exemplos comuns de CLS:

Imagens sem atributos width e height definidos
Anúncios ou banners que aparecem e empurram o conteúdo
Fontes web que substituem o texto provisório (FOIT/FOUT)
Conteúdo dinâmico injetado acima de elementos existentes

INP — Interaction to Next Paint (e TBT como proxy)

O INP substituiu o FID (First Input Delay) em março de 2024 como métrica oficial. Ele mede a latência de todas as interações do usuário com a página — cliques, toques, digitação — e reporta o pior caso.

O TBT (Total Blocking Time) é o substituto de laboratório para o INP: mede o tempo em que a thread principal do browser está bloqueada, impedindo resposta a interações.

Thresholds do INP:

✅ Bom: até 200 ms
⚠️ Precisa melhorar: 200 ms a 500 ms
❌ Ruim: acima de 500 ms

Como Medir os Core Web Vitals do Seu Site

Antes de otimizar, você precisa saber onde está o problema. O Teste de Velocidade do FlashMon executa uma análise completa da sua página e retorna:

Nota de 0 a 100 consolidada (similar ao Lighthouse/PageSpeed)
LCP, CLS e TBT medidos individualmente com status visual
Breakdown por tipo de recurso — JavaScript, imagens, CSS, fontes, third-party
Top 10 recursos mais pesados com tamanho e tempo de carregamento

Isso permite identificar exatamente qual arquivo está puxando o LCP para cima ou qual script está bloqueando a thread principal, sem precisar instalar extensões ou rodar o Lighthouse manualmente.

Como Melhorar Cada Métrica

Melhorando o LCP

1. Otimize imagens

Imagens são a causa mais frequente de LCP alto. Use formato WebP (20–35% menor que JPEG com qualidade equivalente) ou AVIF para imagens estáticas. Se você usa Next.js, o componente <Image> faz isso automaticamente.

Para imagens abaixo da dobra (não visíveis no carregamento inicial), adicione loading="lazy". Para a imagem principal da página — o elemento candidato ao LCP — faça o oposto: adicione fetchpriority="high" para garantir que o browser a priorize.

2. Faça preload de fontes críticas

Fontes web bloqueiam a renderização por padrão. Adicione no <head>:

<link rel="preload" href="/fonts/sua-fonte.woff2" as="font" type="font/woff2" crossorigin>

Combine isso com font-display: swap no CSS para exibir texto provisório enquanto a fonte carrega, evitando tela em branco.

3. Reduza o TTFB com hosting e CDN

Se o servidor demora mais de 600 ms para enviar o primeiro byte, o LCP será alto independentemente de outras otimizações. Considere:

Migrar para um hosting com servidores mais próximos do seu público
Usar uma CDN (Cloudflare, Fastly, Vercel Edge) para servir conteúdo estático da edge
Habilitar cache de resposta no servidor para páginas com conteúdo estático

Melhorando o CLS

1. Defina dimensões explícitas em imagens e vídeos

Todo elemento <img> e <video> deve ter width e height definidos no HTML. Isso permite que o browser reserve o espaço correto antes do recurso carregar, eliminando o salto de layout.

<!-- Errado -->
<img src="banner.jpg" alt="Banner">

<!-- Correto -->
<img src="banner.jpg" alt="Banner" width="1200" height="600">

2. Reserve espaço para conteúdo dinâmico

Anúncios, banners de cookie e widgets de terceiros que aparecem após o carregamento são fontes clássicas de CLS. A solução é reservar o espaço antes: use min-height no container para garantir que o layout não seja empurrado quando o conteúdo aparecer.

3. Evite injetar conteúdo acima de elementos existentes

Se você precisa mostrar um banner ou notificação, prefira animações que aparecem de baixo para cima ou overlays que não deslocam o fluxo da página.

Melhorando o TBT e INP

1. Code splitting e carregamento sob demanda

Enviar um bundle JavaScript gigante faz a thread principal ficar bloqueada enquanto o browser analisa e executa o código. Use importações dinâmicas para dividir o bundle:

// Carrega o componente pesado apenas quando necessário
const GraficoComplexo = dynamic(() => import('./GraficoComplexo'), { ssr: false });

2. Defira scripts de terceiros

Analytics, chat widgets, pixels de marketing — esses scripts são os maiores vilões do TBT. Carregue-os com defer ou async, ou melhor ainda, use uma fachada: exiba um placeholder estático e carregue o script real apenas quando o usuário interagir com ele.

<script src="analytics.js" defer></script>

3. Mova trabalho pesado para Web Workers

Processamento intensivo (parsing de dados, cálculos) não deve rodar na thread principal. Web Workers permitem executar código em paralelo sem bloquear a UI.

Ferramentas Complementares

Melhorar os Core Web Vitals envolve mais do que otimizar assets. Dois fatores de infraestrutura têm impacto direto:

Teste de Suporte a HTTP/2 e HTTP/3

O protocolo HTTP/2 permite multiplexação: múltiplos recursos são transferidos em paralelo pela mesma conexão, reduzindo latência. O HTTP/3 vai além, usando QUIC para menor overhead em conexões instáveis.

Use o Teste de Versão HTTP do FlashMon para verificar se seu servidor suporta HTTP/2 e HTTP/3. Se ainda estiver em HTTP/1.1, a migração pode reduzir o LCP consideravelmente sem nenhuma mudança de código.

Análise de Headers HTTP e Redirecionamentos

Um redirect desnecessário adiciona 100–300 ms ao TTFB antes mesmo de a página começar a carregar. O header Strict-Transport-Security com preload elimina o redirect de HTTP para HTTPS para visitantes recorrentes, pois o browser já sabe usar HTTPS direto.

Verifique seu Status HTTP e cadeia de redirecionamentos para identificar redirecionamentos evitáveis na rota de carregamento principal.

Resumo: O Que Priorizar

Problema	Causa mais comum	Ação prioritária
LCP alto	Imagem principal sem otimização	Converter para WebP + `fetchpriority="high"`
LCP alto	Servidor lento	CDN + cache de resposta
CLS alto	Imagens sem dimensões	Adicionar `width` e `height` a todos os `<img>`
CLS alto	Conteúdo dinâmico	Reservar espaço com `min-height`
TBT alto	Bundle JS gigante	Code splitting com importações dinâmicas
TBT alto	Scripts de terceiros	Adicionar `defer` ou usar fachadas

A sequência recomendada é: meça primeiro com o Teste de Velocidade do FlashMon para identificar o problema real, depois aplique a correção específica. Otimizar às cegas — comprimindo imagens quando o problema real é JavaScript bloqueante — é o erro mais comum e desperdiça tempo sem mover o ponteiro da nota.

Core Web Vitals não são uma caixa para marcar uma vez. Cada novo recurso, script de parceiro ou imagem adicionada pode degradar as métricas. O ideal é integrá-los ao processo de deploy: uma nota PageSpeed abaixo de 70 antes de ir para produção deve ser um sinal de alerta tão sério quanto um teste falhando.

Teste a velocidade do seu site agora — é gratuito

Leia também

Reduza overhead de TLS e redirects — veja headers de segurança HTTP e audite sua cadeia de redirect com o verificador HTTP.
Confirme se seu servidor já usa HTTP/2 ou HTTP/3 com o teste de versão HTTP.