Velocidade do site e SEO: o que corrigir primeiro nos Core Web Vitals

O que os Core Web Vitals medem e qual é o impacto no SEO?

Os Core Web Vitals medem três dimensões da experiência: carregamento do conteúdo principal, resposta às interações e estabilidade visual durante a navegação. O Largest Contentful Paint, ou LCP, registra quando o maior elemento de conteúdo visível aparece, normalmente uma imagem relevante ou um bloco de texto. O Interaction to Next Paint, ou INP, avalia a latência das interações ao longo da visita, considerando a resposta visual após ações como cliques e toques. O Cumulative Layout Shift, ou CLS, quantifica deslocamentos inesperados de elementos visíveis, com regras próprias de agrupamento desses eventos. Essas métricas não resumem toda a qualidade de um site, mas identificam problemas que tornam a experiência mais lenta, frustrante ou sujeita a erros.

As faixas consideradas boas são LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1, sendo este último uma pontuação sem unidade. A avaliação utiliza o percentil 75 das experiências medidas, portanto não basta apresentar um resultado excelente em uma única visita ou no computador da equipe. Na prática, esse percentil indica que pelo menos 75% das observações ficaram naquele valor ou abaixo dele, conforme a métrica analisada. Um conjunto de páginas só tem os três indicadores aprovados quando cada um atende ao próprio limite no recorte avaliado. Por isso, acompanhar somente a média esconde usuários com experiências ruins e pode levar a decisões equivocadas sobre a prioridade de uma correção técnica.

Os Core Web Vitals são utilizados pelos sistemas de classificação do Google, mas uma aprovação não garante posições melhores nem compensa conteúdo irrelevante para a busca. A relação entre velocidade do site e SEO deve ser entendida como parte de uma experiência útil, junto de acesso ao conteúdo, usabilidade e qualidade da resposta. Em 2026, não há fundamento para afirmar que uma nota 100 habilita uma página a aparecer em AI Overviews, AI Mode ou respostas de assistentes. Conteúdo claro e acessível continua necessário, e desempenho não substitui requisitos de indexação ou a capacidade de responder à intenção de pesquisa. O benefício mais direto das correções é remover obstáculos reais de navegação, enquanto eventuais efeitos sobre tráfego e vendas precisam ser medidos sem atribuições automáticas.

• Considere bom um LCP de até 2,5 segundos no percentil 75 das experiências avaliadas.
• Considere bom um INP de até 200 milissegundos, verificando especialmente as interações importantes no celular.
• Considere bom um CLS de até 0,1, lembrando que esse valor não representa segundos.
• Trate a aprovação nos três indicadores como um objetivo de experiência, e não como garantia de crescimento orgânico.

Dados de usuários reais ou nota de laboratório: em qual confiar?

Confie nos dados de usuários reais para avaliar a experiência observada e use os testes de laboratório para investigar causas e comparar alterações controladas. No PageSpeed Insights, a área de experiência real pode apresentar dados do Chrome UX Report, conhecido como CrUX, quando existe volume elegível suficiente. Esses registros refletem diferentes dispositivos, conexões e condições de uso, dentro dos critérios de coleta do relatório, em uma janela móvel de 28 dias. Já a análise de laboratório utiliza o Lighthouse para executar uma visita simulada com condições específicas, gerando diagnósticos e uma nota de desempenho. As duas fontes respondem a perguntas diferentes, portanto uma divergência entre elas não significa necessariamente erro da ferramenta ou ausência de problemas no site.

A primeira conferência é identificar se o PageSpeed Insights está mostrando dados daquela URL ou da origem, que reúne experiências de diferentes páginas do domínio. Quando não há informações suficientes para a página consultada, a ferramenta pode exibir o recorte mais amplo, e isso muda bastante a interpretação do diagnóstico. Uma página de produto rápida não deixa de funcionar bem apenas porque outras áreas contribuíram para uma experiência ruim no conjunto da origem. Da mesma forma, um domínio aprovado não prova que um formulário específico responde rapidamente ou que todas as páginas de campanha estão estáveis. No Search Console, os agrupamentos de URLs com experiências semelhantes ajudam a localizar padrões, mas ainda exigem inspeção de exemplos e dos componentes compartilhados.

A nota de desempenho do Lighthouse é uma síntese de métricas de laboratório, não uma reprodução direta da aprovação nos três Core Web Vitals reais. Em uma auditoria padrão de carregamento, o INP não é medido como ocorre durante uma visita com interações, e o Total Blocking Time funciona como pista relacionada ao bloqueio da thread principal. Um TBT menor costuma indicar menos bloqueios nesse cenário, mas não comprova que filtros, menus e formulários passaram a responder bem durante o uso. Para sites sem dados suficientes no CrUX, combine laboratório com monitoramento de usuários reais, também chamado de RUM, respeitando privacidade e requisitos aplicáveis. Faça várias execuções comparáveis e registre o contexto, porque uma única nota pode variar por rede, servidor, scripts externos e condições do ambiente.

