Os Core Web Vitals não são apenas uma métrica técnica do Google — eles são a medida direta de quanto dinheiro seu site está perdendo por segundo. Em 2026, a velocidade de carregamento é um fator de ranqueamento confirmado no algoritmo do Google e um dos maiores determinantes da taxa de conversão de sites de serviços e e-commerce. Este guia explica cada métrica dos Core Web Vitals em linguagem de negócio, não de engenharia, e apresenta as correções de maior impacto para PMEs.
Em maio de 2020, o Google anunciou um conjunto de métricas chamado Core Web Vitals para medir a experiência real do usuário em sites. O anuncio foi acompanhado de uma confirmação crítica: a partir de 2021, essas métricas passariam a influenciar diretamente o ranqueamento nos resultados de busca. Em outras palavras, o Google começou a recompensar sites rápidos e penalizar sites lentos com posicionamento orgânico.
A lógica do Google é simples: o mecanismo de busca quer recomendar a melhor experiência possível para seus usuários. Se um site demora 8 segundos para carregar e o usuário sai frustrado, esse comportamento prejudica a reputação do Google como ferramenta de busca. Portanto, o Google tem incentivo financeiro e de produto direto para priorizar sites que oferecem experiência rápida e estável.
“Impacto financeiro documentado: a Vodafone UK reportou aumento de 8% em conversões após melhorar o LCP em 31%. A Tokopedia (maior e-commerce da Indonésia) registrou 23% mais sessões e 35% mais novos usuários após melhoria nos Core Web Vitals. Para PMEs, uma melhoria de 1 segundo no LCP costuma resultar em aumento de 2-5% na taxa de conversão.”
O LCP (Largest Contentful Paint) mede o tempo que leva para o maior elemento visível da página — normalmente a imagem de destaque do hero ou o título principal — ser completamente renderizado na tela. Em termos simples: é o tempo que o visitante espera até ver o 'conteúdo principal' da página. A nota do Google: LCP abaixo de 2.5 segundos é considerado BOM. Entre 2.5 e 4 segundos é PRECISA MELHORAR. Acima de 4 segundos é RUIM.
Os culpados mais comuns por LCP lento em sites de PME: imagem do hero não otimizada (um banner de 4MB em JPEG sem compressão sozinho pode causar 5+ segundos de LCP), servidor de hospedagem lento sem CDN (Content Delivery Network), e recursos bloqueantes no <head> (fontes externas carregando de forma bloqueante, scripts de terceiros mal implementados).
Como corrigir o LCP: converta a imagem principal do hero para formato WebP e limite a 200KB. Adicione o atributo `fetchpriority='high'` na tag <img> do hero para dizer ao browser que essa imagem é a prioridade máxima. Se usar WordPress, instale o plugin WP Rocket ou Perfmatters e ative 'Preload Key Requests'. Adicione um CDN (Cloudflare gratuito funciona excelentemente) para servir os arquivos do seu servidor mais próximo do visitante.
O INP (Interaction to Next Paint) substituiu o FID em março de 2024 como métrica oficial. Ele mede o tempo de resposta do site a qualquer interação do usuário — clique em botão, toque em menu mobile, digitação em campo de busca. É a métrica que captura 'o site trava quando eu clico'. INP bom: abaixo de 200ms. Precisa melhorar: 200-500ms. Ruim: acima de 500ms.
O INP alto (site lento para responder interações) é causado principalmente por JavaScript excessivo executando na thread principal do browser. Em sites WordPress, o problema costuma vir de plugins desnecessários (cada plugin adiciona JS). Em sites customizados, scripts de terceiros como chatbots, widgets de redes sociais e ferramentas de analytics mal implementados são os maiores vilões. A solução é usar o relatório de Cobertura de Código no Chrome DevTools para identificar qual JavaScript está sendo carregado mas não sendo executado — e diferir ou remover esse código.
O CLS (Cumulative Layout Shift) mede o quanto o conteúdo da página 'pula' durante o carregamento — quando elementos se movem inesperadamente enquanto o usuário tenta ler ou clicar. O CLS é a métrica responsável pela experiência de 'eu estava prestes a clicar no botão certo e a página se mexeu e eu cliquei no errado'. CLS bom: abaixo de 0.1. Precisa melhorar: 0.1-0.25. Ruim: acima de 0.25.
Causas comuns de CLS: imagens sem dimensões definidas (o browser não reserva espaço para a imagem durante o carregamento, e quando ela carrega empurra todo o conteúdo abaixo), anúncios que são injetados dinamicamente na página empurrando o conteúdo, e fontes da web que causam FOUT (Flash of Unstyled Text — o texto muda de tamanho quando a fonte customizada carrega substituindo a fallback).
Como corrigir CLS: sempre especifique os atributos width e height em todas as tags <img> do site. Use `font-display: swap` no CSS de fontes para evitar FOUT. Para anúncios (AdSense, banners), reserve o espaço do anúncio com um placeholder de tamanho fixo antes do anúncio carregar. Se usar WordPress, verifique no Elementor ou Gutenberg se as imagens têm dimensões definidas — é o erro de CLS mais comum em sites de PME.
Existem duas perspectivas de medição: Lab Data (dados de laboratório) e Field Data (dados de campo, reais). Lab Data é medido por ferramentas que simulam carregamento em um ambiente controlado — Google PageSpeed Insights, Lighthouse no Chrome DevTools. Field Data é coletado de usuários reais que visitaram seu site e é reportado no Google Search Console (Relatório de Experiência de Página) e na Chrome UX Report.
Para a análise inicial, use o Google PageSpeed Insights (pagespeed.web.dev). Cole a URL da página mais importante do seu site (geralmente a home ou a página de serviço principal). Analise as notas separadas para Mobile e Desktop — o Google usa os dados Mobile como fator de ranqueamento primário. Notas abaixo de 50 no mobile precisam de ação urgente. Entre 50-89 há oportunidades claras de melhoria. Acima de 90 o site está bem otimizado.
No Google Search Console, acesse Experiência → Core Web Vitals para ver dados reais de usuários do seu site, separados por tipo de dispositivo (mobile e desktop) e por URL. Esse relatório é mais valioso que o PageSpeed para decisões de negócio, porque mostra o impacto em URLs específicas com tráfego real — não uma estimativa de laboratório.
Se o site usa WordPress, você pode implementar 80% das melhorias de Core Web Vitals sem tocar em código. Semana 1: Instale WP Rocket ou LiteSpeed Cache (plugins de performance). Ative: Minificação de CSS/JS, Lazy Loading de imagens, Cache de página. Custo: R$0 a R$200/ano. Semana 2: Instale o plugin ShortPixel ou Imagify e converta todas as imagens existentes para WebP em lote. Custo: R$0 a R$50/ano.
Semana 3: Adicione o Cloudflare ao seu domínio (plano gratuito). O Cloudflare atua como CDN, acelerando a entrega de arquivos estáticos e protegendo contra ataques DDoS simultaneamente. Semana 4: Audite e desative plugins WordPress não utilizados. Cada plugin desativado que você não usa reduz o JavaScript e CSS carregados desnecessariamente. O objetivo: ter menos de 15 plugins ativos em um site de serviços simples.
Core Web Vitals ruins me impedem de aparecer na primeira página do Google? Não necessariamente. Os Core Web Vitals são um dos mais de 200 fatores de ranqueamento. Um site com conteúdo extremamente relevante, muitos backlinks de qualidade e forte autoridade de domínio pode ranquear bem mesmo com Core Web Vitals mediocres. Mas em nichos competitivos onde múltiplos sites têm autoridade similar, o desempate vai para o site com melhor experiência de usuário — e os Core Web Vitals são a medida oficial disso.
Meu desenvolvedor disse que meu site tem nota 90 no Desktop mas 40 no Mobile. Qual priorizar? Sempre o Mobile. O Google usa o índice Mobile-First — o bot de indexação do Google rastreia e avalia primariamente a versão mobile do site. Sua posição nos resultados de busca é determinada pela qualidade da experiência mobile, independentemente de como o desktop performa. Um site com nota 95 no desktop e 40 no mobile terá suas posições baseadas no 40.
Quanto custa melhorar os Core Web Vitals profissionalmente? Para sites WordPress, um desenvolvedor especializado em performance pode fazer uma auditoria e implementação completa por R$1.500 a R$4.000 — com resultados sustentáveis. Agências que cobram R$500/mês de 'manutenção' geralmente não incluem otimização de performance no escopo. Peça sempre o relatório do PageSpeed antes e depois do trabalho para verificar se houve melhora real e mensurável.
Desde 2019, o Google adotou oficialmente o Mobile-First Indexing — o robô de rastreamento do Google prioriza a versão mobile do site para determinar o ranqueamento, independente de como o desktop se comporta. Isso significa que um site com velocidade de 95/100 no desktop e 40/100 no mobile terá seu ranqueamento determinado pelo score de 40. Para a maioria das PMEs, a versão mobile do site é significativamente mais lenta que a desktop — principalmente por imagens não responsivas, scripts pesados que não são necessários em mobile e layouts que foram projetados para desktop e adaptados precariamente.
O comportamento do usuário mobile reforça a urgência: pesquisa do Google (2025) mostra que 53% dos visitantes mobile abandonam o site se o carregamento ultrapassar 3 segundos. Em conexões 4G comuns no Brasil, sites com mais de 3MB de assets totais frequentemente ultrapassam esse limite. Use o Google PageSpeed Insights especificamente no modo mobile, simulando uma conexão 4G lenta, para ver a realidade da experiência dos seus visitantes. As otimizações de maior impacto para mobile são invariavelmente as mesmas: compressão de imagem para WebP, eliminação de JavaScript não essencial e escolha de um servidor ou CDN geograficamente próximo ao Brasil.