Modelo de auditoria de Core Web Vitals e velocidade da página

Audite e corrija os Core Web Vitals (LCP, INP, CLS) e a velocidade geral da página usando dados de campo e de laboratório para atingir os bons limites do Google.

Os Core Web Vitals são as métricas de experiência do usuário que o Google usa para medir carregamento, interatividade e estabilidade visual no mundo real: LCP (<=2,5 s), INP (<=200 ms) e CLS (<=0,1). Este modelo orienta você a medir cada métrica com dados de campo e de laboratório, diagnosticar a causa raiz, aplicar correções comprovadas e testar novamente para confirmar que os ganhos se mantêm. Percorra as variantes em ordem ou vá direto à métrica que está falhando para suas URLs.

6 variações prontas para usar

Benchmark e dados de campo vs. laboratório

Estabeleça uma baseline para cada Core Web Vital antes de mudar qualquer coisa e aprenda em qual fonte de dados confiar para pontuação versus depuração.

Defina sua baseline

Antes de otimizar qualquer coisa, registre onde cada métrica está hoje para [URL da página]. O Google classifica com base em dados de campo (usuários reais do Chrome, o conjunto de dados CrUX, uma janela contínua de 28 dias), então esse é o número que importa para a Pesquisa. Os dados de laboratório (Lighthouse, um único carregamento simulado) servem para depuração, porque são repetíveis e fornecem traces acionáveis.

  • Fonte de campo: obtenha dados do CrUX no PageSpeed Insights ou no relatório de Core Web Vitals do Search Console para [Propriedade].
  • Fonte de laboratório: execute o Lighthouse (Chrome DevTools ou PageSpeed Insights) para reproduzir e rastrear os problemas.
  • Registre os limites: LCP bom <=2,5 s, INP bom <=200 ms, CLS bom <=0,1; anote seu valor atual e a aprovação/reprovação no "percentil 75" de cada uma.

Os dados de campo e de laboratório vão divergir, e isso é esperado. O laboratório carrega em um dispositivo e rede; o campo agrega muitos. Use o laboratório para encontrar a causa e o campo para confirmar a cura.

Resultado: uma tabela de baseline registrando cada métrica, seu valor de campo atual, valor de laboratório e status de aprovação/reprovação para [Data].

Correções de Largest Contentful Paint (LCP)

Diagnostique e corrija o LCP lento para que o elemento de conteúdo principal seja renderizado em 2,5 segundos para a maioria dos visitantes.

Faça o conteúdo principal aparecer rápido

O LCP mede quando o maior elemento visível (geralmente uma imagem de destaque, um pôster de vídeo ou um bloco de título) termina de renderizar. A meta é <=2.5s no percentil 75. Identifique o elemento LCP no Lighthouse e ataque as quatro fases que o atrasam.

  1. Time to first byte: reduza a resposta do servidor para [Origem] com cache, um host mais rápido ou renderização na borda.
  2. Recursos que bloqueiam a renderização: adie CSS e JavaScript não críticos para que o navegador possa pintar mais cedo.
  3. Atraso no carregamento do recurso: adicione preload para a imagem LCP e defina [fetchpriority=high] nela para que o navegador a busque cedo.
  4. Atraso na renderização do recurso: garanta que a imagem LCP não seja carregada de forma lazy e seja servida em formato moderno no tamanho certo.

Evite carregar a imagem de destaque via fundo CSS ou JavaScript do lado do cliente, pois o navegador a descobre tarde demais. Uma imagem referenciada diretamente, pré-carregada e dimensionada corretamente quase sempre vence.

Verifique: execute o Lighthouse novamente e confirme que o elemento LCP e sua linha do tempo de carregamento para [URL da página] caíram abaixo de 2,5 s.

Correções de Interaction to Next Paint (INP)

Melhore a responsividade para que a página reaja rapidamente a cliques, toques e teclas pressionadas, substituindo a métrica mais antiga FID.

Faça as interações parecerem instantâneas

O INP substituiu o FID como Core Web Vital em março de 2024. Ele mede a latência das interações ao longo de toda a visita à página, relatando aproximadamente a pior delas. A meta é <=200ms. Um INP ruim quase sempre remonta a JavaScript monopolizando a thread principal quando o usuário age.

  • Encontre tarefas longas: use o painel Performance do DevTools para identificar tarefas da thread principal acima de 50 ms durante a interação em [URL da página].
  • Divida o JavaScript: quebre tarefas longas em partes menores e ceda a thread principal para que a entrada possa ser processada.
  • Reduza o trabalho da thread principal: remova ou adie scripts não utilizados, especialmente tags de terceiros pesadas como [Nome da tag].
  • Otimize os manipuladores de eventos: aplique debounce ao trabalho custoso e adie atualizações não urgentes até depois do próximo paint.
  • Minimize o tamanho do DOM e o custo de layout: um DOM grande ou profundamente aninhado torna cada interação mais cara.

