Como Melhorar os Core Web Vitals em 8 Passos (2026)

Sites lentos perdem ranqueamentos. Também perdem clientes. Uma melhoria de 0,1 segundo na velocidade da página pode aumentar as conversões no varejo em 8,4%. Ainda assim, 40% dos sites ainda não atingem os limites dos Core Web Vitals do Google.

Essa falha custa dinheiro real. O Google descobriu que sites que passam nos três limites dos Core Web Vitals têm 24% menos abandonos de página. Os visitantes saem. Os ranqueamentos caem. Concorrentes com páginas mais rápidas levam o tráfego que deveria ser seu.

Este guia mostra como melhorar os Core Web Vitals em 8 passos. Sem teoria. Sem conselhos vagos. Cada passo inclui a correção exata, a ferramenta para diagnosticar e por que isso importa para seus ranqueamentos.

Publicamos mais de 3.500 posts de blog em mais de 70 setores. Nossa pontuação média de SEO é de 92%. Os padrões de desempenho deste guia são os mesmos que aplicamos a cada site que otimizamos.

Aqui está o que você vai aprender:

• Como auditar suas pontuações atuais de LCP, CLS e INP
• As 3 correções que resolvem 80% dos problemas de LCP
• Como eliminar mudanças de layout sem redesenhar seu site
• Por que o INP substituiu o FID e o que fazer a respeito
• Como o tempo de resposta do servidor mata silenciosamente seus ranqueamentos
• Um processo de validação para confirmar que suas correções realmente funcionam

---

O Que Você Vai Precisar

Tempo necessário: 2 a 4 horas (dependendo da complexidade do site)

Dificuldade: Intermediário

O que você vai precisar:

• Acesso ao Google Search Console
• Google PageSpeed Insights (gratuito)
• Chrome DevTools (integrado ao Chrome)
• Acesso ao painel de hospedagem ou CMS do seu site
• Uma conta de CDN (o plano gratuito da Cloudflare funciona)

---

O Que São Core Web Vitals?

Core Web Vitals são três métricas que o Google usa para medir a experiência do usuário real no seu site. Elas se tornaram um sinal de ranqueamento em 2021. Em 2024, o Google substituiu o First Input Delay (FID) pelo Interaction to Next Paint (INP). As três métricas atuais são:

Métrica	O Que Mede	Bom	Precisa Melhorar	Ruim
LCP (Largest Contentful Paint)	Velocidade de carregamento	Menos de 2,5s	2,5 a 4,0s	Mais de 4,0s
INP (Interaction to Next Paint)	Responsividade	Menos de 200ms	200 a 500ms	Mais de 500ms
CLS (Cumulative Layout Shift)	Estabilidade visual	Menos de 0,1	0,1 a 0,25	Mais de 0,25

Para passar, pelo menos 75% das visitas às suas páginas devem pontuar “bom” nas três métricas. Páginas ranqueadas na posição 1 do Google são 10% mais propensas a passar nos Core Web Vitals do que páginas na posição 9.

43% dos sites falham apenas no limite de INP. Isso significa que quase metade da web te dá uma vantagem competitiva se você corrigir essa única métrica.

---

Passo 1: Audite Suas Pontuações Atuais de Core Web Vitals

Antes de corrigir qualquer coisa, você precisa de uma linha de base. Execute seu site em três ferramentas de diagnóstico. Cada uma revela problemas diferentes.

Especificamente:

• Abra o Google Search Console e clique em “Core Web Vitals” na barra lateral esquerda. Isso mostra dados de campo de visitantes reais agrupados por mobile e desktop.
• Execute sua página inicial e as 5 principais páginas de destino no PageSpeed Insights. Registre as pontuações de LCP, INP e CLS para cada página.
• Abra o Chrome DevTools (F12), vá para a aba Performance e grave um carregamento de página. Procure por tarefas longas (barras vermelhas) e mudanças de layout (marcadores roxos).

O Search Console mostra o panorama geral. O PageSpeed Insights fornece diagnósticos em nível de página. O DevTools revela o código exato que está causando os problemas.

