Como Corrigir Problemas de Core Web Vitals: LCP, INP e CLS Explicados
Experimente o AuditMe ao vivo — Verificação instantânea gratuita
Cole qualquer URL abaixo e receba uma pontuação SEO real em cerca de 60 segundos. Sem cadastro — é o mesmo motor descrito neste artigo.
O Que São os Core Web Vitals? (E Por Que Eles Realmente Importam)
Os Core Web Vitals são o conjunto de métricas do mundo real do Google que medem a experiência do usuário no seu site. Desde 2022, eles são fatores de ranking diretos. Em 2026, eles continuam sendo críticos — tanto para o SEO quanto para impedir que as pessoas abandonem a sua página por frustração.
O que digo a todo cliente: o Google não se importa com o quão bonito é o seu site. Ele se importa com a rapidez com que ele carrega, o quão estável ele parece e a velocidade com que responde quando alguém toca em um botão. Essas três coisas são o que os Core Web Vitals medem.
As três métricas com as quais você precisa se preocupar são:
- LCP (Largest Contentful Paint) — Desempenho de carregamento (a rapidez com que o seu conteúdo principal aparece)
- INP (Interaction to Next Paint) — Interatividade (o quão ágil a sua página parece)
- CLS (Cumulative Layout Shift) — Estabilidade visual (o quanto as coisas pulam de lugar durante o carregamento)
Também existem o FCP e o TTFB, que são métricas de apoio importantes, mas LCP, INP e CLS são os três grandes que o Google realmente usa para ranquear. Passei os últimos dois anos corrigindo essas métricas para clientes e vou mostrar exatamente o que funciona — não teoria, mas as coisas que realmente fizeram a agulha se mover.
Corrigindo o LCP (Meta: Abaixo de 2,5s)
O LCP mede quanto tempo o maior elemento visível leva para ser renderizado. Para a maioria dos sites, esse é o hero image ou um grande bloco de título. O Google quer isso abaixo de 2,5 segundos. Qualquer coisa acima disso e você está perdendo tanto rankings quanto usuários. Para um detalhamento completo do diagnóstico e da correção do LCP especificamente, consulte o nosso guia aprofundado de LCP.
Passei três semanas corrigindo o LCP na loja WooCommerce de um cliente no ano passado. As páginas de produto estavam carregando em 6,8 segundos no mobile. Conseguimos reduzir para 2,1 segundos. Aqui está exatamente como.
1. Otimize as Imagens (É Aqui Que Estão a Maioria das Vitórias)
As imagens são a causa número um de LCP ruim. Ponto final. Nunca vi um site com uma pontuação ruim de LCP que não tivesse um problema de imagem.
- Converta para os formatos WebP ou AVIF. O WebP oferece arquivos 40-80% menores que o JPEG com basicamente a mesma qualidade. O AVIF é ainda melhor, mas o suporte dos navegadores ainda está em desenvolvimento.
- Use imagens responsivas com srcset para que usuários de mobile não estejam baixando hero images de 4000px em uma tela de 375px. Isso é simplesmente desperdício.
- Faça o carregamento preguiçoso (lazy load) das imagens abaixo da dobra. Não carregue aquela imagem do rodapé até que alguém realmente role a página até ela.
- Sirva imagens com tamanho adequado para o viewport. Uma imagem de 1200px de largura é ideal para desktop. Para mobile, 400px é suficiente.
O que eu realmente mudei: Naquela loja WooCommerce, estávamos servindo as mesmas imagens de produto de 2400px para todos os dispositivos. Usamos `html<img srcset="product-400.webp 400w, product-800.webp 800w, product-1200.webp 1200w" sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px" src="product-800.webp" alt="Product name">` e convertemos tudo para WebP. Só isso cortou o LCP em 2,3 segundos.
2. Elimine Recursos Que Bloqueiam a Renderização
O seu <head> provavelmente está carregando CSS e JavaScript que bloqueiam a renderização. Cada recurso que bloqueia a renderização adiciona milissegundos ao seu LCP.
- Adie (defer) o CSS e o JavaScript não críticos. Se não for necessário para o conteúdo acima da dobra, adie.
- Coloque o CSS crítico inline no <head> para os estilos acima da dobra. Isso elimina completamente uma solicitação que bloqueia a renderização.
- Use rel="preload" para o seu hero image e fontes críticas. Diga ao navegador para começar a baixar esses itens imediatamente, em vez de esperar.
O que eu realmente mudei: Encontrei três arquivos CSS carregando no <head> que bloqueavam a renderização. Dois deles eram para um slider que só aparecia na página inicial. Movemos para <link rel="preload" as="style" onload="this.rel='stylesheet'"> e colocamos o CSS crítico acima da dobra inline. O LCP caiu mais 0,8 segundo.
3. Melhore o Tempo de Resposta do Servidor
Se o seu servidor é lento, tudo mais que você fizer será uma luta contra a correnteza.
- Use um CDN (Cloudflare, Vercel Edge, Fastly). Não há desculpa para não usar em 2026.
- Habilite HTTP/2 ou HTTP/3. Múltiplas solicitações podem ser multiplexadas em uma única conexão.
- Otimize as consultas de banco de dados no backend. Pela minha experiência, sites WooCommerce em que uma única página disparava mais de 200 consultas de banco de dados.
- Implemente estratégias de cache. Cache de página, cache de objetos, cache de navegador — use todos.
O que eu realmente mudei: Aquele mesmo cliente WooCommerce estava em uma hospedagem compartilhada de US$ 5/mês. O TTFB deles sozinho era de 1,8 segundo. Movemos para uma hospedagem WooCommerce gerenciada com cache em nível de servidor e CDN do Cloudflare. O TTFB caiu para 180ms. Essa foi a maior melhoria de LCP que fizemos.
4. Otimize as Fontes da Web
Fontes personalizadas são bonitas, mas podem destruir completamente o seu LCP se você não tomar cuidado.
- Use font-display: swap para que o texto fique visível imediatamente usando uma fonte substituta e depois troque para a fonte personalizada quando ela carregar.
- Faça subset das fontes para incluir apenas os caracteres que você precisa. A maioria dos sites não precisa de conjuntos de caracteres cirílicos, gregos e vietnamitas.
- Pré-carregue fontes críticas com <link rel="preload"> para que o navegador as busque cedo.
O que eu realmente mudei: O cliente estava carregando três pesos diferentes de uma família de fontes (400, 600, 700), além de duas famílias de fontes diferentes. Fizemos subset de cada uma apenas para caracteres latinos e removemos o peso leve. O tamanho dos arquivos de fonte passou de 380KB no total para 85KB.
O Resultado Final do LCP
Depois de todas essas mudanças, tiramos o LCP deles de 6,8 segundos para 2,1 segundos no mobile. Isso é uma melhoria de 70%. O tráfego orgânico para as páginas de produto aumentou 34% nos dois meses seguintes. Não é coincidência.
Corrigindo o INP (Meta: Abaixo de 200ms)
O INP (Interaction to Next Paint) substituiu o First Input Delay (FID) em 2024 e, sinceramente, é uma métrica muito mais difícil de acertar. O FID apenas media o atraso antes da primeira interação. O INP mede a rapidez com que a sua página responde a todas as interações ao longo da sessão. Se você tem um handler lento escondido no seu código, o INP o detecta.
O que ninguém te conta sobre o INP: a maioria dos sites falha por causa de JavaScript que eles mesmos não escreveram. Scripts de terceiros, ferramentas de análise, widgets de chat — eles são os assassinos silenciosos do INP.
1. Divida Tarefas Longas
A thread principal do navegador só consegue fazer uma coisa por vez. Se uma tarefa de JavaScript leva mais de 50ms, ela bloqueia tudo — rolagem, cliques, renderização. Os usuários sentem isso como "jank" (travamento).
- Divida a execução do JavaScript em blocos abaixo de 50ms usando requestIdleCallback ou setTimeout.
- Use requestIdleCallback para trabalho não urgente, como analytics, pré-busca ou atualizações de interface não críticas.
- Implemente code splitting e carregamento preguiçoso para que os usuários baixem apenas o que precisam para a página atual.
O que eu realmente mudei: Encontrei uma página de produto que executava uma tarefa de JavaScript de 340ms no carregamento da página — uma calculadora de preços complexa que calculava impostos para 12 regiões diferentes. Ninguém interagia com ela no carregamento. Envolvemos em requestIdleCallback e a adiamos até que o navegador ficasse ocioso. O INP caiu de 420ms para 85ms.
2. Otimize os Event Handlers
Todo clique, toque, rolagem e tecla pressionada aciona um event handler. Se esse handler faz trabalho demais, a sua página parece lenta.
- Faça debounce nos handlers de rolagem e redimensionamento. Executar lógica complexa em cada evento de rolagem quase sempre é desnecessário.
- Evite manipulações complexas de DOM em callbacks de eventos. Agrupe leituras e escritas de DOM.
- Use event listeners passivos quando possível (`htmladdEventListener('scroll', handler, { passive: true })`). Isso permite que o navegador role enquanto o seu handler é executado.
O que eu realmente mudei: Um cliente tinha um cabeçalho fixo que recalculava a sua posição em cada evento de rolagem — sem debounce, sem throttle. Isso é centenas de vezes por segundo. Adicionar um simples debounce com atraso de 16ms corrigiu imediatamente. O INP passou de 380ms para 120ms.
3. Reduza o Trabalho da Thread Principal
Quanto menos JavaScript você forçar o navegador a executar, mais rápido ele consegue responder às interações.
- Minimize o tamanho do bundle de JavaScript. Use tree-shaking, remova exports não utilizados e analise o seu bundle com ferramentas como webpack-bundle-analyzer.
- Remova polyfills e código legado não utilizados. Se você não está dando suporte ao IE11, pare de enviar polyfills para ele.
- Use Web Workers para cálculos pesados, como processamento de dados, manipulação de imagens ou cálculos complexos.
O que eu realmente mudei: Ao verificar uma landing page de SaaS, encontrei 400KB de JavaScript que nunca era executado. Era uma biblioteca legada de testes A/B que havia sido substituída, mas nunca removida. Excluí-la reduziu o bundle em 40% e o INP melhorou de 290ms para 110ms.
O Resultado Final do INP
A maioria dos meus clientes fica entre 80-150ms de INP após a otimização. Abaixo de 200ms é aprovação, mas miro abaixo de 150ms para ter uma margem de segurança. Lembre-se, o INP é medido no 98º percentil — as suas piores interações importam mais do que as médias.
Corrigindo o CLS (Meta: Abaixo de 0,1)
O CLS mede a estabilidade visual — o quanto o layout da sua página se desloca depois que ela começa a carregar. Pense naquele momento em que você está prestes a clicar em um link e um anúncio carrega acima dele, empurrando tudo para baixo. Isso é o CLS, e os usuários absolutamente odeiam.
O maior problema de CLS que já vi foi causado por um site de notícias com 14 unidades de anúncio diferentes carregando de forma assíncrona. A página se deslocava três ou quatro vezes antes de se estabilizar. A pontuação de CLS deles era 0,45. Conseguimos reduzi-la para 0,03.
1. Defina Dimensões Explícitas
Se você não diz ao navegador o quão grande um elemento será, ele tem que adivinhar. E quando o conteúdo real carrega, tudo se desloca.
- Sempre defina largura e altura em imagens e vídeos. Mesmo que você use CSS para torná-los responsivos, o navegador precisa das dimensões intrínsecas para calcular a proporção de aspecto.
- Use a propriedade CSS aspect-ratio para elementos responsivos: `htmlaspect-ratio: 16 / 9;`
- Reserve espaço para anúncios e incorporações. Uso um div de espaço reservado com as dimensões esperadas que o anúncio preenche quando carrega.
O que eu realmente mudei: O blog de um cliente incorporava vídeos do YouTube apenas com o iframe — sem dimensões especificadas. Envolvemos cada iframe em um contêiner com aspect-ratio: 16 / 9; width: 100%; e definimos atributos explícitos de width e height no iframe. O CLS caiu de 0,28 para 0,05.
2. Evite Conteúdo Que Carrega Tarde
Qualquer coisa que aparece após o carregamento inicial da página e empurra o conteúdo contribui para o CLS.
- Não injete conteúdo acima do conteúdo existente após o carregamento. Se precisar, pré-aloque espaço para ele.
- Pré-aloque espaço para elementos dinâmicos como banners, avisos de cookies e widgets de chat.
- Use telas esqueleto com dimensões fixas para que o layout não se desloque quando o conteúdo real carrega.
O que eu realmente mudei: Aquele site de notícias que mencionei tinha um banner de notícias de última hora que aparecia 2-3 segundos após o carregamento da página. Ele empurrava o artigo inteiro 120px para baixo. Demos posição ao banner com um espaço reservado em CSS: `html<div class="banner-slot" style="height: 120px;"></div>` — o espaço sempre estava lá, apenas ficava vazio até o banner carregar.
3. Use o Font Display Swap (Estrategicamente)
Fontes personalizadas podem causar deslocamentos de layout quando carregam — a fonte substituta pode ter um tamanho diferente, fazendo o texto fluir novamente.
- Use font-display: swap para o texto do corpo. O texto aparece imediatamente em uma fonte substituta e depois troca para a fonte personalizada.
- Use font-display: optional para fontes não críticas. Isso elimina completamente o deslocamento de layout — o navegador ou usa a fonte personalizada ou mantém a substituta, sem troca.
- Corresponda às métricas da sua fonte substituta. Use ferramentas como fontaine para encontrar fontes do sistema que se aproximem muito das suas fontes da web.
O que eu realmente mudei: Um cliente tinha três fontes personalizadas causando um CLS de 0,12 apenas pelo reflow de texto. Usamos font-display: optional para a fonte de títulos (ela só era usada em tamanhos grandes, onde a diferença era quase imperceptível) e combinamos as métricas da fonte substituta usando o CSS size-adjust. O CLS do carregamento de fontes caiu para zero.
O Resultado Final do CLS
A maioria dos problemas de CLS vem de anúncios, imagens e conteúdo injetado dinamicamente. Corrija essas três categorias e você normalmente ficará abaixo de 0,1. Fiz todos os clientes com quem trabalhei passarem no CLS — geralmente é a mais fácil das três métricas de corrigir quando você sabe o que procurar.
O Que Eu Realmente Mudei (Resumo)
A realidade é que — acabei de te dar muitos conselhos técnicos. Deixe-me resumir o que realmente faz diferença, em ordem de impacto:
- Imagens — Converta para WebP, defina dimensões explícitas, use srcset, faça lazy load abaixo da dobra. Isso corrige o LCP e o CLS simultaneamente.
- JavaScript — Remova código não utilizado, adie scripts não críticos, divida tarefas longas. Isso corrige o INP.
- Servidor — Use um CDN, habilite o cache, faça upgrade da hospedagem se necessário. Isso corrige o LCP e o FCP.
- Fontes — Faça subset, pré-carregue e use o font-display estrategicamente. Isso corrige o LCP e o CLS.
- Estabilidade do layout — Defina dimensões em tudo, reserve espaço para conteúdo dinâmico. Isso corrige o CLS.
Se você fizer apenas uma coisa, corrija as suas imagens. É a mudança de maior impacto com o menor esforço. Pela minha experiência, a otimização de imagens sozinha melhora o LCP em mais de 2 segundos em sites com muitas imagens.
Ferramentas Para Medir os Core Web Vitals
Você não pode corrigir o que não pode medir. Aqui estão as ferramentas que uso diariamente:
- Google PageSpeed Insights — Dados de laboratório e de campo. Gratuito, confiável e o que o Google realmente usa.
- Chrome User Experience Report (CrUX) — Métricas de usuários reais de usuários reais do Chrome. É o padrão ouro para dados de campo.
- Relatório de Core Web Vitals do Search Console — Mostra problemas em nível de URL em todo o seu site. Ótimo para encontrar páginas que precisam de atenção.
- AuditMe — Análise automatizada de CWV com recomendações específicas de correção. Ele não apenas diz o que está quebrado — ele diz exatamente o que mudar.
- Painel Performance do Chrome DevTools — Para mergulhar fundo em interações específicas e identificar tarefas longas.
Meu conselho? Comece com o PageSpeed Insights para uma visão geral rápida e depois use o Search Console para encontrar os maiores infratores do seu site. Depois de identificar as páginas problemáticas, use o painel Performance do DevTools para apontar exatamente o que está causando o problema. Especificamente para sites WordPress, o nosso guia sobre otimização de Core Web Vitals para WordPress cobre correções plugin por plugin.
Artigos Relacionados
- Checklist de SEO Técnico 2026: Rastrear, Indexar, Renderizar, Ranquear
- Core Web Vitals para WordPress: Guia de Otimização Plugin por Plugin
- Mergulho Profundo em LCP: Diagnosticando e Corrigindo o Core Web Vital Mais Difícil
Teste Seus Core Web Vitals Agora
Pare de adivinhar e comece a medir. Execute uma análise gratuita de Core Web Vitals em qualquer URL. Você receberá uma pontuação de semáforo para todas as cinco métricas, além de etapas específicas de otimização classificadas por impacto. Sem necessidade de cadastro — basta colar a sua URL e ver exatamente onde você está.
Eduard Tymchenko
SEO Expert & Founder of AuditMe
“I built AuditMe after 10+ years of manual SEO audits — every check in this report is one I used to run by hand.”
Specializes in technical SEO, Core Web Vitals, and WordPress optimization.
Execute Sua Auditoria SEO Gratuita
Obtenha uma análise SEO completa de qualquer URL em 60 segundos. Sem cadastro necessário.
Ou abra o analisador completo com mais detalhes
Analise Seu Site GrátisFerramentas SEO Gratuitas
Artigos Relacionados
Continue aprendendo com estes guias e tutoriais relacionados de SEO:
Your Website Was Seen 116,181 Times and Clicked 9 Times. Here's What Search Engines and AI Systems Are Actually Doing.
A first-party 2026 investigation from AuditMe into the Visibility Gap: how crawling, indexing, retrieval, ranking, AI citations, clicks, trust, and conversions form one measurable website intelligence system.
21 min read
How AI Systems Read the Web in 2026: Discovery, Retrieval, Citations and Agents
An evidence-first guide to AI search, GEO, retrieval, entity clarity, citations and agent-ready websites — with a practical framework, implementation patterns and a proposed open benchmark methodology.
45 min read
The New SEO: When Search Engines Stop Reading Websites and Start Using Them
Search is moving from ranking pages to running them as machine interfaces. This guide explains the six-dimension Website Intelligence framework — discoverability, understanding, verification, actionability, reliability, and observability — that makes your site machine-readable, verifiable, and actionable for AI search engines and agents.
23 min read
AI Readiness Guide: llms.txt, AI Bot Access & Semantic HTML for AI Search in 2026
Is your website ready for AI search? Complete guide to llms.txt, AI bot access, semantic HTML, and content architecture for ChatGPT, Claude, Perplexity, and Gemini in 2026.
24 min read