--- title: "Como melhorar os Core Web Vitals: guia de campo — Dardo" description: "Descubra qual métrica e template falham no Search Console, corrija LCP, INP e CLS pela causa e confirme nos dados de campo, com notas para sites 3D." url: "https://dardo.studio/pt/blog/melhorar-core-web-vitals/" language: "pt" translations: {"en":"https://dardo.studio/en/blog/pass-core-web-vitals/","es":"https://dardo.studio/es/blog/mejorar-core-web-vitals/"} updated: "2026-10-15T14:07:03.361Z" --- [Blog](https://dardo.studio/pt/blog/) # Como melhorar os Core Web Vitals: guia baseado em dados de campo para sites de marketing Descubra qual métrica e template falham no Search Console, corrija LCP, INP e CLS pela causa e confirme o resultado nos dados de campo cerca de 28 dias depois. Por [Nicolás Cerón](https://dardo.studio/pt/nicolas-ceron/) ·15 de outubro de 2026 ![Pátio ferroviário com neblina na hora azul sob lâmpadas âmbar: uma única linha carmesim atravessa fileiras de trilhos cinzentos até uma cabine de sinalização iluminada num portão aberto.](https://dardo.studio/_astro/01M4YY262MHNX487SWZ7QSA1V6_Z1igRsR.webp) ## Pontos-chave - Comece pelo relatório de Core Web Vitals do Search Console: ele agrupa URLs parecidas, rotula cada grupo pela pior métrica e lista suas páginas por impressões, então você corrige um template, não uma página. - Na análise do Google sobre dados de campo do Chrome, o site mediano com LCP ruim esperava 1,29 segundo antes de solicitar a imagem do LCP e levava 350 milissegundos para baixá-la, então corrija primeiro a descoberta e a prioridade, e só depois a compressão. - O INP conta apenas cliques, toques e teclas; em sites de marketing, o lento costuma ser o botão Aceitar de um banner de consentimento ou uma tag que roda durante o carregamento. - O Lighthouse vê um único carregamento de página, enquanto o CrUX conta os deslocamentos de layout da visita inteira, incluindo conteúdo carregado sob demanda durante a rolagem e deslocamentos causados por passar o mouse. - Os dados de campo do Google são uma janela móvel de 28 dias, então anote a data de cada versão e avalie uma correção cerca de quatro semanas depois. ## 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](https://dardo.studio/pt/blog/core-web-vitals-brasil/): 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](https://dardo.studio/pt/servicos/otimizacao-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](https://almanac.httparchive.org/en/2025/performance) 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](https://support.google.com/webmasters/answer/9205520)). 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](https://dardo.studio/pt/ferramentas/velocidade-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](https://developer.chrome.com/docs/crux/history-api)). 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](https://dardo.studio/pt/servicos/configuracao-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](https://developer.chrome.com/blog/devtools-grounded-real-world)). 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](https://web.dev/articles/optimize-lcp)). Corrija a parte que está fora de proporção. | Subparte do LCP | Proporção saudável do LCP | O que costuma alongá-la | Primeira correção | | ---------------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | Tempo até o primeiro byte | Cerca de 40% | Cadeias de redirecionamento, HTML sem cache, servidor distante, query strings que ignoram o cache | Colocar o HTML em cache em uma CDN e remover redirecionamentos | | Atraso de carregamento do recurso | Menos de 10% | Imagem principal definida em CSS ou JavaScript, com lazy loading, dentro de um carrossel ou em outro host | Uma tag img no HTML com fetchpriority="high", ou um preload quando o CSS precisar defini-la | | Duração do carregamento do recurso | Cerca de 40% | Arquivos grandes demais e um único tamanho para todas as telas | Tamanhos responsivos em AVIF ou WebP | | Atraso na renderização do elemento | Menos de 10% | CSS e scripts que bloqueiam a renderização, fontes web em um LCP de texto, uma imagem principal que espera o JavaScript para aparecer | CSS crítico inline, scripts adiados, imagem principal no HTML, font-display | 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](https://web.dev/blog/common-misconceptions-lcp)). 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](https://web.dev/articles/inp)). 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](https://github.com/GoogleChrome/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](https://developer.chrome.com/docs/web-platform/long-animation-frames)). 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](https://web.dev/articles/cookie-notice-best-practices)); 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](https://web.dev/articles/tag-best-practices)). - **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](https://web.dev/articles/optimize-long-tasks)). 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](https://web.dev/articles/cls)). 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](https://web.dev/articles/bfcache)). 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](https://web.dev/articles/vitals-spa-faq)). 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](https://dardo.studio/pt/blog/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](https://dardo.studio/pt/servicos/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](https://dardo.studio/pt/servicos/manutencao-de-sites/) incluem esse relatório mensal. Se o objetivo por trás do trabalho é o ranqueamento, combine-o com [SEO técnico](https://dardo.studio/pt/servicos/seo-tecnico/), 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](https://dardo.studio/pt/contato/?service=website-speed-optimization): diremos por qual métrica e por qual parte dela começar. ## Perguntas frequentes **Quanto tempo leva para as melhorias de Core Web Vitals aparecerem no Search Console?** Cerca de quatro semanas. O Search Console e o PageSpeed Insights leem os dados de campo do Chrome como uma janela móvel de 28 dias, então as visitas a uma correção publicada hoje se misturam com visitas antigas até a janela avançar. Testes de laboratório e a sua própria medição de usuários reais mostram a mudança em dias. Quando todas as URLs de um grupo estiverem corrigidas, inicie a validação no relatório de Core Web Vitals, que monitora o grupo por 28 dias. **Por que o PageSpeed Insights não mostra dados de campo do meu site?** Os dados de campo do Chrome só incluem páginas e origens descobertas publicamente e visitadas por usuários elegíveis do Chrome em número suficiente. Uma página com poucas visitas recorre aos dados da origem, e um site pequeno pode não ter nenhum; dardo.studio não tinha em 14 de outubro de 2026. Nesse caso, meça LCP, INP e CLS nas suas próprias visitas com a biblioteca de código aberto web-vitals e use testes de laboratório para achar as causas. **Minha nota no Lighthouse é baixa, mas meus Core Web Vitals passam. O que devo corrigir?** Os dados de campo decidem se você passa; o Lighthouse é um carregamento simulado em um celular de nível intermediário com conexão lenta. Use os diagnósticos dele, como o elemento LCP e seu detalhamento, para achar causas que também aparecem nos dados de campo, e não corra atrás da nota em si. O contrário também acontece: uma página pode ir bem no Lighthouse e falhar em INP ou CLS no campo, porque o Lighthouse não vê toques nem deslocamentos depois do carregamento. **Qual Core Web Vital devo corrigir primeiro?** O que está ruim para o maior número de visitas, começando pelos grupos móveis com mais impressões no Search Console. No celular, costuma ser o LCP: nos dados de 2025 do HTTP Archive, 62% dos sites móveis tinham LCP bom, contra 77% no INP e 81% no CLS. Dentro do LCP, comece pela subparte fora de proporção, normalmente o atraso de carregamento do recurso ou o tempo até o primeiro byte, antes de comprimir imagens. **Um plugin ou uma CDN corrige os Core Web Vitals automaticamente?** Em parte. Uma CDN que coloca o HTML em cache encurta o tempo até o primeiro byte, e a otimização de imagens encurta o download. Nenhuma das duas decide qual elemento vira o seu LCP, quais scripts rodam quando alguém toca na tela nem onde se reserva espaço para um embed ou um banner, e essas são as causas habituais de LCP, INP e CLS ruins. Elas estão nos templates e nas configurações de tags, então é lá que se corrigem. **Os Core Web Vitals medem cada página de um site com transições de página?** Ainda não na maioria das ferramentas. Quando o JavaScript troca de página sem um carregamento completo, o Chrome contou cada interação e cada deslocamento de layout posterior contra a URL em que o visitante entrou. O Chrome 151 adicionou APIs que medem cada soft navigation separadamente e, em outubro de 2026, passou a publicar métricas experimentais de soft navigation no CrUX, com a meta de torná-las padrão em maio de 2027. Até lá, teste INP e CLS nas páginas que as pessoas acessam depois de entrar. ## Fontes e leituras adicionais Fontes desta página, com mais detalhes dos publicadores originais. - [web.dev: Web Vitals](https://web.dev/articles/vitals) · web.dev - [Search Console Help: Core Web Vitals report](https://support.google.com/webmasters/answer/9205520) · support.google.com - [Chrome for Developers: CrUX History API](https://developer.chrome.com/docs/crux/history-api) · developer.chrome.com - [Google for Developers: About PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about) · developers.google.com - [web.dev: Optimize Largest Contentful Paint](https://web.dev/articles/optimize-lcp) · web.dev - [web.dev: Common misconceptions about how to optimize LCP](https://web.dev/blog/common-misconceptions-lcp) · web.dev - [web.dev: Interaction to Next Paint (INP)](https://web.dev/articles/inp) · web.dev - [Chrome for Developers: Long Animation Frames API](https://developer.chrome.com/docs/web-platform/long-animation-frames) · developer.chrome.com - [web.dev: Optimize Cumulative Layout Shift](https://web.dev/articles/optimize-cls) · web.dev - [web.dev: Back/forward cache](https://web.dev/articles/bfcache) · web.dev - [web.dev: Core Web Vitals and single-page apps FAQ](https://web.dev/articles/vitals-spa-faq) · web.dev - [HTTP Archive: Web Almanac 2025, Performance](https://almanac.httparchive.org/en/2025/performance) · almanac.httparchive.org [Nicolás Cerón](https://dardo.studio/pt/nicolas-ceron/) Nicolás Cerón é o fundador da Dardo, um estúdio de marca, design e desenvolvimento web em Bogotá, na Colômbia. ## Artigos relacionados - [**Sites 3D: quando valem a pena e como mantê-los rápidos**Quando um site 3D vale a pena, quando vídeo ou imagens funcionam melhor e como mantivemos rápidos, acessíveis e usáveis os dez mundos 3D do Janus Observatory.](https://dardo.studio/pt/blog/sites-3d/) - [**PostHog vs Google Analytics: qual um site de marketing ou SaaS precisa e quando usar os dois**O GA4 conecta com Google Ads e Search Console; o PostHog traz replay, feature flags e experimentos. Qual você precisa, quanto cada um custa e como usar os dois.](https://dardo.studio/pt/blog/ga4-vs-posthog/) - [**Webflow ou WordPress em 2026: qual é melhor? Custos reais, edição, SEO e velocidade**Quanto custa em três anos um site bilíngue de 20 páginas com blog de 300 posts no Webflow e no WordPress, e como eles se comparam em edição, SEO e velocidade.](https://dardo.studio/pt/blog/webflow-ou-wordpress/) - [**Core Web Vitals no Brasil e na América Latina: quantos sites são aprovados por país (dados 2026)**Em setembro de 2026, só 33,7% dos sites foram aprovados nas Core Web Vitals no celular no Brasil, contra 63,3% nos EUA. Os dados por país e o que fazer.](https://dardo.studio/pt/blog/core-web-vitals-brasil/) ## Continue explorando. - [Serviço · **Otimização de velocidade de sites e Core Web Vitals**](https://dardo.studio/pt/servicos/otimizacao-de-velocidade-de-sites/) - [Seu projeto · **Vamos conversar**](https://dardo.studio/pt/contato/)