As Core Web Vitals são três métricas do Google que avaliam pontos-chave da experiência do usuário: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Elas nasceram para dar um padrão objetivo a algo que, por anos, parecia subjetivo: “este site carrega rápido?”, “responde ao meu clique sem atrasos?”, “a página fica pulando enquanto abre?”.
Em 2024, o INP substituiu o FID como métrica oficial de responsividade, tornando a avaliação mais fiel ao que as pessoas sentem ao usar uma página. Para o Google, páginas que atingem bons resultados nessas três medidas tendem a oferecer melhor experiência e, por consequência, têm mais chances de performar bem na busca quando a relevância do conteúdo é comparável.
LCP (Largest Contentful Paint): carregamento do conteúdo principal
O LCP (Largest Contentful Paint) mede o tempo que o maior elemento visível no carregamento inicial da página, geralmente uma imagem de destaque, um bloco de texto principal ou até mesmo um vídeo leva para aparecer por completo. O Google considera uma boa experiência quando esse tempo é de até 2,5 segundos.
As falhas mais comuns acontecem por resposta lenta do servidor, imagens pesadas, arquivos CSS ou JavaScript bloqueando a renderização ou pela ausência de priorização dos recursos críticos.
Como melhorar, na prática
- Entregar pixels mais cedo: Critical CSS inline e adiar CSS não crítico; remover JS bloqueante no início.
- Imagens corretas no primeiro paint: preload da hero, formatos modernos (WebP/AVIF), compressão e dimensionamento responsivo (<picture>/srcset).
- Rede e infraestrutura: CDN, HTTP/2/HTTP/3, cache bem configurado, redução de TTFB.
- Prioridade de recursos: preconnect/dns-prefetch para domínios essenciais e ordem de carregamento que favoreça o LCP.
NP (Interaction to Next Paint): resposta às interações
O NP mede o tempo entre a interação do usuário (clique, toque, tecla) e a próxima atualização visual. Considera a sessão inteira e reporta o percentil 98 ou seja, captura “os piores momentos” da página. Em 12 de março de 2024, o INP substituiu o FID como Core Web Vital.
Meta: < 200 ms.
Ele costuma falhar por conta de muito JavaScript no carregamento inicial, longas tarefas no main thread, listeners custosos, renderizações pesadas após cliques.
Como reduzir atrasos
- Quebrar JS em pedaços menores: code splitting por rota/componente e carregamento sob demanda.
- Evitar tarefas longas: fatiar trabalhos acima de ~50 ms, usar Web Workers para processos pesados.
- Responder primeiro, finalizar depois: confirmar a ação com feedback imediato (ex.: estado “carregando”) e adiar cálculos não críticos.
- Hidratação e frameworks: preferir parcial/progressiva, limitar bibliotecas e componentes que rodam no primeiro paint.
CLS (Cumulative Layout Shift): estabilidade visual
O INP (Interaction to Next Paint) avalia a rapidez com que a página responde às interações do usuário cliques, toques ou digitação durante toda a sessão. O ideal é que esse tempo fique abaixo de 200 milissegundos, garantindo uma navegação fluida e sem atrasos perceptíveis.
Problemas de INP geralmente estão ligados a JavaScript pesado, manipuladores de eventos ineficientes, tarefas longas que bloqueiam o thread principal e ao excesso de scripts de terceiros que atrasam a resposta da interface.
Como estabilizar
- Sempre declarar largura/altura (ou aspect-ratio) para imagens e iframes.
- font-display: swap e pré-carregamento da fonte principal; se possível, auto-hospedar e fazer subset.
- Reservar espaço para embeds e anúncios; usar transform em vez de propriedades que reflowam a página.
- Skeletons e placeholders com medidas fixas no layout.
Core Web Vitals: resumindo
Em termos práticos:
- LCP mostra quanto tempo leva para o conteúdo principal aparecer por completo na tela, o alvo é até 2,5 s.
- INP indica a resposta da página às interações ao longo da sessão; a experiência fica consistente quando esse tempo fica abaixo de 200 ms.
- CLS mede se a página “salta” enquanto carrega; o ideal é manter a pontuação abaixo de 0,1. Esses parâmetros são os mesmos usados na documentação e nas ferramentas oficiais do Google (Search Console, PageSpeed Insights e CrUX).
Por que o Core Web Vitals é relevante para SEO e negócios
A busca do Google considera sinais de experiência de página. Em disputas apertadas de relevância, páginas mais rápidas, estáveis e responsivas tendem a levar vantagem. Além de SEO, impactos aparecem em métricas de negócio: menos abandono no carregamento, mais páginas por sessão, mais conversões.
O Google incentiva explicitamente que proprietários de sites “alcancem” as metas de Core Web Vitals para melhorar a experiência e ter melhores chances na pesquisa.
Leia também: Como melhorar o SEO on-page.
Como o Google mede (e por que “laboratório” e “campo” divergem)
Há dois jeitos de olhar para performance:
- Dados de laboratório: simulações controladas (Lighthouse/PSI) úteis para diagnosticar gargalos antes de pôr no ar.
- Dados de campo: experiências de usuários reais (CrUX/Search Console/PSI Field Data), aqueles que contam para a avaliação.
Diferenças acontecem porque o mundo real varia: rede, aparelho, localização, comportamento. O Google explica por que esses números podem divergir e como interpretar cada um. Em PageSpeed Insights, você vê os dois blocos (lab + field) na mesma tela. Para “passar” na avaliação, o 75º percentil das três métricas deve estar na zona “Boa”.
Onde medir no dia a dia
O Search Console oferece relatórios de Core Web Vitals separados por Mobile e Desktop, sempre com base nos dados reais do CrUX. Essa visão é útil para identificar gargalos e priorizar melhorias por grupos de URL. Já o PageSpeed Insights (PSI) combina dados de campo e de laboratório, permitindo analisar o desempenho de uma página específica e trazendo uma lista de oportunidades de otimização.
Por fim, o Lighthouse, integrado ao DevTools, é indicado para inspeções locais ou em ambientes de staging, pois possibilita simulações detalhadas e diagnósticos técnicos que ajudam no ajuste fino da performance.
Como montar um plano de melhoria (passo a passo)
Um bom plano de melhoria em Core Web Vitals começa pela priorização: use o relatório do Search Console para identificar grupos de URLs classificados como “Ruim” ou “Precisa melhorar” em Mobile e Desktop, dando atenção especial às páginas com maior tráfego ou impacto direto na receita.
Em seguida, é hora do diagnóstico individual, rodando o PageSpeed Insights para cruzar dados de campo e laboratório e entender os principais gargalos, sejam imagens pesadas, scripts bloqueando a renderização, falta de cache ou excesso de recursos não utilizados.
A partir daí, as ações podem ser organizadas em ondas de implementação. As primeiras correções são rápidas e de alto retorno, como otimizar imagens, ativar compressão, configurar cache ou CDN e remover arquivos JS e CSS desnecessários. Na segunda etapa entram ajustes mais técnicos, como aplicação de CSS crítico, divisão de código, uso de hidratação parcial, implementação de web workers e otimização de fontes.
Por fim, a terceira onda envolve mudanças de arquitetura mais profundas, como adotar renderização no servidor (SSR ou SSG), substituir bibliotecas pesadas e revisar padrões de interface que causam instabilidade de layout.
Após as implementações, é fundamental validar os resultados no PageSpeed Insights e acompanhar, ao longo das semanas, a evolução dos indicadores de Mobile e Desktop no Search Console, que reflete os dados reais de uso no período de 28 dias.
Lazy loading, Lighthouse e outras dúvidas comuns
- Lazy loading ajuda o LCP? Ajuda quando aplicado a imagens abaixo da dobra; a hero deve carregar cedo (sem lazy) e, se necessário, com preload. Use IntersectionObserver para o restante. Boas práticas estão na documentação do Google.
- Google Lighthouse x PSI: o Lighthouse mede em laboratório; o PSI reúne laboratório e campo. Use o primeiro para testar hipóteses e o segundo para confirmar se a experiência real melhorou.
- Avaliação “aprovado” nas CWV: o Google considera aprovado quando, no 75º percentil, as três métricas estão na zona Boa; a avaliação pode ser por página ou em nível de origem (origin) se houver dados suficientes.
O que acontece se estiver ruim?
Você tende a ver quedas de engajamento (rejeição mais alta, menos páginas por sessão), menor conversão e menor competitividade orgânica quando disputa posição com páginas igualmente relevantes.
Não é um “botão liga/desliga” de ranking, mas pode desempatar resultados parecidos em qualidade de conteúdo. O próprio Google incentiva atingir bons níveis de Core Web Vitals como parte de uma boa experiência para usuários da Busca.
Performance do site como alavanca contínua para marcas
Os Core Web Vitals oferecem uma régua clara para orientar times de SEO e desenvolvimento. Ao atacar LCP, INP e CLS com um plano contínuo, priorizando páginas de maior impacto, corrigindo gargalos de rede, recursos e código, e validando com dados de campo você constrói uma base técnica que sustenta tráfego, conversão e resiliência a mudanças de algoritmo.
Na MO4, tratamos Core Web Vitals como parte da estratégia de desenvolvimento e manutenção, não só como “pontuação”. Cruzamos dados reais (Search Console/CrUX) com diagnósticos técnicos (PSI/Lighthouse) e um roteiro de implementação para otimizar e trazer o máximo de performance para os sites.
Se você quer transformar performance em resultados, conte conosco!
