PageSpeed Insights explicado: o que cada nota significa e como corrigir
PageSpeed Insights explicado
PageSpeed Insights explicado: notas, métricas e correções | We.Inc
O que cada número do PageSpeed Insights significa, dados de campo versus dados de laboratório, limites de LCP, INP, CLS, FCP e TTFB, pesos da nota e código que corrige resultados vermelhos.
O PageSpeed Insights mostra dois relatórios. O de cima traz dados de campo de visitantes reais do Chrome nos últimos 28 dias, avaliados no percentil 75. O de baixo é um teste de laboratório do Lighthouse com nota de 0 a 100: 90 ou mais é bom, de 50 a 89 precisa melhorar, abaixo de 50 é ruim. Corrija primeiro as métricas de campo.
Limites das métricas de campo usados pelo PageSpeed Insights
Métrica
Bom
Precisa melhorar
Ruim
LCP (Largest Contentful Paint)
2.5 s ou menos
2.5 a 4 s
acima de 4 s
INP (Interaction to Next Paint)
200 ms ou menos
200 a 500 ms
acima de 500 ms
CLS (Cumulative Layout Shift)
0.1 ou menos
0.1 a 0.25
acima de 0.25
FCP (First Contentful Paint)
1.8 s ou menos
1.8 a 3 s
acima de 3 s
TTFB (experimental)
0.8 s ou menos
0.8 a 1.8 s
acima de 1.8 s
A maioria das pessoas fica olhando a grande nota circular, mas esse número vem de uma única visita simulada em um celular com conexão limitada. Este guia separa as duas metades do relatório, permite avaliar os seus próprios números com base nos limites oficiais e associa cada métrica vermelha à mudança que normalmente a melhora.
Teste a sua URL em pagespeed.web.dev e olhe primeiro o bloco de dados de campo. Se ele disser que não há dados suficientes, só o teste de laboratório está disponível.
Digite os seus valores de LCP, INP, CLS, FCP e TTFB no avaliador abaixo para ver em qual faixa cada um cai.
Abra a seção de correções da pior métrica e aplique a mudança de código correspondente.
Espere novos dados de campo. O relatório de usuários reais cobre uma janela móvel de 28 dias, então as melhorias aparecem aos poucos, e não na manhã seguinte.
O teste de laboratório para celular roda em um aparelho intermediário emulado com rede lenta, então é normal a nota no celular ser menor que no desktop.
As notas de laboratório variam alguns pontos entre execuções. Rode o teste três vezes e olhe o resultado do meio antes de concluir que algo mudou.
O teste de laboratório não consegue medir o INP, porque ninguém clica em nada. O Total Blocking Time faz esse papel, então um TBT alto costuma indicar um INP ruim.
Tags de terceiros, como widgets de chat, mapas de calor e scripts de anúncios, muitas vezes pesam mais que o seu próprio código. Confira a lista de requisições de terceiros antes de reescrever o seu app.
Perguntas frequentes
Por que meus dados de campo e minha nota de laboratório são tão diferentes?
Eles medem coisas diferentes. Os dados de campo são o que usuários reais do Chrome viveram nos próprios aparelhos e redes ao longo de 28 dias. A nota de laboratório é um único carregamento simulado com limitação fixa. Uma página pode tirar 60 no laboratório e ainda passar nas Core Web Vitals em campo, ou o contrário.
A nota do Lighthouse afeta o ranking no Google?
O Google descreve as Core Web Vitals como medidas da experiência real do usuário alinhadas com o que os seus sistemas principais de ranking recompensam. A orientação dele para a Pesquisa não cita a nota de laboratório de 0 a 100 como fator de ranking, então trate essa nota como um diagnóstico para encontrar problemas.
O que é TTFB e qual é um bom valor?
Time to First Byte é quanto tempo o navegador espera até chegar o primeiro byte do HTML, incluindo redirecionamentos, DNS, abertura da conexão e trabalho do servidor. O PageSpeed Insights considera bom 800 ms ou menos. Armazenar o HTML em cache na borda de uma CDN é a correção mais comum.
Como a nota de desempenho do Lighthouse é calculada?
No Lighthouse 10 em diante, ela é uma combinação ponderada de cinco métricas de laboratório: Total Blocking Time 30 por cento, LCP 25 por cento, CLS 25 por cento, FCP 10 por cento e Speed Index 10 por cento. Cada métrica é antes convertida em uma subnota de 0 a 100 segundo uma curva.
Por que aparece que não há dados de campo para o meu site?
O Chrome User Experience Report só publica dados de páginas e origens com visitas elegíveis suficientes. Sites novos ou com pouco tráfego muitas vezes não têm nenhum, então conte com o teste de laboratório e o seu próprio monitoramento até o tráfego crescer.
Leia o relatório de cima para baixo
O primeiro bloco responde se os visitantes reais tiveram uma boa experiência. Ele mostra o valor no percentil 75 de cada métrica, o que significa que três de cada quatro visitas foram pelo menos tão rápidas. A meta é passar nas três Core Web Vitals (LCP, INP e CLS).
O segundo bloco é uma única execução do Lighthouse. Os diagnósticos e as oportunidades dele mostram por que uma métrica de campo está lenta, porque o rastreamento de laboratório lista os arquivos, imagens e scripts envolvidos.
Um exemplo de antes e depois
Pense na página inicial típica de uma pequena empresa, com uma foto hero de largura total carregada de forma lazy, uma fonte web sem estratégia de fallback e três tags de marketing no head. Neste exemplo, a imagem do LCP só começa a ser baixada depois que o script termina, então o LCP cai na faixa ruim.
Tirar o loading=lazy do hero, adicionar fetchpriority=high, servir a foto em AVIF ou WebP no tamanho exibido e fazer as tags carregarem depois que a página fica interativa ataca cada subparte do LCP. Essas são as mudanças mostradas no código abaixo; os seus números vão depender da sua página.
Onde cada métrica costuma dar errado
O LCP se divide em quatro partes: tempo até o primeiro byte, atraso no carregamento do recurso, duração do carregamento do recurso e atraso na renderização do elemento. Encontre primeiro a maior parte e corrija essa.
O INP tem a ver com tarefas longas de JavaScript rodando quando alguém toca ou digita. O CLS vem de coisas que mudam de tamanho depois da primeira pintura: imagens sem dimensões, banners atrasados e fontes que trocam para uma largura diferente.
Como a nota de laboratório é ponderada
O Lighthouse 10 em diante combina cinco métricas de laboratório. O Total Blocking Time tem o maior peso, então JavaScript pesado prejudica a nota mais que qualquer outra coisa.
Pesos da nota de desempenho do Lighthouse
Métrica de laboratório
Peso
Métrica de campo relacionada
Total Blocking Time
INP
Largest Contentful Paint
LCP
Cumulative Layout Shift
CLS
First Contentful Paint
FCP
Speed Index
Nenhuma diretamente
Auditorias comuns e a correção de cada uma
O que uma auditoria vermelha está dizendo
Auditoria ou sintoma
Por que está vermelha
Correção habitual
A imagem do Largest Contentful Paint foi carregada de forma lazy
O navegador espera o layout antes de buscar o hero
Tire o loading=lazy do hero e adicione fetchpriority=high
Elimine recursos que bloqueiam a renderização
CSS ou scripts síncronos no head atrasam a primeira pintura
Coloque o CSS crítico inline e adie os scripts
Dimensione as imagens corretamente
As imagens são maiores que o tamanho exibido
Use srcset e sizes e exporte na largura de exibição
Sirva imagens em formatos modernos
JPEG ou PNG onde AVIF ou WebP seriam menores
Converta e sirva com picture ou uma CDN de imagens
Reduza o JavaScript não usado
Código enviado para recursos que não estão nesta página
Divida os bundles por rota e remova bibliotecas não usadas
Reduza o impacto de código de terceiros
As tags bloqueiam a thread principal
Carregue as tags depois da interação ou quando o navegador estiver ocioso
Os elementos de imagem não têm width e height explícitos
O espaço não é reservado, então o conteúdo pula
Defina width e height ou aspect-ratio
Garanta que o texto fique visível durante o carregamento da fonte web
O texto fica escondido enquanto a fonte é baixada
Use font-display: swap e faça preload da fonte principal
O tempo de resposta inicial do servidor foi longo
TTFB lento por HTML sem cache
Faça cache do HTML na borda e corte redirecionamentos
Trechos de correção
Imagem hero que carrega primeiro
Sem lazy loading no provável elemento do LCP, prioridade de busca alta, formatos modernos e dimensões reais para nada se deslocar.
Fonte que não esconde o texto
Faça preload do único arquivo de fonte usado acima da dobra e deixe o texto aparecer em uma fonte de fallback até ela chegar.
Tag de terceiros carregada depois que a página se estabiliza
Injeta um script de marketing quando o navegador fica ocioso, para que ele não concorra com a primeira renderização nem com o primeiro toque.
Reserve espaço para conteúdo que chega depois
Um embed ou espaço de anúncio com proporção fixa impede que o conteúdo abaixo dele pule quando ele carrega.
Checklist de velocidade
Siga estes passos em ordem
Passo
Verificação
Dados de campo: qual entre LCP, INP e CLS falha no percentil 75?
Elemento do LCP: é uma imagem, e ela é carregada de forma lazy ou descoberta tarde?
TTFB: o HTML está em cache, e há redirecionamentos antes dele?
JavaScript: qual é o Total Blocking Time e quais scripts o causam?
Layout: imagens, embeds e banners têm espaço reservado?
Fontes: o font-display está definido e o arquivo principal tem preload?
Bom
Precisa melhorar
Ruim
Avalie os seus números
Digite os valores do seu relatório para ver se cada um é bom, precisa melhorar ou é ruim.