O objetivo é manter a thread principal livre quando os usuários clicam e tocam, para que o navegador possa pintar uma resposta dentro do orçamento de 200 ms.

Verifique: teste interações reais e confirme que o INP de campo tende ao bom para [Propriedade].

Correções de Cumulative Layout Shift (CLS)

Impeça que o conteúdo salte durante o carregamento para que o layout permaneça visualmente estável abaixo de um CLS de 0,1.

Impeça o layout de saltar

O CLS mede mudanças inesperadas de layout do conteúdo visível durante a vida útil da página. A meta é <=0.1. Os deslocamentos frustram os usuários e causam cliques errados, e quase sempre vêm de elementos que carregam sem espaço reservado.

  • Dimensione sua mídia: sempre defina os atributos width e height (ou um aspect-ratio CSS) em imagens, vídeos e iframes para que o navegador reserve espaço antes de carregarem.
  • Reserve espaço para embeds e anúncios: dê aos slots de [Anúncio ou embed] um contêiner com min-height fixa para que não empurrem o conteúdo para baixo.
  • Nunca insira conteúdo acima do conteúdo existente: evite injetar banners, avisos ou barras de cookies que empurram a página para baixo após a renderização.
  • Evite deslocamentos por troca de fonte: pré-carregue as fontes principais e use [font-display] com sabedoria para limitar o reflow.
  • Reserve espaço para UI dinâmica: mantenha espaço para elementos adicionados por JavaScript para que se expandam em um espaço pré-alocado.

Trate qualquer "salto" que você veja durante o carregamento como um defeito a ser eliminado.

Verifique: observe o filmstrip de carregamento e confirme que não há deslocamentos visíveis em [URL da página].

Otimização de assets e entrega

Reduza e acelere os recursos que uma página envia — imagens, JavaScript, CSS, cache e CDN — para elevar todas as métricas de uma vez.

Envie menos, entregue mais rápido

A maioria dos problemas de velocidade de página se resume a enviar bytes demais ou enviá-los devagar demais. Otimizar a entrega melhora LCP, INP e CLS juntos, porque o navegador tem menos a baixar, analisar e executar.

  • Imagens: sirva formatos modernos (como WebP ou AVIF), dimensione-as às dimensões exibidas e comprima; faça lazy-load apenas de imagens abaixo da dobra, nunca da imagem LCP.
  • JavaScript: minifique, faça tree-shaking e code-splitting para que cada página carregue só o que precisa; adie ou torne async os scripts não críticos.
  • CSS: minifique, remova regras não utilizadas e faça inline do CSS crítico do conteúdo acima da dobra em [Modelo].
  • Cache: defina tempos de cache longos para assets estáticos e use nomes de arquivo com fingerprint para que as atualizações invalidem o cache com segurança.
  • CDN: sirva assets de locais de borda perto dos usuários e habilite compressão (Brotli ou gzip) no [Provedor de CDN].

Audite os scripts de terceiros sem piedade, pois são uma causa comum e oculta de carregamentos lentos e má responsividade.

Verifique: compare o tamanho total de transferência e a contagem de requisições antes e depois para [URL da página].

Testar novamente e monitorar

Confirme que as correções funcionaram nos dados de campo e configure um monitoramento contínuo para que regressões sejam detectadas cedo.

Confirme o ganho e mantenha-o

Uma correção só está pronta quando os dados de campo a confirmam. Como o CrUX usa uma janela contínua de 28 dias, as melhorias para usuários reais levam tempo para aparecer, então valide em duas etapas: primeiro no laboratório para feedback instantâneo, depois no campo ao longo das semanas seguintes.

  1. Reexecute os testes de laboratório: use o Lighthouse ou o PageSpeed Insights para confirmar que o problema no nível do trace em [URL da página] foi resolvido.
  2. Observe os dados de campo: acompanhe o CrUX no relatório de Core Web Vitals do Search Console e espere a janela de 28 dias atualizar antes de declarar sucesso.
  3. Defina metas: mantenha cada grupo de URLs em LCP <=2.5s, INP <=200ms, CLS <=0.1 no percentil 75.
  4. Monitore continuamente: adicione monitoramento de usuários reais (RUM) ou auditorias agendadas para [Propriedade] para que regressões apareçam rápido.
  5. Proteja-se contra desvios: reaudite após grandes releases, novas tags de terceiros ou mudanças de template.

Desempenho não é um projeto único; trate-o como um orçamento contínuo que você defende a cada deploy.

