Como Passar no Core Web Vitals: Passo a Passo (2026)

O Caminho Mais Rápido para Passar no Core Web Vitals

Você sabe que o seu Core Web Vitals precisa de melhorias. O Google Search Console está mostrando vermelho ou laranja, um cliente está fazendo perguntas ou o PageSpeed Insights acabou de trazer más notícias. Esta página é o fluxo de trabalho que uso para fazer os sites passarem de reprovados para aprovados o mais rápido possível.

Eu usei esse fluxo de trabalho para ajudar sites a passarem no Core Web Vitals em centenas de milhares de páginas. Funciona no WordPress, Shopify, construções personalizadas e todas as plataformas intermediárias. A ordem na qual você corrige as coisas importa. Corrija a fundação primeiro e depois trabalhe para fora. Caso contrário, você perderá tempo otimizando coisas que um problema mais profundo irá anular.

Onde a Web Está Exatamente Agora

De acordo com o Web Almanac de 2025 (com base em dados do CrUX de julho de 2025), 48% dos sites mobile e 56% dos sites desktop passam em todos os três Core Web Vitals. Isso é uma melhoria em relação aos 44% no mobile em 2024, mas ainda significa que mais da metade da web mobile está reprovando.

Analisando por métrica (porcentagem de origens classificadas como "boas" no mobile):

Fonte: 2025 Web Almanac (HTTP Archive, dados do CrUX de julho de 2025). Os dados de RUM do CoreDash em sites monitorados mostram distribuições semelhantes.

LCP é o gargalo. 77% passam no INP e 81% passam no CLS, mas apenas 62% passam no LCP. É isso que arrasta a taxa geral de aprovação para 48%. É por isso que o fluxo de trabalho abaixo prioriza o TTFB e o LCP primeiro.

Os dados agregados do CoreDash contam a mesma história. Nos sites que implementaram exatamente esse fluxo de trabalho (TTFB → LCP → INP → CLS nessa ordem), o tempo médio de "reprovado" para "aprovado nas três métricas" no CrUX foi de 4 a 6 semanas: 1 a 2 semanas para implementação, mais 2 a 4 semanas para a janela contínua de 28 dias do CrUX refletir as melhorias. Os sites que pularam direto para a otimização de JavaScript sem corrigir o TTFB primeiro levaram de 2 a 3 vezes mais tempo para alcançar a aprovação porque a base estava instável.

Passo 1: Avalie a Sua Situação Atual

Antes de alterar qualquer coisa, descubra exatamente quais métricas estão falhando e em quais páginas. Se você pular isso e adivinhar, perderá tempo corrigindo as coisas erradas.

Verifique o Google Search Console

Acesse a propriedade do seu Search Console e abra o relatório do Core Web Vitals em "Experiência". Isso mostra a você:

• Quantos URLs são classificados como Bons (Good), Precisam de Melhorias (Needs Improvement) ou Pobres (Poor)
• Qual métrica específica está falhando (LCP, INP ou CLS)
• Grupos de URLs que compartilham o mesmo problema (por exemplo, todas as páginas de produtos falhando no INP)

O Search Console usa dados reais de campo de usuários do Chrome durante uma janela contínua de 28 dias. Estes são os dados que o Google usa para o ranqueamento. Se o Search Console mostrar que você está passando, você está passando, independentemente do que o Lighthouse disser.

Execute o PageSpeed Insights nas Páginas Principais

Teste pelo menos um URL de cada tipo de página: sua página inicial, um post de blog, uma página de produto, uma página de categoria/coleção. O PageSpeed Insights fornece tanto dados de campo (se disponíveis) quanto dados de laboratório (lab data) com diagnósticos específicos.

Olhe a seção de dados de campo primeiro (marcada como "Descubra o que seus usuários reais estão experienciando"). Se ela mostrar verde para todas as três métricas, aquela página passou. Se os dados de campo não estiverem disponíveis, a página não tem tráfego suficiente para os dados do CrUX. O Google pode usar dados em nível de origem ou em nível de grupo de URLs em vez disso.

Configure o Monitoramento de Usuários Reais (RUM)

O Search Console e o CrUX possuem uma janela contínua de 28 dias, o que significa que as melhorias levam semanas para aparecer. Para ver o impacto imediato das suas alterações, configure uma solução de Real User Monitoring (RUM) como o CoreDash. O RUM fornece dados de campo em tempo real para cada página, cada dispositivo e cada país, para que você possa verificar se cada correção funcionou antes de passar para a próxima.

Passo 2: Identifique Qual Métrica Corrigir Primeiro

Se várias métricas estiverem falhando, corrija-as nesta ordem:

O TTFB não é um Core Web Vital em si, mas cada milissegundo do TTFB é um milissegundo adicionado diretamente ao seu LCP e FCP. Uma página com um TTFB de 800ms já usou um terço do orçamento de 2,5 segundos do LCP antes mesmo que o navegador comece a renderizar. O limite "bom" do CrUX para o TTFB é de 800ms, mas o mais rápido é sempre melhor porque qualquer melhoria no TTFB é transferida diretamente para as suas métricas de paint. Saiba mais em nosso guia de Time to First Byte.