Como decidir qual problema corrigir primeiro?

Corrija primeiro o problema que combina experiência ruim comprovada, grande alcance entre usuários e presença em páginas relevantes para o negócio. Essa regra evita gastar dias reduzindo alguns arquivos de uma página pouco visitada enquanto um componente compartilhado prejudica todo o catálogo no celular. Comece separando os principais modelos de página, como artigos, categorias, produtos, páginas de serviço e etapas de conversão, porque cada grupo costuma ter gargalos próprios. Em seguida, cruze os indicadores de campo com volume de acessos, participação de dispositivos móveis e importância das ações que acontecem naquele ambiente. O resultado deve ser uma fila de correções justificável por evidências, e não uma sequência automática baseada apenas na ordem das recomendações do PageSpeed Insights.

Use quatro critérios simples para comparar tarefas: gravidade do problema, quantidade de sessões afetadas, relevância comercial e esforço estimado para implementar com segurança. Um INP de 450 milissegundos em filtros usados para escolher produtos pode merecer atenção antes de um LCP de 2,7 segundos em artigos de baixo movimento. Por outro lado, um LCP acima de cinco segundos em todas as páginas de entrada pode ser mais urgente do que uma interação lenta em uma função secundária. Um CLS elevado perto do botão de compra também merece prioridade quando causa toques errados, mesmo que o restante da página carregue rapidamente. Esses exemplos ilustram critérios de decisão, não limites universais, pois o impacto precisa ser confirmado nas jornadas e nos dispositivos realmente utilizados pelo público.

Separe correções rápidas e reversíveis de mudanças estruturais, mantendo uma estimativa de risco junto da expectativa de benefício para cada tarefa aprovada. Reservar espaço para imagens pode ser simples, enquanto trocar o tema, reorganizar a renderização ou substituir uma plataforma envolve testes mais amplos e possíveis efeitos colaterais. Não há orçamento responsável baseado apenas em uma nota, porque o mesmo LCP ruim pode nascer de uma imagem excessiva ou de uma arquitetura complexa. Antes de contratar a execução, peça diagnóstico, escopo, critérios de aceite e uma explicação sobre como a melhoria será validada após a publicação. Essa disciplina reduz retrabalho e evita pagar por intervenções genéricas que deixam o principal gargalo intacto, embora produzam uma pequena mudança no relatório.

• 1. Agrupe as URLs por modelo de página para identificar problemas que podem ser corrigidos em um componente compartilhado.
• 2. Registre LCP, INP e CLS de campo com o dispositivo, o período e o nível de agregação exibido pela ferramenta.
• 3. Cruze os problemas com acessos e ações importantes para estimar quantos usuários encontram cada obstáculo.
• 4. Compare benefício esperado, esforço técnico e risco antes de aprovar mudanças em tema, scripts ou infraestrutura.
• 5. Defina como testar a jornada e medir o resultado para que cada tarefa tenha um critério de conclusão verificável.

Como melhorar LCP sem otimizar o recurso errado?

Para melhorar LCP, identifique primeiro qual elemento determina a métrica e em qual etapa ocorre a maior demora até sua exibição. Se o elemento for uma imagem, o tempo pode estar concentrado na resposta inicial do servidor, na descoberta do arquivo, na transferência ou no atraso para renderizá-lo. Se for um bloco de texto, folhas de estilo, fontes e dependências de renderização podem ter mais importância do que o tamanho das imagens abaixo da dobra. Uma imagem pequena ainda pode aparecer tarde quando só é inserida por JavaScript depois de várias requisições, por exemplo. A análise correta acompanha a sequência de carregamento e o elemento efetivo de LCP no dispositivo investigado, em vez de presumir que o banner sempre é o responsável.

Quando a imagem principal é o gargalo, entregue dimensões adequadas à tela, use compressão compatível com a qualidade necessária e avalie formatos como WebP ou AVIF. Imagens responsivas com srcset e sizes ajudam o navegador a escolher um arquivo proporcional ao espaço disponível, evitando transferir uma versão enorme para um celular. A imagem que determina o LCP normalmente não deve receber carregamento preguiçoso, porque o lazy loading pode atrasar justamente o conteúdo que precisa aparecer primeiro. Torná-la descobrível no HTML inicial e avaliar fetchpriority="high" pode ajudar quando existe disputa por prioridade, sem aplicar essa indicação indiscriminadamente a várias imagens. O preload deve ser reservado a casos justificados, pois uma configuração incorreta pode disputar banda com recursos críticos ou causar transferências desnecessárias durante o carregamento.