Por que este passo importa: Você não pode corrigir o que não mede. Muitos proprietários de sites tentam adivinhar seus problemas e perdem horas otimizando as coisas erradas. Uma auditoria de 5 minutos diz exatamente por onde começar.

Dica profissional: Concentre-se primeiro nas URLs com mais tráfego. Corrigir os Core Web Vitals nas suas 10 principais páginas entrega mais impacto de ranqueamento do que corrigir 100 páginas de baixo tráfego.

---

Passo 2: Otimize o Largest Contentful Paint (LCP)

O LCP mede a velocidade com que o maior elemento visível carrega. Em 73% das páginas mobile, o elemento LCP é uma imagem. No restante, geralmente é um bloco de texto ou um pôster de vídeo.

A maioria dos problemas de LCP vem de três fontes. Corrija-os nesta ordem.

2A. Torne o Recurso LCP Descobrível

35% das imagens LCP não são descobríveis na resposta HTML inicial. O navegador não pode começar a baixar o que não consegue encontrar.

Especificamente:

• Use tags <img> padrão com atributos src. Nunca carregue imagens de destaque por meio de CSS background-image ou lazy loading JavaScript data-src.
• Adicione fetchpriority="high" à tag da sua imagem LCP. Apenas 15% das páginas elegíveis usam esse atributo.
• Remova loading="lazy" de qualquer imagem acima da dobra. O lazy loading da imagem LCP a atrasa em centenas de milissegundos.

2B. Comprima e Sirva Formatos Modernos

Arquivos de imagem grandes são o maior vilão do LCP. Uma imagem de destaque de 2 MB em uma conexão 3G leva mais de 5 segundos para carregar.

• Converta imagens para formato WebP ou AVIF. O WebP entrega arquivos 25 a 30% menores do que o JPEG na mesma qualidade.
• Use atributos srcset responsivos para servir imagens menores em dispositivos mobile.
• Defina dimensões máximas. Imagens de destaque raramente precisam exceder 1.200 pixels de largura.

Para uma análise mais aprofundada sobre otimização de imagens, veja nosso guia de otimização de imagens para blogs.

2C. Elimine Recursos que Bloqueiam a Renderização

Arquivos CSS e JavaScript no <head> bloqueiam a renderização até que terminem de ser baixados.

• Insira CSS crítico (os estilos necessários para o conteúdo acima da dobra) diretamente no HTML.
• Adicione atributos async ou defer a arquivos JavaScript não essenciais.
• Mova scripts de terceiros (analytics, widgets de chat, tags de anúncio) para abaixo da dobra ou carregue-os depois que a página renderizar.

Por que este passo importa: O LCP é a métrica mais diretamente ligada à velocidade percebida. Os usuários formam uma opinião sobre seu site em até 2,5 segundos. Se o conteúdo principal ainda não carregou, eles saem.

---

Pare de escrever. Comece a ranquear. A Stacc publica 30 artigos de SEO por mês por $99. Comece por $1 →

---

Passo 3: Corrija o Cumulative Layout Shift (CLS)

O CLS mede o quanto o conteúdo da sua página se move durante o carregamento. Imagens sem dimensões, anúncios que carregam tarde e injeção de conteúdo dinâmico são os suspeitos habituais.

66% das páginas têm pelo menos uma imagem sem dimensões. Esse único problema causa mais mudanças de layout do que qualquer outro fator.

3A. Defina Dimensões Explícitas em Toda Mídia

Toda tag <img> e <video> precisa de atributos width e height. Sem eles, o navegador reserva zero espaço. Quando a imagem carrega, tudo abaixo dela se desloca para baixo.

<!-- Ruim: sem dimensões -->
<img src="hero.webp" alt="Imagem de destaque">

<!-- Bom: dimensões definidas -->
<img src="hero.webp" alt="Imagem de destaque" width="1200" height="630">