Passo 3: Corrija a Base (TTFB)

Se o seu Time to First Byte estiver consistentemente acima de 400ms, comece por aqui. Os problemas comuns:

• Hospedagem lenta: atualize para uma hospedagem de qualidade com cache em nível de servidor. Hospedagens gerenciadas para WordPress (Kinsta, SiteGround, Cloudways) ou a infraestrutura integrada do Shopify lidam com isso.
• Sem cache de página: garanta que o seu CMS armazene em cache o HTML totalmente renderizado para que o servidor não o regenere a cada requisição.
• Sem CDN: configure uma CDN (o Cloudflare é gratuito) para servir as páginas a partir de edge locations (pontos de borda) próximos aos visitantes. Consulte o guia de configuração do Cloudflare.
• Redirecionamentos: cada redirecionamento adiciona uma viagem completa de ida e volta (round trip). Elimine cadeias de redirecionamento desnecessárias.
• Backend lento: consultas de banco de dados não otimizadas, excesso de plugins do WordPress ou processamento pesado no lado do servidor. Use ferramentas de monitoramento de consultas para identificar os gargalos.

Meta: obter um TTFB abaixo de 200ms para a maioria dos visitantes. No mínimo, abaixo de 400ms.

Passo 4: Corrija o LCP

Uma vez que o TTFB esteja sólido, corrija o Largest Contentful Paint. O processo:

Identifique o seu Elemento LCP

Execute sua página que está falhando no PageSpeed Insights e encontre o "Elemento do Largest Contentful Paint" (Largest Contentful Paint element) na seção Diagnósticos. Geralmente é uma imagem hero (hero image), imagem destacada (featured image) ou um grande bloco de texto.

Se o LCP For uma Imagem

1. Certifique-se de que o navegador consegue encontrá-la no HTML. O URL da imagem deve estar em uma tag <img src=""> regular, não oculta atrás de um atributo data-src ou carregada via JavaScript. Se o parser de HTML do navegador não puder ver o URL da imagem, ele não poderá começar a carregá-la cedo. De acordo com o Web Almanac de 2025, 7% dos sites ainda escondem a sua imagem LCP desta forma.
2. Adicione fetchpriority="high" à tag <img>. Isso diz ao navegador para priorizar esta imagem em relação a outros recursos que competem por largura de banda. Sem isso, o navegador pode baixar folhas de estilo, scripts e outras imagens primeiro. Em um teste do Google no Google Flights, esta única alteração melhorou o LCP de 2,6s para 1,9s.
3. Remova loading="lazy". O carregamento preguiçoso (lazy loading) atrasa a requisição até que a imagem esteja perto da viewport. Em uma imagem LCP, esse atraso vai direto para a sua pontuação de LCP.
4. Otimize o tamanho do arquivo. Converta para WebP ou AVIF. Sirva as dimensões corretas para a viewport usando srcset e sizes.
5. Se a imagem não estiver no HTML (imagem de fundo em CSS, carregada via JavaScript ou em uma página onde você não pode alterar a tag <img>): adicione um preload. Use <link rel="preload" as="image" href="..." fetchpriority="high"> no <head>. O preload força o navegador a descobrir a imagem antecipadamente mesmo quando ela não está visível no código-fonte HTML. Para imagens que já estão em uma tag <img> normal, o preload geralmente é desnecessário porque o parser já as encontra.

Se o LCP For Texto

1. Elimine o CSS que bloqueia a renderização. Gere e insira (inline) o CSS crítico (critical CSS) para que o navegador possa renderizar o texto sem esperar por folhas de estilo externas.
2. Otimize o carregamento das fontes. Hospede suas próprias fontes (self-host) e faça o preload do arquivo de fonte primário para reduzir o tempo antes do texto renderizar.
3. Minimize o JavaScript que bloqueia a renderização. Adie (defer) o JavaScript não crítico para que ele não bloqueie o parser de HTML.

Passo 5: Corrija o INP

Uma vez que o LCP esteja passando, aborde a Interaction to Next Paint. O INP falha quando o JavaScript bloqueia a thread principal (main thread) durante as interações do usuário.

Encontre o Gargalo

Abra o Chrome DevTools, vá até o painel Performance (Desempenho) e grave você mesmo interagindo com a página. Procure por tarefas longas (long tasks) (tarefas acima de 50ms, exibidas como barras vermelhas). São elas que bloqueiam a resposta do navegador aos seus cliques.

O que geralmente bloqueia a thread principal (main thread):

• Scripts de terceiros (third-party) (analytics, anúncios, widgets de chat, tags de marketing) competindo pelo tempo da thread principal
• Grandes bundles de JavaScript de frameworks, construtores de páginas (page builders) ou plugins em execução durante o carregamento da página
• Handlers de eventos não otimizados que fazem trabalho demais em resposta a um clique ou ao pressionar de uma tecla

A Prioridade da Correção

