PageSpeed, GTmetrix ou WebPageTest: como medir seu site

O cliente mandou três prints no mesmo dia. No GTmetrix, nota A. No PageSpeed Insights, 54 no celular. No Search Console, um grupo de URLs marcado como "ruim" em LCP. A pergunta era qual das três ferramentas estava mentindo. Nenhuma estava. Cada uma media uma coisa diferente, de um lugar diferente, com um aparelho diferente, e só uma delas mostrava o que o Google usa.

Este post compara as ferramentas que aparecem em toda conversa sobre velocidade de site (PageSpeed Insights, Lighthouse no DevTools, CrUX, Search Console, WebPageTest e GTmetrix) e diz quando usar cada uma. O que significam LCP, INP e CLS está em Core Web Vitals: o que são LCP, INP e CLS. Como interpretar a nota de 0 a 100 está em a nota do PageSpeed influencia o SEO?.

Laboratório ou campo: a pergunta antes da ferramenta

Toda ferramenta de velocidade entrega um de dois tipos de dado.

Laboratório é uma simulação: uma máquina carrega a página uma vez, com um aparelho e uma rede definidos, cache vazio e ninguém clicando. É reproduzível, mostra o waterfall e serve para achar a causa. Não diz como seus visitantes estão.

Campo é medição de gente de verdade. No ecossistema do Google, a fonte é o CrUX (Chrome User Experience Report), que agrega visitas de usuários do Chrome no desktop e no Android que compartilham estatísticas de uso, numa janela móvel de 28 dias. É o dado que alimenta a avaliação de Core Web Vitals. Não diz por que algo está lento.

A regra que eu uso: o laboratório encontra o problema, o campo confirma que ele existe e, depois, que foi resolvido. Quem só olha laboratório otimiza no escuro. Quem só olha campo sabe que está ruim, mas não sabe onde mexer.

As seis ferramentas lado a lado

PageSpeed Insights: o ponto de partida

O PSI junta dois blocos numa página só. Em cima, os dados de campo do CrUX: o percentil 75 de LCP, INP e CLS nos últimos 28 dias, com a avaliação de Core Web Vitals (aprovada ou reprovada). Embaixo, um teste de laboratório do Lighthouse rodado nos servidores do Google, com a nota de 0 a 100 e os diagnósticos.

Três detalhes que confundem:

• Fallback de origem. Se a URL não tem dados suficientes no CrUX, o PSI mostra os dados da origem (o site inteiro). A avaliação aprovada pode ser do domínio, não da página que você digitou. Confira se o bloco de campo está mostrando a URL ou a origem antes de comemorar.
• O perfil do teste mobile. O laboratório do PSI usa o throttling simulado do Lighthouse: no celular, 150 ms de RTT, cerca de 1,6 Mbps de download, 750 Kbps de upload e CPU 4 vezes mais lenta, emulando um Android intermediário (o Lighthouse atual se identifica como Moto G Power). Na aba desktop, a rede é 40 ms de RTT e cerca de 10 Mbps, sem desacelerar a CPU. É por isso que a nota desktop quase sempre é maior.
• A nota não é a avaliação. A nota de 0 a 100 vem do laboratório. A avaliação de Core Web Vitals vem do campo. São coisas diferentes, e a segunda é a que importa para busca.

Lighthouse no DevTools: para o que ainda não está no ar

O PSI só testa URL pública. Para staging, localhost ou página atrás de login, o Lighthouse no painel do Chrome DevTools resolve. O custo é que ele roda na sua máquina, com a sua CPU, e extensões do navegador interferem. Rode em janela anônima e compare resultados da mesma máquina entre si, nunca com o PSI.

O DevTools tem três modos. Navegação é o teste de carregamento clássico. Período (timespan) grava enquanto você interage com a página, o que ajuda a enxergar tarefas longas disparadas por cliques, coisa que o teste de carregamento não vê. Snapshot analisa a página num estado específico, como um modal aberto.

Para pegar regressão antes do deploy, o Lighthouse CI (@lhci/cli) roda o Lighthouse no pipeline. Por padrão, o lhci autorun faz três execuções por página, o que reduz o ruído de uma rodada isolada, e você define asserções para quebrar o build:

{
  "ci": {
    "collect": { "url": ["https://staging.exemplo.com/"], "numberOfRuns": 3 },
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }]
      }
    }
  }
}

Esse arquivo vai em lighthouserc.json. Use números de laboratório como trava de regressão, não como meta de Core Web Vitals.

CrUX: o dado de campo sem intermediário

O PSI e o Search Console mostram o CrUX, mas você pode consultá-lo direto. A CrUX API aceita uma origin ou uma url, separa por tipo de dispositivo (PHONE, DESKTOP, TABLET) e é atualizada diariamente, sempre com uma janela de 28 dias. A CrUX History API guarda as últimas 40 janelas semanais, e o CrUX Vis desenha essa tendência sem você escrever código. No BigQuery fica o histórico mensal por origem desde 2017, útil para comparar seu site com concorrentes.

O CrUX tem duas granularidades: página (URL) e origem. Não existe "grupo de páginas" no CrUX; isso é do Search Console. E ele só inclui o que é público e tem tráfego suficiente. Chrome no iPhone e Safari não contribuem, então um público majoritariamente de iPhone aparece pouco no campo.

Search Console: o mapa do site inteiro