Para layouts responsivos, use a propriedade CSS aspect-ratio em vez de valores fixos em pixels. Isso reserva o espaço correto em qualquer tamanho de tela.

3B. Reserve Espaço para Conteúdo Dinâmico

Anúncios, vídeos incorporados e banners de cookies todos carregam depois da renderização inicial da página. Se você não reservar espaço para eles, eles empurram o conteúdo para baixo.

• Defina valores min-height em containers de anúncios com base no tamanho de anúncio mais comum para aquele espaço.
• Use containers de placeholder com proporções fixas para vídeos do YouTube incorporados e iframes.
• Carregue banners de cookies como sobreposições (posicionados como fixed ou absolute) em vez de injetá-los no fluxo do documento.

3C. Pare de Animar Propriedades de Layout

Páginas que animam propriedades CSS como margin, padding, top ou left são 15% menos propensas a alcançar boas pontuações de CLS. Essas propriedades disparam recálculos completos de layout.

Use transform em vez disso. Transladar, escalar e rotacionar com transform roda na thread do compositor da GPU. Não dispara recálculos de layout.

/* Ruim: dispara mudança de layout */
.slide-in { left: 0; transition: left 0.3s; }

/* Bom: sem mudança de layout */
.slide-in { transform: translateX(0); transition: transform 0.3s; }

Por que este passo importa: Mudanças de layout frustram os usuários. Um botão que se move bem na hora em que você toca nele erode a confiança. O Google quantifica essa frustração com o CLS. Corrigir isso melhora tanto os ranqueamentos quanto a experiência do usuário.

---

Passo 4: Melhore o Interaction to Next Paint (INP)

O INP substituiu o FID em março de 2024. Enquanto o FID apenas media o atraso antes da primeira interação, o INP mede a responsividade de cada interação ao longo do ciclo de vida da página. 43% dos sites falham nesta métrica.

4A. Divida Tarefas Longas

Qualquer tarefa JavaScript que exceda 50 milissegundos se torna uma “tarefa longa” que bloqueia interações do usuário. O navegador não pode responder a cliques, toques ou pressionamentos de tecla enquanto uma tarefa longa está em execução.

Especificamente:

• Abra o Chrome DevTools, vá para a aba Performance e clique em “Record”. Interaja com sua página, depois pare a gravação. Tarefas marcadas com bandeira vermelha são seus alvos.
• Divida funções grandes em pedaços menores usando setTimeout ou a API scheduler.yield().
• Mova computações pesadas para Web Workers, que rodam em uma thread separada.

4B. Reduza o Payload JavaScript

Cada quilobyte de JavaScript deve ser baixado, analisado e compilado antes de poder ser executado. Pacotes oversized são a causa raiz da maioria das falhas de INP.

• Use a ferramenta Coverage do Chrome DevTools (Ctrl+Shift+P, digite “coverage”) para encontrar JavaScript não utilizado. Muitos sites enviam 40 a 60% mais JavaScript do que precisam.
• Implemente code splitting. Carregue apenas o JavaScript necessário para a página atual.
• Audite seu tag manager. Tags de marketing e analytics frequentemente adicionam 200 a 500 KB de JavaScript que roda em cada página.

4C. Minimize o Tamanho do DOM

Árvores DOM grandes (mais de 1.500 nós) tornam cada interação mais lenta. Cada clique ou pressionamento de tecla dispara recálculos de estilo em todo o DOM.

• Use CSS content-visibility: auto para renderizar preguiçosamente o conteúdo fora da tela.
• Remova elementos ocultos do DOM inteiramente em vez de escondê-los com display: none.
• Paginate ou virtualize listas longas em vez de renderizar milhares de itens de uma vez.

Por que este passo importa: O INP é o Core Web Vital mais novo e aquele que a maioria dos sites falha. Corrigir isso te dá uma vantagem imediata de ranqueamento sobre os 43% dos sites que ainda não se adaptaram.

---

Passo 5: Otimize o Tempo de Resposta do Servidor

