Como melhorar os Core Web Vitals: guia baseado em dados de campo para sites de marketing

A resposta curta

Melhorar os Core Web Vitals começa pelos dados de campo do Google, não pela nota do Lighthouse. Descubra qual métrica falha, se no celular ou no desktop, e em qual template de página, no relatório de Core Web Vitals do Search Console. Depois corrija a causa por trás dessa métrica: no Largest Contentful Paint (LCP), costuma ser a demora do navegador em descobrir a imagem ou o texto principal; no Interaction to Next Paint (INP), um script que mantém a thread principal ocupada quando alguém toca na tela; e no Cumulative Layout Shift (CLS), conteúdo que chega sem espaço reservado. Corrija o template, anote a data da publicação e avalie o resultado cerca de 28 dias depois, quando a janela móvel do Google só contém visitas ao código novo.

Se os seus visitantes estão no Brasil, comece por Core Web Vitals no Brasil e na América Latina: em setembro de 2026, só 33,7% dos sites foram aprovados no celular.

É o roteiro que seguimos no nosso próprio site e nas auditorias de clientes. Se preferir delegar, é o que faz o nosso serviço de otimização de velocidade de sites; essa página também explica custo e ranqueamento.

No celular, o LCP é a métrica que mais sites reprovam. O Web Almanac 2025 do HTTP Archive, construído com dados de campo do Chrome, encontrou LCP bom em 62% dos sites móveis, contra 77% no INP e 81% no CLS; 48% passaram nas três.

Passo 1: encontre a métrica que falha e o template

Uma página passa quando 75% das visitas têm LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1, medidos separadamente no celular e no desktop. Abra o relatório de Core Web Vitals do Search Console e comece pelo celular. Ele agrupa páginas parecidas e dá a cada grupo o status da sua pior métrica, então um grupo com LCP bom e CLS ruim é classificado como ruim (Ajuda do Search Console). Cada URL de exemplo representa um grupo cujas páginas são listadas por impressões, o que mostra qual template corrigir primeiro.

Para ver como os sites da sua plataforma se saem em média no país dos seus visitantes, nosso relatório de velocidade de plataformas web ordena 31 plataformas pelas Core Web Vitals de usuários reais, com dados mensais do HTTP Archive.

Depois, refine:

• PageSpeed Insights mostra os últimos 28 dias de uma URL, atualizados diariamente, e recorre à origem inteira quando a página tem poucas visitas. Confira qual dos dois você está lendo.
• CrUX Vis, em cruxvis.withgoogle.com, mostra os mesmos dados semana a semana nas últimas 40 semanas (Chrome for Developers). Uma métrica que piorou em uma semana costuma apontar para uma publicação, uma tag nova ou uma campanha.
• A API do CrUX também informa o tipo de recurso do LCP e, nos LCPs de imagem, cada subparte do LCP no percentil 75, para você ver onde o tempo se perde antes de abrir o DevTools.

Quando não há nenhum dado de campo, o site costuma estar abaixo do limite de popularidade do Chrome. É o nosso caso: em 14 de outubro de 2026, o PageSpeed Insights não tinha dados de campo de dardo.studio, nem da página nem da origem. Por isso medimos nossas visitas com a biblioteca de código aberto web-vitals do Google, sem cookies, agrupadas por tipo de página e tamanho de tela. Duas regras que aprendemos usando-a: uma visita sem toque nem tecla não tem INP, então nunca a registre como zero, e nossos grupos de tela pequena e grande não são o mobile e o desktop do Google, por isso não os comparamos um a um com o CrUX. Montar essa medição faz parte do nosso trabalho de configuração de analytics.

Passo 2: reproduza no laboratório e leia a causa

Ferramentas de laboratório encontram causas; os dados de campo dizem se você passa. Grave um trace no painel Performance do Chrome DevTools com a limitação de CPU calibrada para um celular de nível intermediário, disponível desde o Chrome 134. A limitação desacelera o processador, não o chip gráfico, então efeitos pesados para a GPU só mostram o custo real em um celular físico (Chrome for Developers).

Nossa home mostra por que a nota é só um ponto de partida. Nessa execução do PageSpeed Insights, o Moto G Power emulado pelo Lighthouse em 4G lenta deu LCP de 6,0 segundos, enquanto a nossa própria medição, com uma amostra pequena, deu à home um LCP de 1,1 segundo no percentil 75 em telas pequenas nos sete dias até 3 de outubro. O útil foi o diagnóstico: o elemento LCP é o título h1, não a cena 3D, e o detalhamento mostrou 10 milissegundos de resposta do servidor seguidos de 1.460 milissegundos de atraso na renderização do elemento. Isso aponta para fontes e trabalho que bloqueia a renderização, não para imagens.