O relatório de Core Web Vitals do Search Console usa o mesmo CrUX, mas organiza por site. Ele agrupa URLs com experiência parecida e dá um status para o grupo inteiro (bom, precisa melhorar, ruim) pela pior métrica: um grupo com CLS ruim é ruim, mesmo com LCP e INP bons. Celular e desktop têm status separados. Se um grupo não tem dados suficientes, o Search Console tenta um grupo maior, da origem; se ainda faltar dado, não mostra nada.

É a ferramenta para priorizar: você vê que o problema é "LCP acima de 2,5 s em 140 URLs de produto", abre uma URL de exemplo e vai investigar no laboratório. Depois do conserto, o botão de validação inicia um acompanhamento de 28 dias.

WebPageTest: quando o Lighthouse não explica

O WebPageTest roda num navegador real, no local e na conexão que você escolher, e mostra um waterfall completo (DNS, conexão, TTFB, download de cada recurso) e um filmstrip quadro a quadro, onde você vê o momento exato em que o conteúdo principal aparece. Dá para repetir o teste várias vezes e trabalhar com a execução mediana.

A diferença técnica que mais pesa: o WebPageTest limita a rede no nível de pacote, que a documentação do Lighthouse descreve como a simulação de rede mais precisa, embora com mais variação entre execuções. O Lighthouse no PSI, por padrão, carrega a página sem limitação e estima as métricas para o perfil de rede. Quando o PSI diz "tudo certo" e o usuário reclama, é no WebPageTest que eu abro o waterfall.

GTmetrix: relatório bonito, outra régua

O GTmetrix usa o Lighthouse para a parte de performance e mostra uma nota em letra que mistura essa performance com uma nota de "estrutura" própria da GTmetrix. Por isso a nota A do GTmetrix e o 54 do PSI não se contradizem: são réguas diferentes, testadas de lugares e com perfis de aparelho e rede diferentes dos do PSI mobile.

Onde ele brilha é na apresentação: um relatório com waterfall e recomendações que dá para mandar para quem não é dev. Só não use a letra do GTmetrix como prova de que os Core Web Vitals estão bons; ela é laboratório.

Qual usar em cada situação

• "Meu site está bom para o Google?" Search Console (site inteiro) e o bloco de campo do PSI (URL).
• "Por que esta página está lenta?" Lighthouse no DevTools ou no PSI para a lista de diagnósticos; WebPageTest para o waterfall e o filmstrip.
• "Vou subir uma mudança, piorou?" Lighthouse CI no pipeline.
• "Como estou contra o concorrente?" CrUX (API, CrUX Vis ou BigQuery), porque é a mesma fonte para os dois.

Achada a causa, o conserto quase sempre passa por peso e prioridade da imagem principal. Eu reduzo as imagens no compressor de imagens do Quick Tools, que roda no navegador e não envia nada para servidor, e sigo a ordem de ajustes de como reduzir o tempo de carregamento inicial. Se o problema for imagem abaixo da dobra carregando cedo demais, o caminho está em lazy loading de imagens e componentes.

Perguntas frequentes

Por que o PageSpeed e o GTmetrix dão notas tão diferentes?

Porque testam de lugares diferentes, com perfis de aparelho e rede diferentes, e o GTmetrix soma à performance uma nota de estrutura própria. O teste mobile do PSI simula um celular intermediário numa rede lenta, o que derruba a nota. Compare cada ferramenta com ela mesma ao longo do tempo, nunca uma com a outra.

Meu site não aparece com dados de campo. O que eu uso?

Se o CrUX não tem volume para a URL nem para a origem, não há dado de campo do Google. Trabalhe com laboratório (PSI e WebPageTest) e, se quiser números reais, colete os seus com a biblioteca web-vitals (onLCP, onINP, onCLS) enviando para o seu analytics.

Por que o Search Console mostra como ruim uma URL que eu nunca testei?

Porque ele avalia grupos de URLs parecidas. A URL entra no status do grupo, mesmo sem ter dados próprios suficientes. Teste algumas URLs de exemplo do grupo no laboratório; a causa costuma ser o mesmo template.

Corrigi o problema. Quando o campo mostra a melhora?

O CrUX trabalha com 28 dias corridos, então a melhora entra aos poucos e só aparece por inteiro depois de cerca de um mês. A validação do Search Console também acompanha por 28 dias. O laboratório mostra o efeito na hora; use-o para confirmar que a mudança está no ar.

Ferramenta certa para a pergunta certa

Nenhuma dessas ferramentas está errada. O erro é fazer a pergunta para a ferramenta errada: perguntar ao GTmetrix se o Google está satisfeito, ou ao Search Console por que a imagem demora. Comece pelo campo (Search Console e PSI) para saber se existe problema, desça para o laboratório (Lighthouse e WebPageTest) para achar a causa, e deixe o Lighthouse CI vigiando os deploys.

Referências

• About PageSpeed Insights, Google for Developers
• Lighthouse throttling, GoogleChrome/lighthouse
• Perfis de throttling do Lighthouse (Lantern Constants), ChromeDevTools/devtools-frontend
• Lighthouse user flows, GoogleChrome/lighthouse
• Lighthouse CI getting started, GoogleChrome/lighthouse-ci
• CrUX API, Chrome for Developers
• CrUX methodology, Chrome for Developers
• Tools that use CrUX data, Chrome for Developers
• Relatório de Core Web Vitals, Ajuda do Search Console
• Why lab and field data can be different, web.dev
• Web Vitals, web.dev