Como este tema funciona na sua empresa
Avaliação pontual com PageSpeed Insights e Search Console: rodar o relatório nas páginas que mais geram tráfego (home, principais páginas de destino, blog mais acessado) e atacar três correções rápidas — compressão de imagens, otimização de fontes web e cache do navegador. Sem squad técnico dedicado, a abordagem é por sprint: dois ou três dias de foco semestrais para revisar limites de LCP, INP e CLS e endereçar os principais problemas. Site geralmente em WordPress ou plataformas como Shopify, Wix e Webflow, onde a maior parte das melhorias vem de configurar bem plug-ins de cache e otimização de imagem.
Monitoramento contínuo dos Core Web Vitals via Search Console, com revisão mensal das URLs marcadas como "ruim" ou "precisa de melhoria". Plano de melhoria conduzido por squad técnico (front-end + SEO) com ciclos trimestrais. Faz acompanhamento tanto do dado de laboratório (Lighthouse) quanto do dado de campo (relatório de experiência do Chrome, conhecido como CrUX). Define limites internos de desempenho para cada tipo de página e bloqueia o envio para produção quando regredem. Costuma usar Google Tag Manager e ferramentas como GTmetrix ou WebPageTest como apoio.
Monitoramento de usuário real (RUM, sigla para real user monitoring) integrado à observabilidade do site — ferramentas como Datadog, New Relic, SpeedCurve ou Akamai mPulse capturam LCP, INP e CLS dos visitantes em produção. Cada nova versão do site (release) tem orçamento de desempenho definido: se passar do limite, a entrega não vai para produção. Time dedicado de engenharia de desempenho prioriza melhorias por impacto em receita, com cálculo de quantos pontos percentuais de conversão se ganham ao reduzir LCP em meio segundo. Governança no ciclo de vida do software garante que regressões sejam detectadas antes de afetarem usuário.
Core Web Vitals
são o conjunto de três indicadores oficiais do Google para medir a qualidade da experiência de carregamento, interação e estabilidade visual de uma página: LCP (Largest Contentful Paint, tempo para o maior elemento visivel aparecer), INP (Interaction to Next Paint, tempo de resposta a interações do usuário) e CLS (Cumulative Layout Shift, soma das mudanças inesperadas de diagramação). São parte do sinal de experiência da página usado pelo algoritmo de busca, atuam principalmente como critério de desempate entre páginas com conteúdo equivalente e devem ser medidos tanto em ambiente de laboratório quanto com dados reais de usuários no campo.
O que cada métrica mede e como ler os limites
Antes de discutir governança, é preciso entender exatamente o que cada métrica captura. Os três indicadores foram escolhidos pelo Google porque cobrem dimensões distintas da experiência percebida: a velocidade de carregamento aparente, a responsividade durante o uso e a estabilidade visual ao longo da sessão.
LCP (Largest Contentful Paint) — tempo até o maior elemento aparecer. Mede quanto tempo leva, desde o início do carregamento, até que o maior elemento visível na área útil da tela (banner principal, imagem destaque, bloco de texto grande) termine de ser renderizado. Os limites oficiais: bom até 2,5 segundos, precisa de melhoria entre 2,5 e 4 segundos, ruim acima de 4 segundos. LCP alto geralmente vem de imagens muito pesadas sem dimensionamento adequado, tempo de resposta lento do servidor, recursos bloqueando a renderização ou JavaScript pesado adiando o desenho da página.
INP (Interaction to Next Paint) — responsividade durante o uso. Mede o atraso entre o usuário interagir com a página (clicar em botão, tocar em link, digitar em campo) e o navegador conseguir desenhar a próxima atualização visual. Diferente do antigo FID (First Input Delay), que mediu só a primeira interação, o INP avalia o pior atraso entre todas as interações durante a sessão. Limites: bom até 200 milissegundos, precisa de melhoria entre 200 e 500 milissegundos, ruim acima de 500 milissegundos. INP alto quase sempre indica JavaScript executando trabalho pesado no fio principal, bloqueando o navegador de responder ao usuário.
CLS (Cumulative Layout Shift) — estabilidade visual. Soma as mudanças inesperadas de posição dos elementos da página durante o carregamento — aquele momento em que o usuário vai clicar em um botão e ele "pula" para outro lugar porque uma imagem terminou de carregar. Limites: bom até 0,1, precisa de melhoria entre 0,1 e 0,25, ruim acima de 0,25. Causas comuns: imagens e anúncios sem dimensões explícitas, fontes web que substituem o texto ao carregar (FOUT/FOIT), conteúdo injetado dinamicamente acima de elementos já visíveis.
O Google considera que uma página "passa" nos Core Web Vitals quando o percentil 75 dos visitantes — ou seja, três em cada quatro carregamentos reais — atinge a categoria "bom" nas três métricas. Não basta a média; o que importa é a experiência da maioria.
Dado de campo vs. dado de laboratório: por que os dois importam
Esse é o ponto que mais confunde quem está começando a tratar Core Web Vitals. Existem duas formas de medir as métricas e elas frequentemente discordam — porque medem coisas diferentes.
Dado de laboratório (lab data). O navegador simula um carregamento em ambiente controlado: rede pré-definida, processador pré-definido, sem cache. É o que ferramentas como Lighthouse, PageSpeed Insights (na aba "Diagnóstico") e WebPageTest entregam. A vantagem é a reprodutibilidade: o mesmo teste rodado várias vezes na mesma página dá resultado parecido. A desvantagem é que não reflete necessariamente o que seus visitantes reais vivem. Um teste em rede simulada de 4G pode parecer pior ou melhor do que a média real de quem acessa de fibra ou de 3G em região remota.
Dado de campo (field data). Capta o desempenho real dos usuários enquanto navegam. A principal fonte pública é o relatório de experiência do Chrome (CrUX, sigla para Chrome User Experience Report), que agrega dados anônimos dos usuários que optaram por compartilhar com o Google. É o que aparece na aba "Descobertas dos seus usuários reais" do PageSpeed Insights, no Search Console (relatório de Core Web Vitals) e em painéis públicos como o CrUX Dashboard. Para empresas grandes, ferramentas de monitoramento de usuário real (RUM, real user monitoring) como SpeedCurve, Akamai mPulse, Datadog RUM e New Relic Browser fazem a mesma coisa internamente, sem depender de o usuário ser do Chrome ou ter optado por compartilhar dados.
A regra crítica: o Google usa dado de campo para ranqueamento, não dado de laboratório. Se o Lighthouse aponta LCP de 1,8 segundo mas o relatório de campo no Search Console diz que o percentil 75 está em 4,2 segundos, é o 4,2 que conta para o ranqueamento — e é o que reflete a experiência real. Dado de laboratório serve para diagnosticar e validar correções; dado de campo serve para saber se a operação está funcionando.
Em base pequena de tráfego, o relatório de campo do Search Console pode ficar com "dados insuficientes" para certas páginas — o CrUX precisa de volume mínimo de visitas. Quando isso acontecer, use dado de laboratório (PageSpeed Insights na aba diagnóstico) como referência principal e priorize correções pelas melhores práticas conhecidas: imagens otimizadas, fontes carregadas com display: swap, cache adequado.
Volume de tráfego costuma garantir dado de campo confiável para as principais páginas. Use o relatório do Search Console como fonte de verdade para o que está em produção e o PageSpeed Insights como ferramenta de diagnóstico das URLs marcadas como problemáticas. Considere começar a coletar dado de campo próprio via biblioteca web-vitals (script JavaScript oficial do Google) enviando para Google Analytics ou ferramenta de BI.
Ferramenta de monitoramento de usuário real (RUM) integrada à observabilidade — Datadog, New Relic, SpeedCurve, Akamai mPulse — substitui CrUX como fonte primária, porque captura 100% dos visitantes (não só Chrome com permissão) e permite recortes por dispositivo, navegador, região, página, segmento de cliente. CrUX continua útil como benchmark externo e como o que o Google "vê", mas as decisões internas saem do dado proprietário.
Como ler o relatório de Core Web Vitals no Google Search Console
O relatório do Search Console é o ponto de partida para a maioria das operações. Está em "Experiência" no menu lateral. Mostra dois recortes — Mobile e Desktop — com três status por URL: bom, precisa de melhoria e ruim. As URLs são agrupadas em "exemplos" representativos de páginas com o mesmo padrão (uma página de produto representa todas as páginas de produto similares).
O fluxo de leitura recomendado: comece pelo Mobile (responde pela maior parte do tráfego para a maioria dos sites). Identifique quantas URLs estão em "ruim" e "precisa de melhoria", veja qual métrica é a maior responsável (LCP, INP ou CLS) e clique em cada problema para ver os exemplos de URL. Replique a URL no PageSpeed Insights para entender as causas específicas e priorize correções por impacto: páginas com mais tráfego e em status "ruim" vêm primeiro.
Atenção a um ponto que confunde muita gente: o Search Console mostra dado dos últimos 28 dias agregado. Mudanças que você fizer hoje só vão aparecer no relatório semanas depois — a janela de 28 dias precisa "rolar" para refletir o novo cenário. Para validação imediata, use Lighthouse e PageSpeed Insights (aba diagnóstico). Para confirmar o impacto real, espere a janela de campo rolar.
Causas e correções típicas por métrica
Cada métrica tem um repertório bem conhecido de causas. Saber esse repertório é metade do trabalho — a outra metade é priorizar.
Para reduzir LCP. Otimizar a imagem ou o bloco que é o "maior elemento" — geralmente a imagem hero da página. Servir em formato moderno (WebP ou AVIF), com dimensões corretas para o dispositivo, comprimida sem perda visível, com atributo fetchpriority="high" para priorizar o download. Eliminar recursos que bloqueiam a renderização (CSS e JavaScript no topo do HTML), usar pré-conexão (preconnect) para domínios externos críticos, reduzir o tempo de resposta do servidor (alvo abaixo de 600 milissegundos para o primeiro byte) e considerar CDN se o site tem alcance geográfico amplo. Para sites em React, Vue ou frameworks similares, considerar renderização no servidor (SSR) ou geração estática (SSG) para que o usuário veja conteúdo antes de o JavaScript executar.
Para reduzir INP. O culpado quase sempre é JavaScript pesado bloqueando o fio principal — scripts de terceiros (analytics, mapas de calor, chat), bibliotecas grandes carregadas integralmente, listeners de evento que executam trabalho pesado. Diagnóstico: aba Performance do DevTools do Chrome durante uma sessão típica, procurar tarefas longas (acima de 50 milissegundos). Correções: dividir o código (code splitting), carregar scripts não-essenciais de forma assíncrona ou diferida (atributos async e defer), revisar scripts de terceiros (remover o que não traz retorno claro), quebrar tarefas longas em pedaços menores usando requestIdleCallback ou setTimeout.
Para reduzir CLS. Garantir que toda imagem, vídeo e iframe tenha atributos width e height explícitos (ou estilo CSS com proporção definida via aspect-ratio). Reservar espaço para banners, anúncios e conteúdo carregado dinamicamente antes de o conteúdo chegar — não deixar o navegador "abrir buraco" quando o anúncio terminar de carregar. Para fontes web, usar font-display: swap com fonte de sistema visualmente similar como fallback, ou pré-carregar a fonte com rel="preload". Nunca injetar conteúdo acima de elementos já renderizados (banners de aviso, pop-ups que empurram o conteúdo para baixo).
Limites de impacto em ranqueamento: o que esperar realista
Esse é o ponto onde muito conteúdo de SEO exagera. Vamos ao que o próprio Google diz e ao que estudos de correlação mostram.
O Google declarou que sinais de experiência da página — incluindo Core Web Vitals — são fatores de desempate, não pilares principais de ranqueamento. Em palavras simples: entre duas páginas com conteúdo equivalente, a que tem melhor desempenho tende a ranquear melhor. Mas conteúdo ruim com desempenho excelente continua perdendo para conteúdo excelente com desempenho aceitável.
Estudos de correlação (SEOClarity, Sistrix, Ahrefs e outros) confirmam: a correlação entre Core Web Vitals e posição é positiva, mas modesta. Páginas que passam nos limites têm tendência de ranquear um pouco melhor, e há indicação de impacto adicional em métricas de experiência (taxa de rejeição, taxa de conversão) que vem do próprio comportamento do usuário, não do algoritmo de busca diretamente.
O retorno real de melhorar Core Web Vitals vem por três caminhos: pequena alavancagem em desempate de ranqueamento, redução de taxa de rejeição (página rápida segura mais visitante), e aumento de taxa de conversão em páginas comerciais (cada segundo de atraso em LCP custa pontos percentuais de conversão em estudos de e-commerce). O resultado total justifica investimento — mas é cumulativo, não milagroso.
Erros comuns que invalidam o esforço
Otimizar laboratório e ignorar campo. Equipe técnica celebra Lighthouse com nota 95, mas o relatório do Search Console mostra que três quartos dos visitantes têm LCP acima de 4 segundos. O que vai para ranqueamento é o campo. Sempre validar com dado real.
Medir só a home. A home é apenas uma página. Os Core Web Vitals são medidos por padrão de URL: páginas de produto, blog, categoria, busca interna podem ter desempenho radicalmente diferente. Avaliar as principais famílias de página separadamente.
Não revisar após cada nova versão. Toda mudança no site (novo plug-in, atualização de tema, nova biblioteca JavaScript) pode regredir Core Web Vitals. Sem governança no ciclo de vida do software, o site melhora um trimestre e piora no seguinte sem ninguém perceber.
Medir apenas em desktop. Em quase todos os mercados brasileiros, a maioria do tráfego é mobile. Otimizar desktop e ignorar mobile é prioridade trocada — o algoritmo de busca usa principalmente o índice mobile-first.
Bloquear scripts de terceiros sem testar. Mexer em JavaScript de marketing (analytics, ferramentas de teste A/B, chat) para melhorar INP é tentador — mas pode quebrar mensuração crítica. Sempre coordenar com a equipe de mídia e dados antes.
Esperar melhora imediata no Search Console. O relatório usa janela de 28 dias rolante. Mudanças levam semanas para aparecer. Não desistir das correções por ausência de feedback rápido — usar Lighthouse e PageSpeed Insights para validar de imediato.
Sinais de que sua operação precisa atacar Core Web Vitals
Se três ou mais cenários abaixo descrevem sua operação, vale incluir Core Web Vitals como prioridade nos próximos trimestres.
- Search Console sinaliza URLs como "ruim" ou "precisa de melhoria" em volume relevante (acima de 10% do total).
- Lighthouse mostra LCP acima de 4 segundos na página de destino principal ou na home.
- Site usa bibliotecas JavaScript pesadas (frameworks completos sem divisão de código).
- Imagens são carregadas sem dimensões explícitas — causa direta de CLS alto.
- Não existe monitoramento contínuo de desempenho — só auditoria pontual quando "alguém lembra".
- Desempenho é medido apenas em desktop, ignorando o tráfego mobile.
- Cada nova versão do site (release) pode regredir desempenho sem ninguém perceber até a próxima auditoria.
- Time de marketing instala scripts de terceiros (analytics, chat, mapas de calor) sem revisão de impacto no INP.
Caminhos para tratar Core Web Vitals
A decisão entre fazer interno ou contratar apoio externo depende do tamanho do site, da capacidade técnica do time e do volume de templates a otimizar.
Desenvolvedor front-end com domínio de desempenho conduz o diagnóstico, prioriza correções por impacto e implementa direto no código. Marketing valida prioridades por páginas de maior tráfego e maior valor comercial.
- Perfil necessário: desenvolvedor front-end com experiência em otimização de desempenho web + analista de SEO técnico para priorizar páginas
- Quando faz sentido: site relativamente simples (menos de algumas dezenas de templates), time técnico disponível, sem dependência crítica de fornecedores externos
- Investimento: tempo do time (40-120 horas iniciais + 8-16 horas mensais de manutenção) + ferramentas como Lighthouse CI e relatório de campo (ambos gratuitos)
Consultoria de SEO técnico ou agência de desenvolvimento web faz diagnóstico, propõe plano de melhoria e executa correções (ou treina o time interno). Pode incluir implementação de monitoramento de usuário real (RUM) e estabelecimento de orçamento de desempenho.
- Perfil de fornecedor: agência de SEO técnico, agência de desenvolvimento web especializada em desempenho ou consultoria de UX com expertise em métricas web
- Quando faz sentido: site grande com muitos templates, time interno sem expertise em desempenho ou volume grande de regressões recorrentes a cada nova versão
- Investimento típico: R$ 15.000-80.000 por projeto inicial de diagnóstico e correção + R$ 3.000-15.000 mensais para acompanhamento contínuo
Suas páginas principais passam nos limites de Core Web Vitals?
O oHub conecta sua empresa a agências de SEO técnico, desenvolvedores especializados em desempenho web e consultores de UX. Em poucos minutos, descreva seu desafio e receba propostas de quem entende o mercado brasileiro.
Encontrar fornecedores de Marketing no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
O que são Core Web Vitals?
Core Web Vitals são três indicadores do Google para avaliar a qualidade da experiência de uma página web: LCP (tempo até o maior elemento visível aparecer, alvo abaixo de 2,5 segundos), INP (tempo de resposta a interações do usuário, alvo abaixo de 200 milissegundos) e CLS (estabilidade visual durante o carregamento, alvo abaixo de 0,1). Fazem parte do sinal de experiência da página usado pelo algoritmo de busca e funcionam principalmente como critério de desempate entre páginas com conteúdo equivalente.
O que é LCP, INP e CLS?
LCP (Largest Contentful Paint) mede quanto tempo leva até o maior elemento visível da página aparecer — geralmente imagem hero ou bloco de texto principal. INP (Interaction to Next Paint) mede o atraso entre o usuário interagir (clicar, tocar, digitar) e o navegador conseguir desenhar a resposta visual. CLS (Cumulative Layout Shift) soma as mudanças inesperadas de posição dos elementos durante o carregamento, capturando aquela experiência ruim de o botão "pular de lugar" no momento do clique.
Como medir Core Web Vitals?
As ferramentas principais são gratuitas: PageSpeed Insights (combina dado de laboratório via Lighthouse e dado de campo via CrUX para a URL informada), Google Search Console (relatório agregado de todo o site, na seção Experiência) e Lighthouse direto no DevTools do Chrome. Para empresas grandes, ferramentas de monitoramento de usuário real (RUM) como SpeedCurve, Akamai mPulse, Datadog RUM e New Relic Browser capturam o desempenho de 100% dos visitantes em produção.
Qual o impacto real em ranqueamento?
Core Web Vitals são fatores de desempate, não pilares principais. Entre duas páginas com conteúdo equivalente, a que tem melhor desempenho tende a ranquear melhor — mas conteúdo ruim com desempenho excelente continua perdendo para conteúdo excelente com desempenho aceitável. Estudos de correlação mostram impacto positivo modesto em posição e impacto adicional relevante em métricas de comportamento (taxa de rejeição, taxa de conversão), que se traduz em receita.
Como melhorar Core Web Vitals?
Para LCP: otimizar a imagem principal (formato moderno, dimensões corretas, compressão), reduzir tempo de resposta do servidor e eliminar recursos que bloqueiam renderização. Para INP: dividir o código JavaScript, carregar scripts não-essenciais de forma diferida, revisar scripts de terceiros pesados. Para CLS: garantir dimensões explícitas em imagens e iframes, reservar espaço para anúncios e conteúdo dinâmico, usar font-display: swap nas fontes web. Sempre validar com dado de campo, não só de laboratório.
INP substituiu FID?
Sim. INP (Interaction to Next Paint) substituiu FID (First Input Delay) como métrica oficial de responsividade nos Core Web Vitals. A diferença: FID media apenas o atraso da primeira interação do usuário com a página, enquanto INP avalia o pior atraso entre todas as interações durante a sessão — mais representativo da experiência real. Se sua operação ainda monitora FID, é hora de migrar para INP.
Fontes e referências
- web.dev (Google). Web Vitals — guia oficial das métricas e dos limites de bom, precisa de melhoria e ruim.
- Google Search Central. Page Experience — documentação oficial sobre como Core Web Vitals integram o sinal de experiência da página.
- PageSpeed Insights. Ferramenta oficial do Google para medir Core Web Vitals em laboratório e em campo por URL.
- Chrome User Experience Report (CrUX). Documentação do conjunto de dados públicos de experiência real usado pelo Google.
- Search Engine Journal. Cobertura editorial sobre Core Web Vitals, INP e estudos de impacto em ranqueamento.