📅 Atualizado em outubro 18, 2026
Uma página pode terminar de carregar e ainda frustrar quem tenta abrir o menu ou tocar em “comprar”. As Métricas Centrais da Web medem três partes dessa experiência: carregamento, resposta às interações e estabilidade visual. Os indicadores são LCP, INP e CLS; entender seus limites e corrigir a causa de cada falha ajuda a melhorar o uso da página e a avaliar seu desempenho na busca.
Uma nota isolada não explica o que acontece com cada visitante. Para decidir o que corrigir, combine dados de campo, obtidos de usuários reais, com testes de laboratório, que permitem reproduzir condições controladas.
Pontos-chave
- Uma página atende aos limites recomendados quando pelo menos 75% das experiências avaliadas ficam na faixa “boa”, conforme a métrica.
- O INP substituiu o FID como Core Web Vital; o TBT continua útil para investigar tarefas longas, mas não integra o conjunto.
- O PageSpeed Insights pode exibir dados de campo e de laboratório; o Search Console agrupa URLs com problemas semelhantes.
- Priorize a correção que afeta mais usuários e remove o obstáculo identificado, não a que rende mais pontos em uma ferramenta.
O que são as métricas Centrais da Web e quais são os limites?
As Métricas Centrais da Web são indicadores de experiência que avaliam carregamento, interatividade e estabilidade visual por meio de LCP, INP e CLS. Os limites considerados bons são LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1, no percentil 75. Isso significa avaliar a experiência da maioria das visitas, separando, quando possível, celulares e computadores.
O LCP (Largest Contentful Paint) mede quanto tempo leva para o maior elemento de conteúdo visível, como uma imagem principal ou um título, aparecer. O INP (Interaction to Next Paint) avalia a latência das interações durante a visita, como toques, cliques e digitação. Já o CLS (Cumulative Layout Shift) quantifica mudanças inesperadas na posição dos elementos.
Métrica O que mede Bom Precisa melhorar Ruim LCP Tempo de renderização do maior elemento de conteúdo Até 2,5 s Acima de 2,5 s até 4 s Acima de 4 s INP Resposta visual às interações Até 200 ms Acima de 200 ms até 500 ms Acima de 500 ms CLS Deslocamento inesperado do layout Até 0,1 Acima de 0,1 até 0,25 Acima de 0,25
Os limites e as definições constam na documentação de Core Web Vitals do web.dev. São referências para diagnosticar a experiência, não uma promessa de posição específica nos resultados. Uma página também pode ter resultados diferentes em dispositivos ou tipos de conexão distintos.
Como medir Core Web Vitals e interpretar resultados diferentes?
Use dados de campo para entender a experiência de pessoas reais e testes de laboratório para reproduzir problemas sob condições controladas. O PageSpeed Insights pode mostrar as duas fontes quando há dados disponíveis; o Lighthouse ajuda a investigar uma página em uma execução de teste; e o Search Console reúne páginas com padrões de desempenho semelhantes.
Os dados de campo vêm do Chrome UX Report (CrUX), que reúne experiências de usuários do Chrome que optaram por compartilhar dados de navegação. A amostra, o período de coleta e a disponibilidade de dados influenciam o que aparece: páginas novas ou com pouco tráfego podem não ter dados de campo suficientes. O relatório pode refletir um conjunto de URLs ou uma origem, não necessariamente a visita mais recente de uma pessoa.
O Lighthouse executa um teste em condições simuladas. Como dispositivo, rede, conteúdo e execução variam, o PageSpeed Insights e o Lighthouse podem mostrar resultados diferentes sem que uma das ferramentas esteja “errada”. Compare testes feitos com a mesma configuração e use o dado de campo para confirmar se a correção melhorou a experiência real. O Google Lighthouse também oferece diagnósticos para localizar gargalos.
O Search Console é útil para encontrar grupos de URLs que compartilham um problema, enquanto o PageSpeed Insights detalha uma URL. Para configurar o Console e acompanhar relatórios, comece pelas páginas que recebem mais visitas. Os dados podem demorar a refletir uma mudança, portanto não use uma execução isolada como prova de resultado definitivo.
Como reduzir o LCP e acelerar o conteúdo principal?
Para melhorar o LCP, descubra primeiro qual elemento é o maior conteúdo visível e por que ele demora a aparecer. Se o elemento for uma imagem de destaque, confira se o navegador a encontra cedo no HTML e se ela não está sendo carregada com prioridade baixa; se for texto, investigue o tempo de resposta do servidor e os recursos que atrasam a renderização.
O tempo até o LCP pode acumular espera no servidor, atraso para descobrir o recurso, download e renderização. Um servidor lento afeta o início da cadeia; CSS bloqueante ou JavaScript pesado pode atrasar a exibição mesmo quando o arquivo principal já chegou. Medir cada etapa evita otimizar a imagem quando a espera real está no backend.
Reduza o peso das imagens sem comprometer a leitura, escolha formatos adequados e dimensione os arquivos para o espaço em que serão exibidos. Não aplique carregamento tardio à imagem principal: o navegador precisa solicitá-la cedo. Já imagens fora da área visível podem ser carregadas conforme o visitante se aproxima delas.
Fontes, scripts de terceiros e folhas de estilo também podem segurar o conteúdo. Remova recursos que não são necessários na primeira tela e verifique se a origem consegue responder com rapidez. Melhorar a entrega do conteúdo principal pode exigir ajustes no servidor, não apenas compressão de arquivos.
O LCP melhora quando o navegador encontra cedo o conteúdo principal e consegue renderizá-lo sem esperas evitáveis.
Leia também: RPM Receitas: 7 Ajustes que Elevam Ganhos por Visitante
Como melhorar o INP e diagnosticar interações lentas?
Para melhorar o INP, encontre a interação que demora e determine se o atraso vem do processamento do evento, de uma tarefa longa de JavaScript ou da atualização visual posterior. O INP considera as interações ao longo da visita; o objetivo é que a resposta percebida pelo usuário aconteça em até 200 milissegundos no percentil 75.
O JavaScript pode bloquear a thread principal, que também precisa processar eventos e atualizar a tela. Uma tarefa longa, por exemplo, pode fazer um menu parecer inativo mesmo que o clique tenha sido registrado. Dividir tarefas extensas, adiar código que não é necessário de imediato e reduzir trabalho feito após o evento são caminhos possíveis, desde que testes confirmem que a interface continua correta.
Leia também: AdSense em Páginas AMP: Configuração e Pontos de Atenção
O TBT (Total Blocking Time) soma períodos de bloqueio da thread principal em testes de laboratório e ajuda a localizar JavaScript que impede a resposta. Ele não substitui o INP e não é uma Core Web Vital: serve como pista para investigar, enquanto o INP mede interações observadas no campo ou reproduzidas em ferramentas compatíveis. A diferença importa porque uma nota de laboratório não representa todas as ações realizadas por visitantes reais.
Inspecione scripts de terceiros, como tags de publicidade e ferramentas de análise, além do código próprio. Retirar um script sem verificar sua função pode quebrar recursos; a decisão deve considerar o custo de desempenho e a necessidade daquele componente.
Como corrigir o CLS e evitar mudanças inesperadas no layout?
Corrija o CLS reservando espaço para os elementos antes que sejam carregados. Imagens e vídeos sem dimensões declaradas podem empurrar o texto quando aparecem; anúncios, incorporações e componentes dinâmicos também deslocam conteúdo se ocuparem espaço sem previsão.
Defina largura e altura para mídias ou use uma proporção de tela compatível com o espaço disponível. Em anúncios, estabeleça um espaço reservado e aceite que ele pode ficar vazio quando não houver preenchimento. Inserir um aviso ou bloco acima do conteúdo depois que a página já começou a renderizar é outra causa comum de salto visual.
Fontes também merecem atenção: quando a fonte final chega, diferenças de tamanho e espaçamento podem reposicionar linhas. Ajustar a estratégia de carregamento e as métricas da fonte reduz essa variação, mas a solução depende do desenho tipográfico e do comportamento do navegador. Em páginas responsivas, teste mais de uma largura de tela: um espaço reservado adequado no computador pode não funcionar no celular.
O CLS cai quando cada elemento que chega depois encontra um espaço previsto no layout.
Imagens, vídeos, cache e CDN: quais otimizações priorizar?
A otimização certa depende do gargalo identificado. Reduzir o peso de um vídeo não corrige um servidor lento, assim como instalar uma CDN não resolve uma interação bloqueada por JavaScript. Use esta ordem de decisão:
- Se o LCP for uma imagem: ajuste dimensões e compressão, entregue um arquivo adequado ao dispositivo e evite adiar a imagem principal.
- Se a espera ocorrer antes do download: investigue tempo de resposta do servidor, cache e distância entre a origem e o visitante. Uma CDN pode ajudar quando a distribuição geográfica ou a latência da origem são parte do problema.
- Se um vídeo pesar na primeira tela: evite baixar o arquivo inteiro antes de a pessoa pedir para assistir. Uma imagem de prévia ou carregamento sob demanda pode reduzir o trabalho inicial.
- Se o problema for interação: reduza tarefas longas e código dispensável antes de investir em compressão de mídia.
- Se o layout saltar: declare dimensões e reserve áreas para anúncios e elementos incorporados.
Cache bem configurado evita buscar repetidamente recursos que não mudaram; a CDN pode servir esses arquivos a partir de pontos mais próximos do usuário. A vantagem depende da arquitetura do site, das regras de cache e do tipo de conteúdo. Não faça cache de respostas personalizadas sem avaliar dados privados e comportamento de sessão.
Quando usar vídeos, avalie se eles precisam carregar junto com a primeira tela. Para um player ou arquivo pequeno, a diferença pode ser discreta; para mídia pesada, o carregamento sob demanda costuma evitar trabalho que o visitante talvez nunca solicite.
Como priorizar correções e entender o impacto no Google?
Priorize problemas que afetam muitas visitas e prejudicam uma tarefa importante, como abrir um menu, ler o conteúdo principal ou concluir uma compra. Em seguida, compare o alcance da falha, o impacto na experiência e o esforço técnico. O Search Console ajuda a localizar grupos de URLs; a inspeção de uma página e os testes de laboratório ajudam a encontrar a causa.
Uma nota baixa nas Core Web Vitals não impede, por si só, que uma página seja indexada ou apareça no Google. A experiência na página é um conjunto de sinais entre muitos fatores de busca, e bons resultados nesses indicadores não garantem posição. Consulte a documentação do Google Search Central sobre experiência na página para entender como o Google descreve esses sinais.
Os KPIs mais usados para acompanhar esse tema são LCP, INP e CLS, analisados por percentil 75 e, quando os dados permitem, segmentados por tipo de dispositivo ou grupo de URLs. Para uma visão mais ampla, acompanhe também tempo de resposta do servidor, taxa de erros, conversões e indicadores de comportamento relevantes ao objetivo do site. Essas medidas complementam as Core Web Vitals, mas não alteram seus limites.
Para escolher a próxima ação, use um critério simples: se o dado de campo mostra falha em muitas visitas, priorize o impacto; se o laboratório aponta uma causa reproduzível, corrija e repita o teste; se as fontes divergem, confira amostra, dispositivo e período antes de concluir. Também vale identificar quais páginas têm maior relevância para o negócio e quais recebem tráfego de entrada antes de ordenar o trabalho.
O acompanhamento pode incluir outras Métricas de negócio, como conversão e receita, e uma leitura do desempenho do conteúdo. Isso ajuda a separar uma mudança técnica que melhora a experiência de uma alteração que só mexe na pontuação do teste.
📱 Veja este conteúdo em Web Story
Perguntas frequentes
O FID ainda faz parte das Core Web Vitals?
Não. O INP substituiu o FID como métrica de interatividade. O FID media o atraso da primeira interação, enquanto o INP considera as interações ao longo da visita.
Por que uma página pode não ter dados de campo no Pagespeed Insights?
O CrUX depende de dados de navegação disponíveis para a página ou origem. URLs novas ou com tráfego insuficiente podem não ter uma amostra exibível; nesse caso, o teste de laboratório ainda ajuda a investigar, mas não representa sozinho a experiência de visitantes reais.
O que significa avaliar o percentil 75?
Significa que pelo menos 75% das experiências observadas precisam ficar dentro do limite para aquela métrica ser classificada como boa. Esse recorte evita que uma média esconda uma parcela relevante de visitas lentas ou instáveis.
Uma CDN melhora todas as Core Web Vitals?
Não. Ela pode reduzir a latência de entrega de recursos, o que pode ajudar o LCP quando a distância até a origem é um gargalo. Não corrige, por si só, tarefas longas de JavaScript que afetam o INP nem elementos que mudam de posição e prejudicam o CLS.
Artigos Relacionados
SEO para E-commerce: 3 Ajustes Urgentes que Empresas Ignoram
Otimização On Page para Tráfego: 9 Ajustes que Funcionam
Funil de Vendas: 7 Ajustes que Multiplicam Receita
Relatórios Facebook Úteis: Métricas para Cortar Custos
SEO Local: 5 Ajustes que Multiplicam Buscas na Sua Cidade
Analytics Marketing em Ação: Métricas Essenciais e Casos