1. Atrase os scripts de terceiros. Scripts de chat, analytics, redes sociais e marketing devem carregar após a primeira interação do usuário, não durante o carregamento da página.
2. Adie (defer) o JavaScript primário (first-party) não crítico. Use defer ou async nos scripts que não precisam ser executados antes que a página se torne interativa.
3. Divida tarefas longas. Se o seu próprio código tiver funções que levem mais de 50ms, ceda espaço (yielding) para a thread principal para permitir que o navegador processe as entradas do usuário entre os blocos de trabalho. A forma moderna de fazer isso é o scheduler.yield() (suportado no Chrome 129+ e Edge). Para um suporte mais amplo entre navegadores, use o fallback de envolver o trabalho em setTimeout(resolve, 0) dentro de uma Promise:

   async function yieldToMain() {
     if ('scheduler' in window && 'yield' in scheduler) {
       return scheduler.yield();
     }
     return new Promise(resolve => setTimeout(resolve, 0));
   }

4. Remova JavaScript não utilizado. Use a aba Coverage (Cobertura) do Chrome DevTools para identificar o JavaScript que carrega, mas nunca é executado. Remova-o ou carregue-o condicionalmente.

Para a estratégia completa de otimização de INP, veja nosso guia de otimização de INP.

Passo 6: Corrija o CLS

O CLS geralmente é a métrica mais fácil de corrigir. As causas e soluções mais comuns:

Imagens Sem Dimensões

Toda tag <img> precisa dos atributos explícitos de width e height. Sem eles, o navegador não sabe quanto espaço reservar e o conteúdo se desloca (content shifts) quando a imagem é carregada. Essa é a principal causa de CLS globalmente. Veja nosso guia de CLS.

Troca de Web Fonts (Web Font Swapping)

Quando uma web font é carregada e substitui a fonte de fallback, o texto pode fluir novamente e deslocar os elementos ao redor. Correção: hospede suas próprias fontes, use font-display: optional ou utilize a propriedade CSS size-adjust para corresponder as métricas da fonte de fallback com a web font.

Conteúdo Injetado Dinamicamente

Banners de cookies, barras de notificação, espaços de anúncios e popups que empurram o conteúdo para baixo após o carregamento. Correção: reserve espaço para esses elementos com a propriedade CSS min-height ou carregue-os de forma que não afete o layout ao redor (por exemplo, overlays em vez de injeção inline).

Passo 7: Verifique com Dados de Campo (Field Data)

Depois de implementar suas correções, você precisa verificar se elas funcionam no mundo real, e não apenas no Lighthouse.

• Verificação imediata: use o CoreDash ou outra ferramenta de RUM para visualizar os dados de campo em tempo real. As alterações devem ser visíveis em questão de horas.
• Verificação do CrUX: o Chrome User Experience Report usa uma janela contínua de 28 dias. Espere de 2 a 4 semanas antes que as melhorias reflitam totalmente nos dados do CrUX.
• Verificação do Search Console: o relatório do Core Web Vitals no Search Console é atualizado com base no CrUX. Assim que o CrUX mostrar melhora, o Search Console acompanhará a mudança.

Esse atraso é a razão pela qual o RUM é essencial. Sem ele, você não tem visibilidade se as suas alterações realmente funcionaram até semanas depois.

Passo 8: Monitore e Mantenha

A performance regride. Cada novo plugin, atualização de tema ou script de terceiros pode desfazer o seu trabalho. Configure o monitoramento contínuo:

• Verifique o relatório do Core Web Vitals do Search Console semanalmente
• Use o CoreDash para o monitoramento contínuo em tempo real com alertas
• Teste novamente no PageSpeed Insights após cada mudança significativa (novo plugin, atualização de tema, novo script de terceiros)
• Faça uma auditoria de scripts de terceiros trimestralmente. Remova todos os que não são mais necessários.

Para uma referência completa de tudo o que você deve verificar, use o nosso Checklist Definitivo do Core Web Vitals.

Vitórias Rápidas: As Correções com o Maior Impacto

Se você tem tempo apenas para cinco coisas, estas são as correções de maior impacto em todas as plataformas:

Esses intervalos de impacto vêm de dados de Real User Monitoring do CoreDash em vários projetos de otimização. A sua melhoria real depende do seu ponto de partida, da sua hospedagem e do seu perfil de tráfego. Sites que começam com pontuações muito ruins (LCP acima de 5 segundos) frequentemente observam melhorias ainda maiores. Sites que já estão perto do limite podem ver ganhos absolutos menores, mas representam a diferença entre reprovar e passar.

Os dados do Web Almanac de 2025 apoiam essas prioridades. As páginas iniciais passam no Core Web Vitals em 45% no mobile, enquanto as páginas secundárias passam em 56%. A diferença se deve ao fato de que as páginas iniciais tendem a ter mais conteúdo dinâmico, imagens hero (hero images) maiores e mais scripts de terceiros. Se a sua página inicial está falhando, mas as páginas internas estão passando, concentre o seu esforço de otimização de LCP e INP especificamente no template da página inicial.