Core Web Vitals são três métricas de campo que medem carga, interactividade e estabilidade visual de uma página: LCP, INP e CLS. Os limiares de referência são claros: recomendados para LCP, INP e CLS que definem bom desempenho, sempre avaliados no 75.º percentil de dados reais de utilizadores, nunca em testes isolados de laboratório.
Em resumo:
- O INP substitui o FID como métrica de interactividade, pois capta atrasos em todas as interações e não só na primeira.
- As melhorias mais eficazes aumentam a detectabilidade do recurso principal no HTML e reservam espaço para elementos dinâmicos antes de carregarem.
- Os dados de campo decidem as prioridades de correção, enquanto os testes em laboratório ajudam a reproduzir e validar as melhorias.
- Diagnósticos corretos distinguem diferenças entre medições em ambiente real e controlado, que podem apontar problemas diferentes.
- O monitoramento contínuo nos primeiros meses é essencial para evitar regressões e confirmar melhorias duradouras.
Índice
- O que mede cada métrica: LCP, INP e CLS na prática
- Limiares e interpretação: o que significa “Good”, “Need improvement” e “Poor”
- Como medir: ferramentas e workflow combinado entre campo e laboratório
- Táticas práticas para melhorar LCP, CLS e INP por ordem de impacto
- Por que lab e field divergem e como decidir o que corrigir primeiro
- Como aplicamos este processo na Cooprativa
- Tendências futuras: o que esperar das Core Web Vitals em 2026
- Como as Core Web Vitals se integram noutras métricas de desempenho e experiência
- Quando vale mesmo a pena priorizar Core Web Vitals no roadmap
- Serviço da Cooprativa para optimização técnica e integração com SEO e UX
- Fontes
- Perguntas frequentes
O que mede cada métrica: LCP, INP e CLS na prática
Cada métrica conta uma parte diferente da história de uma página, e confundi-las é o erro mais comum em diagnósticos técnicos.
- LCP (Largest Contentful Paint): mede o tempo até o maior elemento visível (geralmente uma imagem de destaque ou um bloco de texto) terminar de renderizar.
- INP (Interaction to Next Paint): mede a capacidade de resposta da página a cliques, toques e teclas ao longo de toda a sessão, não apenas na primeira interação.
- CLS (Cumulative Layout Shift): mede a soma de deslocamentos inesperados de elementos visuais durante o carregamento.
O INP substituiu o FID (First Input Delay) como métrica oficial de interactividade a partir de março de 2024, precisamente porque o FID só captava o atraso da primeira interação, ignorando bloqueios posteriores causados por scripts pesados. Na prática, o CLS costuma ter origem em causas concretas: anúncios ou embeds que carregam sem reservar espaço, imagens sem atributos de largura e altura, ou fontes web que alteram a métrica das linhas de texto no último instante.
Limiares e interpretação: o que significa “Good”, “Need improvement” e “Poor”
A classificação de cada métrica assenta sempre no 75.º percentil dos dados de campo, nunca na média nem no melhor caso observado.
O relatório Core Web Vitals do Search Console agrupa URLs semelhantes e atribui o estado de cada grupo pela métrica com pior desempenho, mesmo que as outras duas estejam dentro do limiar ideal. Convém também segmentar sempre por mobile e desktop em separado: as condições de rede e de processamento são diferentes e misturar os dois esconde problemas reais num conjunto.
Como medir: ferramentas e workflow combinado entre campo e laboratório
Medir bem exige combinar duas fontes complementares, nunca escolher apenas uma.
Os dados de campo (CrUX, acessível pelo Search Console, ou um sistema de RUM próprio) mostram o que os utilizadores reais experienciam, com a sua diversidade de dispositivos, redes e localizações. As ferramentas de laboratório (PageSpeed Insights, Lighthouse, WebPageTest) reproduzem condições controladas e servem para diagnosticar e validar correções antes de irem para produção. A biblioteca web-vitals em JavaScript permite recolher estes valores directamente no browser do visitante e enviá-los para o sistema analítico já em uso.
- Identificar, no Search Console ou no RUM, as páginas ou grupos de URL com estado “Poor” ou “Precisa de melhoria”.
- Reproduzir o problema em Lighthouse ou WebPageTest para isolar a causa técnica.
- Aplicar a correcção em ambiente de pré-produção.
- Validar o impacto real junto dos utilizadores, acompanhando o RUM durante algumas semanas.
- Manter a monitorização activa, porque melhorias tendem a regredir ao longo de seis meses sem supervisão contínua.
Dica profissional: Guarde a versão do deployment como dimensão no RUM; associa regressões de performance a alterações de código específicas em minutos, não em dias.
Táticas práticas para melhorar LCP, CLS e INP por ordem de impacto
As correcções de maior retorno nem sempre são as mais óbvias, e o guia de optimização da web.dev aponta que uma parcela significativa dos sites ainda falha o limiar recomendado de LCP por negligenciar passos simples.
- LCP: tornar o recurso principal detectável directamente no HTML (sem depender de JavaScript para o carregar), reduzir o tempo até ao primeiro byte com um CDN ou servidor mais rápido, comprimir imagens e isolar o CSS crítico do resto da folha de estilos.
- CLS: definir sempre largura e altura em imagens e vídeos, reservar espaço fixo para anúncios e embeds antes de carregarem, e evitar inserir conteúdo acima do que o utilizador já está a ler.
- INP: reduzir a quantidade de JavaScript executado a cada interação, dividir tarefas longas em blocos mais pequenos, delegar processamento pesado para web workers e atrasar o carregamento de scripts não críticos.
Aqui aparece frequentemente o detalhe que escapa a quem optimiza de forma apressada: tornar o recurso de LCP detectável no HTML ganha mais do que a maioria das optimizações de imagem isoladas, porque elimina a dependência de scripts para iniciar o carregamento. Quem quiser aprofundar este ponto específico pode consultar o guia sobre velocidade de site com exemplos aplicados a projectos reais.
Depois de qualquer alteração, confirme sempre três coisas: o novo valor em Lighthouse, a evolução no RUM ao longo de pelo menos uma semana e a ausência de efeitos secundários noutras páginas do mesmo modelo.
Dica profissional: Teste uma tática por vez. Mudanças simultâneas em LCP e CLS dificultam saber qual delas resolveu, ou piorou, o problema.
Por que lab e field divergem e como decidir o que corrigir primeiro
Um site pode obter 100 em Lighthouse e continuar com estado “Poor” no Search Console, e isso não é uma contradição: são medições de contextos diferentes.
- A cache do browser (incluindo bfcache) e o estado já aquecido do dispositivo tornam visitas repetidas mais rápidas do que a primeira carga simulada em laboratório.
- Redes móveis reais, com latência variável, raramente coincidem com a rede estável usada nos testes de laboratório.
- A diversidade de dispositivos dos visitantes reais (muitos de gama média ou baixa) não é representada por um único teste controlado.
A regra prática, confirmada pela documentação sobre divergências entre lab e field, é simples: os dados de campo decidem o que priorizar como negócio, e o laboratório serve para reproduzir e corrigir. Um fluxo típico começa no Search Console, identifica o grupo de URLs problemático, reproduz a falha em WebPageTest com throttling de rede 4G e só então aplica e valida a correcção.
Como aplicamos este processo na Cooprativa
A metodologia própria da Cooprativa combina criatividade e tecnologia, e isso aplica-se também ao trabalho técnico: já trabalhámos com mais de 100 marcas e acumulámos mais de 150 prémios em campanhas e projectos digitais. Nas equipas de SEO, UX/UI e desenvolvimento web, o processo segue sempre a mesma lógica: auditoria inicial das páginas críticas, piloto de correcções num grupo reduzido de URLs e só depois alargamento com monitorização RUM contínua. Esta sequência evita o erro mais caro em optimização técnica, que é aplicar mudanças a todo o site sem confirmar primeiro o impacto real.
Tendências futuras: o que esperar das Core Web Vitals em 2026
As métricas não são estáticas, e a substituição do FID pelo INP em 2024 mostrou que o conjunto de Core Web Vitals continua a evoluir conforme o Google identifica melhores proxies para a experiência real de navegação. Em 2026, a expectativa razoável é de ajustes graduais nos limiares e eventual introdução de sinais complementares ligados à estabilidade de scroll ou a tempos de resposta em interacções complexas, mais do que uma substituição completa das três métricas actuais. Quem acompanha o blog do Google Search Central tende a ter vantagem de alguns meses sobre quem só reage quando a mudança já está em produção.
Para equipas técnicas, a implicação prática é manter o workflow de medição desacoplado de uma métrica específica: um sistema de RUM bem construído, com a biblioteca web-vitals a alimentar o analytics, adapta-se a novos indicadores sem reescrever toda a instrumentação. A mesma lógica aplica-se a quem gere auditorias SEO regulares, onde a performance técnica é apenas uma das frentes a rever, como descrevemos na auditoria SEO prática.
Como as Core Web Vitals se integram noutras métricas de desempenho e experiência
Core Web Vitals não vivem isoladas: fazem parte de um conjunto mais amplo que inclui Time to First Byte, taxa de conversão, taxa de rejeição e métricas de negócio como valor médio de encomenda. Uma página com LCP excelente mas conteúdo irrelevante para a intenção de busca continua a perder utilizadores, e o inverso também é verdade: uma página lenta pode ter conteúdo óptimo e ainda assim afastar visitantes antes de o mostrarem.
Na prática, equipas maduras cruzam os dados de Core Web Vitals com ferramentas de analytics de comportamento (mapas de calor, funis de conversão) e com métricas de marca, porque uma experiência tecnicamente rápida mas confusa raramente converte melhor. Este cruzamento é também onde a performance técnica se liga a decisões de posicionamento competitivo, algo que exploramos com mais detalhe no artigo sobre brand equity para gestores. Equipas que avaliam especialistas externos para esta integração podem consultar critérios estruturados de contratação, como os descritos neste guia de avaliação de performance marketers, e quem procura ferramentas complementares de monitorização SEO pode também rever alternativas disponíveis no mercado, como as listadas nesta comparação de ferramentas SEO.
Quando vale mesmo a pena priorizar Core Web Vitals no roadmap
Priorizar Core Web Vitals faz sentido imediato em páginas de conversão e em páginas com tráfego orgânico elevado, onde um segundo a menos de LCP pode mover receita de forma visível. Mas a performance técnica não substitui um produto confuso ou uma proposta de valor pouco clara: resolver a velocidade de uma página mal estruturada só torna o problema mais rápido de descobrir. A recomendação para gestores é simples: trate CWV como condição necessária, nunca como estratégia de conteúdo ou de marca.
— cooprativa
Serviço da Cooprativa para optimização técnica e integração com SEO e UX
A vantagem de trabalhar com uma agência que une desenvolvimento web, SEO técnico e design UX/UI é não ter de coordenar três fornecedores diferentes para resolver um problema de performance que afecta posicionamento e conversão ao mesmo tempo.
A Cooprativa aplica este processo em forma de auditoria inicial, piloto controlado numa amostra de páginas e roadmap de melhorias com monitorização contínua, cobrindo desde SEO técnico até design UX/UI. Para perceber por onde começar o diagnóstico do seu site, fale com a equipa.
Fontes
Perguntas frequentes
O que são os Core Web Vitals?
São três métricas de campo, LCP, INP e CLS, que medem respectivamente a velocidade de carga do conteúdo principal, a resposta a interacções e a estabilidade visual da página. Fazem parte dos sinais de experiência de página usados pelo Search Console para avaliar o desempenho real sentido pelos utilizadores.
Qual a diferença entre CLS e LCP?
O LCP mede o tempo até o maior elemento visível terminar de carregar, enquanto o CLS mede o quanto os elementos da página se deslocam inesperadamente durante esse carregamento. São problemas distintos: um site pode carregar rápido (LCP baixo) e ainda assim ter elementos a saltar na tela (CLS alto).
O que é considerado uma boa pontuação em Core Web Vitals?
Um bom resultado significa limiares recomendados claros para LCP, INP e CLS que definem bom desempenho, medidos no 75.º percentil de dados reais de utilizadores. Esta classificação segue os limiares definidos na documentação do Search Console, e qualquer métrica fora destes valores coloca a página fora do estado “Good”.
Como posso ver os Core Web Vitals do meu site?
O caminho mais directo é o relatório Core Web Vitals no Search Console, que mostra dados reais de utilizadores agrupados por URL. Para diagnóstico complementar em ambiente controlado, use o PageSpeed Insights ou o Lighthouse directamente no browser.
Recomendações
Vamos pisar uva? 🍇
Utilize o formulário para entrar em contacto com a nossa equipa.