Corrija o LCP pela subparte que está longa demais

Todo LCP se divide em quatro partes consecutivas: tempo até o primeiro byte, atraso de carregamento do recurso até o navegador solicitá-lo, duração do carregamento do recurso e atraso na renderização do elemento (web.dev). Corrija a parte que está fora de proporção.

As proporções são a referência da web.dev para uma página bem otimizada, não metas em segundos.

Comece pelos atrasos. Na análise do Google sobre dados de campo do Chrome, o site mediano com LCP ruim esperava 1.290 milissegundos entre o primeiro byte e a requisição da imagem do LCP, e depois levava 350 milissegundos para baixá-la; a maioria dos sites com LCP ruim gasta menos de 10% dele no download (web.dev). Comprima a imagem principal mesmo assim; sozinha, ela raramente conserta um LCP que falha. O Almanac ainda encontrou cerca de 16% das páginas com lazy loading na imagem do LCP.

Dois detalhes que pegam sites de marketing:

• Imagens principais em tela cheia não contam. O LCP trata elementos que cobrem toda a viewport como plano de fundo e os ignora, então o LCP costuma ser o título; o texto foi o elemento LCP em 23,7% das páginas móveis. O texto não é considerado pintado enquanto sua fonte web está no período de bloqueio, então o carregamento de fontes vira trabalho de LCP.
• A prioridade é relativa. Definir fetchpriority="high" em mais de uma ou duas imagens anula o benefício, e cada preload compete com o que é pintado primeiro. A seção de 3D abaixo mostra esse equilíbrio na nossa home.

Corrija o INP nomeando primeiro o script

O INP é o clique, toque ou tecla mais lento de uma visita, ignorando um a cada 50 interações; passar o mouse e rolar a página não contam (web.dev). Cada interação tem três partes: atraso de entrada enquanto outro trabalho termina, processamento nos seus manipuladores de evento e atraso de apresentação até o próximo quadro ser pintado.

Encontre a interação e o script antes de mudar qualquer coisa. A versão com atribuição do web-vitals informa o elemento tocado, as três partes, se a página ainda estava carregando e os long animation frames que se sobrepuseram a ela. Desde o Chrome 123, esses quadros citam pela URL cada script que rodou por mais de 5 milissegundos, e é assim que você separa o seu código do de um fornecedor (Chrome for Developers). Scripts dentro de iframes de outra origem não são nomeados.

Em sites de marketing, a interação lenta costuma ser uma destas:

• O botão Aceitar do banner de consentimento. Aceitar muitas vezes dispara todas as tags de marketing de uma vez. A equipe do Chrome trabalhou com plataformas de consentimento para que cedam a vez logo após o clique, de modo que o navegador o reconheça no quadro seguinte (web.dev); se a sua não faz isso, peça ao fornecedor.
• Tags que disparam durante o carregamento. Um toque que cai enquanto as tags rodam espera por elas. No Google Tag Manager, as tags de imagem custam menos e as de HTML personalizado mais, e as tags não essenciais devem disparar depois de Window Loaded (web.dev).
• Menus, acordeões e filtros que alteram estilos e depois leem o layout no mesmo manipulador, o que obriga o navegador a calcular o layout na hora.

Para corrigir suas próprias tarefas longas, divida-as e ceda a thread principal logo após a atualização visual. O scheduler.yield() faz isso com prioridade no Chrome e no Edge 129 ou superior e no Firefox 142 ou superior; o Safari não o suporta em outubro de 2026, então use setTimeout como alternativa (web.dev). Confira também as páginas internas: no Almanac, 80% das home pages móveis tinham INP bom, mas só 69% das demais, onde se acumulam filtros, carrosséis e widgets.

Corrija o CLS reservando espaço, inclusive depois do carregamento

O Lighthouse mede um único carregamento de página. O CrUX conta os deslocamentos da visita inteira, agrupados em rajadas de até cinco segundos, e informa a pior rajada (web.dev). Por isso uma página pode parecer estável no laboratório e falhar no Search Console. Deslocamentos até 500 milissegundos depois de um clique, toque ou tecla são excluídos, mas os causados por passar o mouse não são, nem o conteúdo que carrega sob demanda enquanto alguém rola a página.

As correções:

• Dê a toda imagem e vídeo atributos width e height, ou um aspect-ratio em CSS. Em 2025, 62% das páginas móveis tinham pelo menos uma imagem sem dimensões.
• Reserve um espaço com min-height ou aspect-ratio para embeds, formulários e outros conteúdos tardios, e mantenha o espaço mesmo que nada carregue nele.
• Mostre banners de cookies e de promoções como sobreposições, em vez de empurrar a página para baixo.
• Combine a fonte de reserva com a fonte web usando size-adjust e as substituições de ascent e descent, ou use font-display: optional.
• Anime com transform, não com top, left, width nem height.