Se a demora começa antes da entrega do HTML, investigue o tempo de resposta do servidor, as consultas ao banco, os redirecionamentos e a estratégia de cache. Uma CDN pode reduzir a distância de entrega e ajudar com conteúdo armazenável, mas não resolve automaticamente páginas dinâmicas lentas ou processamento excessivo na aplicação. Em áreas personalizadas, o cache exige regras cuidadosas para não misturar sessões, preços específicos ou informações que pertencem a usuários diferentes durante a navegação. Também verifique CSS bloqueante, renderização dependente de JavaScript e fontes que atrasam a apresentação do conteúdo principal, priorizando mudanças sustentadas pelo rastreamento do carregamento. Depois de cada alteração, confira a aparência e a funcionalidade da primeira tela, porque antecipar conteúdo incompleto ou quebrado não representa uma melhoria real de experiência.

• 1. Identifique o elemento de LCP em exemplos representativos de cada modelo de página e tamanho de tela.
• 2. Separe o tempo de resposta do servidor, a descoberta do recurso, sua transferência e o atraso de renderização.
• 3. Remova o lazy loading da imagem principal quando ele estiver atrasando o conteúdo visível de maior importância.
• 4. Ajuste formato, compressão e dimensões da imagem sem comprometer a legibilidade ou a apresentação do produto.
• 5. Refaça o teste para confirmar que a mudança reduziu o gargalo e não apenas deslocou o problema para outro recurso.

Como melhorar INP nas interações que realmente importam?

Para melhorar INP, reduza o trabalho que impede o navegador de responder visualmente aos comandos do usuário, principalmente nas jornadas mais importantes do celular. A métrica considera o atraso até começar a processar a interação, o tempo gasto no processamento e o intervalo necessário para apresentar o próximo quadro. JavaScript excessivo, tarefas longas, cálculos pesados e atualizações extensas da interface podem aumentar esses tempos mesmo depois que o carregamento inicial parece concluído. Por isso, abrir a página e observar sua velocidade não basta para avaliar menus, seletores de variação, calculadoras, filtros e validações de formulários. O diagnóstico precisa reproduzir essas ações e, quando possível, usar telemetria para localizar quais componentes concentram as interações lentas em condições reais de uso.

Comece pelo painel de desempenho do navegador e procure tarefas longas próximas das interações lentas, distinguindo código próprio de funcionalidades e serviços de terceiros. Reduzir dependências desnecessárias, dividir trabalho pesado em tarefas menores e devolver oportunidades de execução ao navegador pode melhorar a resposta sem eliminar recursos úteis da página. Web workers podem ajudar em determinados cálculos fora da thread principal, mas não substituem o trabalho de manipulação do DOM nem resolvem qualquer lentidão automaticamente. Também vale reduzir atualizações repetidas de layout, limitar renderizações desnecessárias e evitar que uma ação simples recalcule uma interface inteira sem necessidade técnica. A escolha depende do perfil encontrado no rastreamento, pois aplicar técnicas avançadas sem identificar o bloqueio costuma aumentar a complexidade antes de gerar um benefício verificável.

Audite ferramentas de chat, mapas de calor, personalização e publicidade, mas não remova rastreamentos essenciais sem discutir os efeitos com quem mede aquisição e conversões. Em páginas usadas por Performance Max e outras campanhas, quebrar eventos pode prejudicar a mensuração e a otimização, mesmo quando o relatório de desempenho apresenta uma nota maior. Adiar scripts até depois do consentimento ou carregá-los apenas onde são necessários pode fazer sentido, desde que respeite as regras aplicáveis e a função de cada integração. Evite apenas empurrar todo o trabalho para o primeiro clique, porque isso pode transferir o custo do carregamento para o momento de interação e piorar o INP. Além disso, acompanhe a conclusão da ação separadamente, já que um feedback visual rápido não garante que uma consulta remota ou uma compra termine depressa.

Como reduzir CLS e impedir que a página mude de lugar?

Para reduzir CLS, reserve espaço antes de carregar elementos e impeça inserções inesperadas que empurrem o conteúdo enquanto o usuário está lendo ou tentando interagir. Imagens sem dimensões, anúncios, embeds, banners e componentes que chegam depois do HTML inicial estão entre os primeiros pontos que merecem investigação técnica. Definir width e height nas imagens ajuda o navegador a calcular a proporção antecipadamente, enquanto aspect-ratio pode organizar áreas responsivas de mídia e outros componentes. Essa reserva precisa refletir o comportamento real em diferentes telas, porque um espaço adequado no desktop pode continuar incorreto em um celular estreito. O objetivo é manter previsível a posição do conteúdo útil, não simplesmente esconder elementos problemáticos ou criar grandes áreas vazias sem considerar a experiência.