O Time to First Byte (TTFB) não é um Core Web Vital em si. Mas impacta diretamente o LCP. Um servidor lento adiciona atraso antes mesmo do navegador começar a renderizar sua página.

5A. Meça Seu TTFB

Execute seu site no PageSpeed Insights e procure pela recomendação “Server Response Time” ou “Reduce initial server response time”. Um TTFB bom é menor que 800 milissegundos. Menor que 200 milissegundos é excelente.

5B. Implemente Correções do Lado do Servidor

• Habilite caching do lado do servidor. Armazene em cache páginas HTML renderizadas para que o servidor não precise reconstruí-las para cada requisição. Usuários de WordPress devem instalar um plugin de caching como WP Super Cache ou W3 Total Cache.
• Faça upgrade da sua hospedagem. Planos de hospedagem compartilhada frequentemente têm TTFB acima de 1 segundo. Um plano de VPS gerenciado ou hospedagem em nuvem tipicamente entrega respostas abaixo de 200ms.
• Reduza consultas ao banco de dados. Consultas lentas ao banco de dados são um gargalo comum de TTFB. Use cache de consultas e otimize os índices do seu banco de dados.

5C. Use uma CDN

Apenas 33% dos documentos HTML são servidos por CDNs. Uma CDN armazena seu conteúdo em cache em servidores ao redor do mundo. Os visitantes carregam seu site do servidor mais próximo em vez de esperar por uma ida e volta ao seu servidor de origem.

A Cloudflare oferece um plano gratuito que cobre CDN, DNS e caching básico. Para a maioria dos sites, o plano gratuito é suficiente.

Por que este passo importa: Cada 100 milissegundos de atraso do servidor somam diretamente à sua pontuação de LCP. Um servidor rápido é a base sobre a qual toda otimização é construída.

Se você quiser ver como o desempenho do servidor se encaixa no panorama maior de SEO técnico, execute uma auditoria SEO completa no seu site.

---

Seu time de SEO. $99 por mês. 30 artigos otimizados, publicados automaticamente. Comece por $1 →

---

Passo 6: Otimize Imagens e Mídia

Imagens causam a maioria dos problemas tanto de LCP quanto de CLS. Uma rodada dedicada de otimização de imagens corrige dois Core Web Vitals de uma vez.

6A. Implemente Formatos Modernos de Imagem

Formato	Melhor Para	Economia vs JPEG
WebP	Fotos, ilustrações	25 a 30% menor
AVIF	Fotos, gradientes	40 a 50% menor
SVG	Ícones, logotipos, ilustrações	Independente de resolução

Use o elemento <picture> com fallbacks:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Descrição" width="1200" height="630">
</picture>

6B. Faça Lazy Loading de Imagens Abaixo da Dobra

Adicione loading="lazy" a cada imagem exceto o elemento LCP. Isso adia o download de imagens até que o usuário role perto delas. Reduz o peso inicial da página em 30 a 50% em páginas com muitas imagens.

6C. Sirva Imagens Responsivas

Uma imagem de 2.400 pixels de largura em uma tela de telefone de 375 pixels de largura desperdiça 80% dos dados baixados. Use srcset e sizes para servir imagens de tamanho apropriado:

<img
  src="image-800.webp"
  srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px"
  alt="Descrição"
  width="1200"
  height="630"
>

Para um passo a passo completo sobre otimização de imagens para SEO, leia nosso guia de otimização de imagens para blogs.

Por que este passo importa: Imagens representam em média 50% do peso total de uma página. Otimizá-las é a mudança de maior impacto que você pode fazer tanto para o LCP quanto para a velocidade da página geral.

---

Passo 7: Habilite Cache do Navegador e Dicas de Recursos

Visitantes recorrentes nunca devem baixar novamente recursos que já possuem. O cache do navegador e dicas de recursos eliminam requisições de rede redundantes.

7A. Configure Headers de Cache

Configure seu servidor para enviar headers de cache adequados para ativos estáticos:

Cache-Control: public, max-age=31536000, immutable