Depois, deixe a navegação para trás e para frente sem custo. Uma em cada cinco navegações no celular é para trás ou para frente, e uma página restaurada do cache de avançar e voltar (bfcache) retorna exatamente como foi deixada, sem se deslocar de novo (web.dev). Remova os manipuladores unload, adicione Permissions-Policy: unload=() para que terceiros não possam incluí-los, evite Cache-Control: no-store em páginas públicas e teste no DevTools, em Application, Back/forward cache.

Transições de página mudam o que é medido

Se o seu site troca de página com JavaScript, como aplicações de página única, o roteador de cliente do Astro, os links do Next.js e bibliotecas de transição, o Chrome sempre tratou a visita inteira como um único carregamento: toda interação e todo deslocamento de layout depois da primeira página contam contra a URL em que o visitante entrou. O Chrome 151 introduziu as APIs de soft navigation, que medem cada rota separadamente. Em outubro de 2026, o Chrome publica métricas experimentais de soft navigation no CrUX e pretende torná-las padrão em maio de 2027, mas a maioria das ferramentas ainda não as mostra (web.dev).

Isso afeta os nossos próprios números: em uma amostra de 24 horas em 3 de outubro, 29 das 45 visualizações de dardo.studio foram soft navigations. Até que suas ferramentas informem as rotas separadamente, teste INP e CLS nas páginas que as pessoas acessam depois de entrar, não só na página de entrada.

Páginas com 3D e muito movimento precisam das próprias marcas

Nosso guia de sites 3D trata de orçamentos de modelos e texturas. Quatro lições de medir a cena 3D em tempo real da nossa home:

• O LCP não mede a cena. Nosso LCP é o título, então o LCP pode estar bom enquanto a cena ainda está escura. Adicione uma marca de User Timing quando o primeiro quadro 3D aparecer e informe-a junto com seus vitals.
• Procure cascatas de importação. Nossa abertura carregava os módulos um após o outro, cada um descobrindo o seguinte. Pedi-los juntos reduziu o intervalo escuro antes da cena de uma mediana de 1.214 para 697 milissegundos, em cinco execuções a frio intercaladas de cada build local de produção com 150 ms de latência, 9 Mbps e uma CPU quatro vezes mais lenta.
• Teste os preloads nos dois sentidos. Dicas modulepreload de baixa prioridade para os mesmos módulos deixaram a cena pronta cerca de 60 milissegundos antes, mas atrasaram a primeira pintura em cerca de 120, então as retiramos.
• Observe a primeira interação com uma seção. Com a CPU quatro vezes mais lenta, o primeiro hover sobre a nossa seção de serviços gerou uma tarefa de 92 milissegundos, um custo de preparação que os hovers seguintes não pagaram. Passar o mouse não conta para o INP, mas um toque que caia durante essa tarefa espera por ela.

Construir cenas assim é o nosso serviço de sites 3D interativos.

Verifique nos dados de campo cerca de 28 dias depois

Testes de laboratório confirmam uma correção no dia em que ela vai ao ar; os dados de campo do Google, uma janela móvel de 28 dias, levam semanas.

1. Publique uma correção por versão sempre que puder e anote a data. Duas correções na mesma versão não se distinguem depois.
2. Leia primeiro a sua própria medição. Compare as visitas depois da versão com as de antes; um relatório móvel de 28 dias mistura a versão antiga com a nova.
3. Leia o CrUX toda semana, não todo dia. A CrUX History API é atualizada às segundas com dados até o sábado anterior, e cada ponto semanal compartilha três semanas de visitas com o anterior. O primeiro ponto construído só com visitas posteriores à versão chega cerca de quatro semanas depois da publicação.
4. Inicie a validação no Search Console quando todas as URLs do grupo estiverem corrigidas. Ele monitora por 28 dias e falha se alguma URL ainda mostrar o problema.
5. Confira as margens. Um grupo perto de um limite pode virar com uma oscilação de tráfego ou um host de imagens mais lento, sem nenhuma mudança de código, como observa a ajuda do Search Console.

Mantenha os ganhos revisando os Core Web Vitals todo mês diante de tags, imagens e embeds novos; nossos planos de manutenção de sites incluem esse relatório mensal. Se o objetivo por trás do trabalho é o ranqueamento, combine-o com SEO técnico, já que os Core Web Vitals são um sinal entre muitos. E se quiser uma segunda opinião, envie a URL e o template que falha: diremos por qual métrica e por qual parte dela começar.