Mudanças de fonte também podem deslocar títulos, parágrafos e botões quando a versão final apresenta métricas muito diferentes da fonte exibida inicialmente pelo navegador. Avalie alternativas de fallback mais próximas, carregamento criterioso e ajustes métricos quando necessários, sem assumir que uma única configuração de font-display elimina todo deslocamento. Barras promocionais inseridas no topo após o início da leitura merecem atenção especial porque podem mover praticamente a página inteira em uma única atualização. Componentes de consentimento precisam ser utilizáveis e acessíveis, com apresentação planejada para evitar reorganizações inesperadas do conteúdo e sem comprometer requisitos legais ou escolhas dos usuários. Animações de propriedades que alteram o layout também devem ser revistas, considerando transformações visuais quando apropriadas e respeitando preferências de redução de movimento.

Observe o CLS durante a navegação completa, porque parte dos deslocamentos aparece somente após rolagem, carregamento de conteúdo adicional ou atualização de componentes dinâmicos. Um teste curto de laboratório pode terminar antes de um anúncio ocupar espaço ou de uma recomendação reorganizar a área em que a pessoa está lendo. Nem todo movimento entra no cálculo, pois existem regras de exclusão para determinados deslocamentos associados a entradas recentes do usuário e janelas de agrupamento. Ainda assim, ficar fora da métrica não transforma automaticamente uma mudança visual confusa em uma experiência aceitável para quem utiliza a página naquele momento. Valide estabilidade com rolagem, diferentes quantidades de conteúdo e estados de autenticação, conferindo especialmente botões e campos que podem receber toques errados quando mudam de posição.

• Defina dimensões ou proporções para imagens, vídeos e embeds antes que os arquivos terminem de carregar.
• Reserve áreas coerentes para anúncios e componentes dinâmicos, considerando os tamanhos previstos em cada tela.
• Revise fontes alternativas e definitivas para reduzir diferenças que alteram a quebra de linhas e a posição dos botões.
• Evite inserir barras acima do conteúdo já visível sem um espaço planejado para recebê-las.
• Teste deslocamentos depois da rolagem e durante interações, em vez de observar apenas a primeira tela.

Como validar as melhorias sem perseguir a nota 100?

Valide primeiro a correção técnica em condições comparáveis e depois acompanhe sua repercussão nos dados de campo, respeitando o tempo de atualização de cada fonte. Antes da publicação, registre URLs, dispositivo, configuração de teste e versão do site para construir uma referência que possa ser reproduzida por outras pessoas. Execute várias medições e compare resultados representativos, evitando escolher somente a melhor nota de cada rodada para apresentar uma melhoria que não se sustenta. Após publicar, teste navegação, formulários, compras, consentimento e eventos de conversão, pois desempenho melhor não compensa uma etapa importante que deixou de funcionar corretamente. Se houver monitoramento próprio, acompanhe tendências e recortes de usuários desde o início, lembrando que amostras pequenas podem oscilar bastante e exigir mais tempo de observação.

Os dados do CrUX refletem uma janela móvel de 28 dias, então resultados anteriores continuam presentes por algum tempo depois de uma alteração bem implementada. Não é necessário esperar exatamente 28 dias para perceber qualquer mudança, mas a substituição completa do período anterior exige acompanhar a evolução sem conclusões precipitadas. No Search Console, use os recursos de validação e os agrupamentos como apoio para verificar se os problemas estão diminuindo nas URLs relacionadas à correção. Em paralelo, observe dispositivos, modelos de página e jornadas, porque uma melhora geral pode esconder regressões localizadas em componentes que recebem menos tráfego. Se o público ou a composição das páginas visitadas mudou, considere esse contexto antes de atribuir toda a variação da métrica exclusivamente ao trabalho técnico realizado.

Acompanhe também resultados de negócio e indicadores orgânicos, mas trate correlação como pista, não como prova de que a velocidade causou uma mudança nas vendas. Sazonalidade, campanhas, preços, concorrência e alterações de conteúdo podem influenciar conversões e tráfego durante o mesmo período em que o site ficou mais rápido. Quando viável, use experimentos controlados ou compare grupos semelhantes, mantendo registro das mudanças publicadas para melhorar a qualidade da interpretação e da tomada de decisão. Defina limites de alerta para componentes e recursos críticos, incorporando verificações de desempenho ao processo de publicação para evitar que um novo script desfaça os ganhos. O trabalho termina com uma experiência melhor e um processo de prevenção, não com a captura de tela de uma nota 100 obtida em condições favoráveis.

Perguntas Frequentes