Página lenta não é só um incômodo. Ela derruba engajamento, piora a percepção da marca e pode corroer resultado orgânico sem fazer barulho.
É por isso que Core Web Vitals deixou de ser conversa de nicho entre desenvolvedores. Hoje ele impacta SEO, experiência do usuário e conversão ao mesmo tempo.
O que os Core Web Vitals medem na prática
Os três indicadores principais olham para partes diferentes da experiência da página:
1. LCP (Largest Contentful Paint)
O LCP mede quanto tempo o principal elemento visível demora para aparecer. Na prática, costuma ser a imagem hero, um banner, um vídeo em destaque ou o primeiro grande bloco de texto.
O alvo mais usado é 2,5 segundos ou menos.
2. INP (Interaction to Next Paint)
O INP mede quanto tempo a página leva para dar um retorno visual depois de uma interação real, como clique, toque ou digitação.
O ideal é ficar em 200 ms ou menos.
3. CLS (Cumulative Layout Shift)
O CLS mede o quanto o layout se mexe sem aviso durante o carregamento ou quando novos elementos entram na tela.
O valor considerado bom é 0,1 ou menos.
Como medir sem cair no achismo
Não adianta sair otimizando tudo ao mesmo tempo. Primeiro é preciso entender onde a experiência quebra.
1. Google Search Console e PageSpeed Insights
O relatório de Core Web Vitals no Search Console mostra quais grupos de URL estão com problema com base em dados de usuários reais. O PageSpeed Insights ajuda a analisar uma página específica.
2. Lighthouse no Chrome
Lighthouse continua sendo o jeito mais rápido de levantar hipóteses técnicas. Vale olhar principalmente:
- qual elemento está sendo tratado como LCP
- quais scripts estão ocupando a thread principal
- quais recursos bloqueiam a renderização inicial
- em que momento acontecem os layout shifts
3. Monitoramento de usuários reais (RUM)
Dados de laboratório ajudam bastante, mas não substituem tráfego real. Dispositivos fracos, internet móvel ruim e scripts de terceiros pesam muito mais no mundo real.
Se você quiser priorizar por impacto SEO antes de abrir o código, vale cruzar essas descobertas com uma revisão rápida no SEO Analyzer.
Como melhorar LCP sem desperdiçar esforço
Na maioria dos projetos, o LCP ruim está ligado a alguns culpados bem previsíveis: imagem principal pesada, resposta lenta do servidor e excesso de recursos bloqueando o primeiro paint.
1. Trate a imagem principal como prioridade
- use WebP ou AVIF
- entregue tamanhos diferentes com
srcsetou<picture> - comprima antes de publicar
- não aplique
loading="lazy"na imagem crítica - defina
widtheheight
1<picture> 2 <source 3 srcset="hero-1200.webp 1200w, hero-800.webp 800w, hero-400.webp 400w" 4 type="image/webp" 5 sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" 6 > 7 <source 8 srcset="hero-1200.jpg 1200w, hero-800.jpg 800w, hero-400.jpg 400w" 9 type="image/jpeg" 10 sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" 11 > 12 <img src="hero-800.jpg" alt="Homepage hero image" width="1200" height="800" loading="eager"> 13</picture>
2. Reduza o TTFB
Se o servidor responde devagar, o navegador fica parado esperando.
- ative cache de página e de dados quando fizer sentido
- use CDN para servir assets estáticos
- revise consultas lentas
- tire processamento pesado do caminho crítico
3. Remova bloqueios na renderização
Muito CSS, fonte ou JavaScript na rota crítica faz a página parecer lenta mesmo quando o problema não está no servidor.
- deixe o CSS crítico mais enxuto
- carregue scripts não essenciais com
defer - use
asyncpara scripts independentes - elimine bibliotecas que não precisam entrar no carregamento inicial
1<head> 2 <link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin> 3 <script src="/js/main.js" defer></script> 4 <script src="https://analytics.example.com/script.js" async></script> 5</head>
4. Use preload com critério
preload ajuda bastante para a imagem LCP e para fontes realmente críticas. O exagero costuma virar gargalo.
Como melhorar INP e deixar a página mais responsiva
INP ruim quase sempre significa uma thread principal ocupada demais.
1. Enxugue o JavaScript
- divida bundles grandes
- carregue funcionalidades secundárias sob demanda
- remova código morto
- evite hidratar cedo componentes que não precisam reagir logo de cara
1document.querySelector('.open-chart').addEventListener('click', async () => { 2 const { renderChart } = await import('./chart-module.js'); 3 renderChart(); 4});
2. Controle scripts de terceiros
Chat, analytics, pixel, mapa, teste A/B, player embutido. É comum o problema de INP estar aí.
Perguntas úteis:
- esse script realmente gera valor?
- ele pode carregar só depois da primeira interação?
- ele pode sair do projeto sem fazer falta?
3. Quebre tarefas longas
Quando uma tarefa de JavaScript segura a thread principal por muito tempo, a resposta ao clique atrasa.
- divida processos pesados em partes menores
- use
requestIdleCallbackpara tarefas secundárias - mova cálculos pesados para Web Workers
Como reduzir CLS e parar de ver a interface "pular"
CLS alto costuma vir de vários detalhes negligenciados ao mesmo tempo.
1. Reserve espaço para mídia e embeds
Imagens, vídeos e iframes precisam de espaço definido antes de aparecer.
- informe
widtheheight - use
aspect-ratioem containers responsivos - deixe áreas estáveis para embeds e players
2. Evite inserir elementos de surpresa
Aviso, banner, recomendação carregada por cima do conteúdo: tudo isso mexe na tela na pior hora.
- reserve espaço antes de carregar
- use overlay quando não quiser empurrar o conteúdo
- defina altura mínima para slots de anúncio
3. Cuide do carregamento de fontes
Fonte web também causa salto visual.
- faça preload da fonte principal
- use
font-display: swap - escolha uma fonte fallback com métricas parecidas
Exemplo real de impacto
Um e-commerce com tráfego majoritariamente mobile começou assim:
- LCP: 4,8 s
- INP: 180 ms
- CLS: 0,25
- conversão: 1,2%
- rejeição: 65%
As mudanças implementadas:
- migração das imagens principais para WebP
- reserva de espaço para imagens e anúncios
- atraso na carga de scripts de analytics e mídia
- preload das imagens hero mais importantes
- redução do CSS crítico
- ativação de CDN para assets estáticos
- ajuste de fontes com
font-display: swap
Depois da otimização:
- LCP: 1,9 s
- INP: 65 ms
- CLS: 0,08
- conversão: 2,8%
- rejeição: 42%
Nada de truque. Só foco no que mais atrapalhava o usuário.
A parte contínua do trabalho
Core Web Vitals não é algo que você "resolve" uma vez. Novo script, novo componente e nova campanha podem estragar tudo de novo.
1. Tenha monitoramento recorrente
Acompanhe Search Console, RUM e os principais tipos de página com frequência.
2. Defina orçamentos de performance
Vale estabelecer limites para:
- peso total de JavaScript
- tamanho máximo de imagem
- quantidade de fontes
- número de scripts de terceiros
3. Coloque performance no fluxo de publicação
Landing page nova, redesign ou feature importante deveria passar por uma checagem básica de LCP, INP e CLS antes de ir ao ar.
4. Distribua esse conhecimento no time
Desenvolvimento não é o único responsável. Design, conteúdo e marketing também influenciam esses números.
Resumo prático
- LCP melhora quando você acelera o recurso principal, o servidor e o caminho crítico.
- INP melhora quando sobra menos trabalho para a thread principal.
- CLS cai quando o layout deixa de ser imprevisível.
- Dado de laboratório ajuda, mas dado real manda.
- O objetivo final não é ter nota bonita. É ter uma página que carrega melhor e converte melhor.
Se você precisa descobrir primeiro quais URLs estão perdendo mais por causa de performance, comece pelo SEO Analyzer e aprofunde com Lighthouse e dados reais de campo.