Isso diz aos navegadores para armazenar em cache CSS, JavaScript, imagens e fontes por um ano. Use hash de arquivo (ex.: styles.a1b2c3.css) para invalidar o cache quando os arquivos mudarem.

7B. Preconecte a Origens de Terceiros

Se sua página carrega recursos de domínios externos (Google Fonts, analytics, servidores de anúncio), adicione dicas preconnect no seu <head>:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

O preconnect elimina a busca DNS, o handshake TCP e a negociação TLS para esses domínios. Isso economiza 100 a 300 milissegundos por origem.

7C. Use o Cache de Voltar/Avançar

O cache de voltar/avançar (bfcache) armazena um snapshot completo da sua página na memória. Quando os usuários clicam no botão voltar, a página restaura instantaneamente com zero mudanças de layout e zero atraso de LCP.

O lançamento do bfcache do Google em 2022 produziu a maior melhoria anual em pontuações de CLS em toda a web. Para se qualificar:

• Não use Cache-Control: no-store em páginas HTML
• Remova listeners de evento unload do seu JavaScript
• Feche conexões abertas de IndexedDB antes da página ser ocultada

Por que este passo importa: Melhorias de cache se acumulam. Um visitante recorrente com recursos em cache experimenta carregamentos de página quase instantâneos. O Google mede dados de usuários reais. Visitas repetidas mais rápidas melhoram suas pontuações de campo em todas as três métricas.

---

Passo 8: Valide e Monitore Suas Melhorias

Correções não significam nada até que o Google as confirme. Os Core Web Vitals usam dados de campo de usuários reais, não pontuações de laboratório. A validação leva tempo.

8A. Verifique no PageSpeed Insights

Execute cada página corrigida no PageSpeed Insights novamente. Compare os dados de campo “Origin Summary” (topo do relatório) com sua linha de base do Passo 1. Se os dados de campo ainda mostrarem as pontuações antigas, espere. Os dados de campo atualizam em uma média móvel de 28 dias.

8B. Valide no Search Console

Vá para o relatório de Core Web Vitals no Google Search Console. Clique em “Validate Fix” ao lado de qualquer grupo de problemas que você abordou. O Google re-rastreia as URLs afetadas ao longo das próximas 2 semanas e confirma se a correção funcionou.

8C. Configure Monitoramento Contínuo

Core Web Vitals não são uma correção única. Novos deployments de código, atualizações de plugin e mudanças de conteúdo podem introduzir regressões.

• Verifique o relatório de Core Web Vitals no Search Console mensalmente.
• Use DebugBear ou SpeedCurve para monitoramento automatizado de desempenho com alertas.
• Adicione Lighthouse CI ao seu pipeline de deployment para pegar regressões antes que cheguem à produção.

Por que este passo importa: Dados de campo levam 28 dias para atualizar completamente. Se você pular a validação, pode assumir que uma correção funcionou quando na verdade não funcionou. O monitoramento contínuo pega regressões antes que impactem os ranqueamentos.

---

Mais de 3.500 blogs publicados. 92% de pontuação média de SEO. Veja o que a Stacc pode fazer pelo seu site. Comece por $1 →

---

Resultados: O Que Esperar

Após completar esses 8 passos, aqui está um cronograma realista:

• Em até 1 hora: Pontuações de laboratório (PageSpeed Insights) mostram melhoria imediatamente após o deployment
• Em 7 a 14 dias: O Search Console começa a atualizar dados de campo para páginas de alto tráfego
• Em até 28 dias: A média móvel completa de 28 dias reflete suas mudanças nos dados de campo
• Em 60 a 90 dias: Melhorias de ranqueamento se tornam visíveis se os Core Web Vitals eram um fator limitante

O Economic Times reduziu taxas de rejeição em 43% após otimizar LCP e CLS. A Rakuten 24 viu um aumento de 53% na receita por visitante após corrigir seus Core Web Vitals. Seus resultados variarão com base em quão abaixo dos limites você começa e quão competitivo é seu nicho.