Resultado: um relatório antes/depois e uma cadência de monitoramento anotada para [Data].

Como usar este modelo

  1. Execute o PageSpeed Insights nas suas URLs principais e registre tanto os valores dos dados de campo (CrUX) quanto os de laboratório (Lighthouse) para LCP, INP e CLS.
  2. Compare cada métrica com os bons limites do Google: LCP <=2,5 s, INP <=200 ms, CLS <=0,1 no percentil 75, e sinalize toda métrica que falhar.
  3. Para LCP com falha, identifique o elemento LCP, depois faça o preload dele, defina prioridade alta de fetch, remova o lazy-loading e corte recursos que bloqueiam a renderização e o tempo de resposta do servidor.
  4. Para INP com falha, abra o painel Performance do DevTools durante a interação, encontre tarefas longas da thread principal acima de 50 ms e quebre ou adie o JavaScript que as causa.
  5. Para CLS com falha, adicione width e height (ou aspect-ratio) a todas as imagens e embeds, reserve espaço para anúncios e conteúdo dinâmico e pare de inserir conteúdo acima do conteúdo existente.
  6. Otimize a entrega de assets servindo formatos de imagem modernos, minificando e fazendo code-splitting de JS e CSS, habilitando compressão e um CDN e definindo tempos de cache longos.
  7. Reexecute o Lighthouse para confirmar que cada problema no nível de laboratório foi corrigido, depois monitore os dados de campo do CrUX no Search Console, considerando a atualização da janela contínua de 28 dias.
  8. Configure um monitoramento contínuo com RUM ou auditorias agendadas e teste novamente após cada grande release para detectar regressões antes que cheguem aos usuários.

Dicas profissionais

  • Confie nos dados de campo (CrUX) para saber se você passa e nos de laboratório (Lighthouse) para diagnosticar o porquê; espere que os dois números difiram.
  • Nunca faça lazy-load da sua imagem LCP, e nunca a carregue via fundo CSS ou JavaScript, porque o navegador a descobre tarde demais.
  • Problemas de INP são quase sempre JavaScript na thread principal; auditar e adiar tags de terceiros pesadas é muitas vezes o maior ganho isolado.
  • Elimine qualquer salto visível durante o carregamento reservando espaço com antecedência; se você consegue ver o conteúdo se mover, seu CLS vai sofrer.

Perguntas frequentes

Quais são os três Core Web Vitals e seus bons limites?

O Largest Contentful Paint (LCP) deve ser de 2,5 segundos ou menos, o Interaction to Next Paint (INP) deve ser de 200 milissegundos ou menos, e o Cumulative Layout Shift (CLS) deve ser de 0,1 ou menos. Cada limite deve ser atingido no percentil 75 das visitas de usuários reais para ser considerado bom.

O que aconteceu com o First Input Delay (FID)?

O INP substituiu o FID como Core Web Vital em março de 2024. O FID media apenas o atraso antes de a primeira interação ser processada, enquanto o INP mede a latência completa das interações ao longo de toda a visita à página, dando um retrato mais completo da responsividade.

Qual é a diferença entre dados de campo e dados de laboratório?

Os dados de campo vêm de usuários reais do Chrome no conjunto de dados CrUX ao longo de uma janela contínua de 28 dias, e é o que o Google usa para classificação. Os dados de laboratório vêm de um único carregamento simulado em uma ferramenta como o Lighthouse; são repetíveis e ideais para depuração, mas não refletem o que os usuários reais vivenciam.

Por que minha pontuação do Lighthouse difere da pontuação de campo do CrUX?

O Lighthouse executa um carregamento em um dispositivo e rede simulados específicos, enquanto o CrUX agrega muitos usuários reais em dispositivos, conexões e estados de cache variados. A divergência é normal. Use os dados de laboratório para encontrar e corrigir a causa, e os de campo para confirmar que a correção funcionou para os usuários reais.

Por que meus Core Web Vitals não melhoraram logo após eu implantar uma correção?

Os dados de campo atualizam lentamente porque o CrUX usa uma janela contínua de 28 dias, então as melhorias levam semanas para aparecer por completo. Confirme a correção em ferramentas de laboratório como o Lighthouse para feedback instantâneo, depois observe o relatório de campo no Search Console à medida que a janela se atualiza gradualmente com os dados pós-correção.

Qual é a causa mais comum de um INP ruim?

Tarefas longas de JavaScript bloqueando a thread principal quando um usuário interage. Quando a thread principal está ocupada, o navegador não consegue processar a entrada e pintar uma resposta dentro do orçamento de 200 ms. Quebrar tarefas longas, adiar scripts não críticos e de terceiros e ceder a thread principal são as correções mais eficazes.