Core Web Vitals sozinhos não vão levar uma página de conteúdo raso da posição 50 para a posição 1. Mas em SERPs competitivas onde a qualidade do conteúdo é similar, passar nas três métricas é o critério de desempate.

---

Solução de Problemas

Problema: A pontuação de laboratório do PageSpeed Insights está verde, mas os dados de campo ainda mostram vermelho. Solução: Dados de laboratório e de campo medem coisas diferentes. Dados de laboratório testam um ambiente simulado. Dados de campo refletem experiências reais de usuários em muitos dispositivos e conexões. Espere 28 dias para a média móvel atualizar. Se os dados de campo permanecerem vermelhos, seus usuários reais têm dispositivos ou conexões mais lentos do que a simulação de laboratório assume.

Problema: A pontuação de CLS flutua entre boa e ruim na mesma página. Solução: O CLS pode variar por visita. Anúncios que carregam tarde, scripts de teste A/B ou banners de consentimento de cookies causam mudanças intermitentes. Use a extensão Web Vitals para Chrome para observar o CLS em tempo real e identificar qual elemento se move.

Problema: O INP está ruim, mas não há tarefas longas óbvias no DevTools. Solução: O INP mede todas as interações, não apenas a primeira. Profile interações específicas (alternância de acordeões, envios de formulário, menus dropdown) em vez de apenas o carregamento inicial da página. A interação mais lenta ao longo de toda a visita determina sua pontuação de INP.

---

FAQ

Quais são boas pontuações de Core Web Vitals?

Boas pontuações são LCP abaixo de 2,5 segundos, INP abaixo de 200 milissegundos e CLS abaixo de 0,1. Pelo menos 75% das visitas às suas páginas devem atingir esses limites para que o Google considere a página como aprovada.

Os Core Web Vitals afetam os ranqueamentos de SEO?

Sim. Os Core Web Vitals são um fator de ranqueamento confirmado pelo Google. Páginas na posição 1 são 10% mais propensas a passar nos Core Web Vitals do que páginas na posição 9. O impacto é mais forte em SERPs competitivas onde a qualidade do conteúdo é similar entre as páginas ranqueadas.

O que substituiu o FID nos Core Web Vitals?

O Google substituiu o First Input Delay (FID) pelo Interaction to Next Paint (INP) em março de 2024. O FID apenas media o atraso antes da primeira interação. O INP mede a responsividade de cada interação ao longo de toda a sessão da página. Isso torna o INP uma métrica muito mais rigorosa e precisa.

Quanto tempo leva para as melhorias nos Core Web Vitals afetarem os ranqueamentos?

Os dados de campo no Search Console atualizam em uma média móvel de 28 dias. A maioria dos sites vê melhorias nos dados de campo em 2 a 4 semanas após implantar as correções. Mudanças de ranqueamento, se os Core Web Vitals eram um fator limitante, tipicamente aparecem em 60 a 90 dias. Para mais informações sobre o cronograma completo de ranqueamento, leia nosso guia sobre como ranquear no Google.

Posso melhorar os Core Web Vitals sem programar?

Parcialmente. Usuários de CMS podem instalar plugins de caching, habilitar CDNs e comprimir imagens sem escrever código. Plugins de WordPress como WP Rocket e Autoptimize lidam com muitas otimizações automaticamente. Mas corrigir problemas de INP e CLS avançados geralmente requer mudanças em JavaScript. A maioria dos provedores de hospedagem e serviços de CDN também oferece recursos de performance com um clique que ajudam com LCP e TTFB.

---

Os Core Web Vitals separam sites rápidos de sites lentos. O Google quantifica a diferença. Agora você tem os 8 passos para ficar do lado certo dessa linha.

Comece com o Passo 1. Audite suas pontuações. Depois trabalhe em cada passo em ordem. Os sites que passam nas três métricas hoje têm uma vantagem mensurável sobre os 40% que não passam.

Ranqueie em todo lugar. Não faça nada. Blog SEO, SEO Local e Social no piloto automático. Comece por $1 →