A diferença entre PageSpeed Insights e Lighthouse é esta: o PageSpeed Insights é um serviço web do Google que mostra duas coisas na mesma tela, os dados de campo de usuários reais vindos do Chrome User Experience Report e um teste de laboratório do Lighthouse rodado nos servidores do Google. O Lighthouse é a ferramenta open source por baixo, que você também pode rodar no Chrome DevTools, na linha de comando ou no CI. Use o PageSpeed Insights para saber se os visitantes reais passam nas Core Web Vitals. Use o Lighthouse, localmente e várias vezes, para depurar a página e confirmar uma correção antes de publicar.
Muita gente trata os dois nomes como sinônimos, e isso gera erro de verdade. Recebo com frequência print de um 98 no Lighthouse do DevTools com a pergunta “por que o Search Console diz que reprovamos?”. As ferramentas são parentes, mas respondem a perguntas diferentes e rodam em lugares diferentes. Este texto é sobre as ferramentas em si. Se você quer o conceito por trás delas, leia antes dados de campo vs dados de laboratório nas Core Web Vitals.
O que é o PageSpeed Insights?
O PageSpeed Insights (PSI) é a página pagespeed.web.dev. Você informa uma URL e recebe um relatório com duas seções separadas.
A seção de cima traz os dados de campo do CrUX. Mostra o percentil 75 de LCP, INP e CLS das visitas reais no Chrome nos últimos 28 dias, mais algumas métricas de diagnóstico como First Contentful Paint e TTFB, e a avaliação das Core Web Vitals (aprovada ou reprovada). Dá para alternar entre esta URL e a origem inteira, e entre celular e desktop.
A seção de baixo é uma execução do Lighthouse. Os servidores do Google carregam a página uma vez com um aparelho emulado e limitação de rede simulada, e mostram a nota de performance, as métricas de laboratório, os diagnósticos e as oportunidades. É o mesmo motor que você tem no Chrome, só que rodando em outro lugar.
O PSI também tem uma API, que devolve as duas seções em JSON. Serve para monitorar uma lista de URLs sem abrir o navegador.
O que é o Lighthouse?
O Lighthouse é uma ferramenta open source mantida pelo time do Chrome. Ele audita a página em quatro categorias: performance, acessibilidade, boas práticas e SEO. Dá para rodar de várias formas:
- No painel Lighthouse do Chrome DevTools.
- Pela ferramenta de linha de comando ou como módulo Node.
- No Lighthouse CI, para auditar cada pull request ou deploy.
- Dentro do PageSpeed Insights, onde o Google roda por você.
Além do modo padrão de navegação, que carrega a página do zero, o Lighthouse tem os modos timespan e snapshot. O timespan grava um período enquanto você interage com a página, o que chega mais perto do que acontece depois do carregamento.
O Lighthouse nunca tem dado de campo. Todo número que ele gera vem da única visita que acabou de simular.
PageSpeed Insights vs Lighthouse: lado a lado
| PageSpeed Insights | Lighthouse (DevTools, CLI, CI) | |
|---|---|---|
| Onde roda | Servidores do Google | Sua máquina ou seu runner de CI |
| Dados de campo do CrUX | Sim, por URL e origem, celular e desktop | Não |
| Teste de laboratório | Uma execução do Lighthouse por requisição | Quantas execuções quiser, com suas configurações |
| Avaliação das Core Web Vitals | Sim, com dados de campo | Não |
| INP | Pelos dados de campo | Não num carregamento normal; o Total Blocking Time é o substituto de laboratório |
| Páginas com login ou em staging | Não, a URL precisa ser pública | Sim |
| Auditorias de acessibilidade, boas práticas e SEO | Sim, pela execução do Lighthouse | Sim |
| Automação | API do PSI | CLI, módulo Node, Lighthouse CI |
Por que o PageSpeed Insights e o Lighthouse dão notas diferentes?
Porque não estão rodando o mesmo teste, mesmo com a mesma versão do Lighthouse. Algumas causas que confiro toda vez que os números não batem:
- Hardware. O PSI roda nas máquinas do Google. O Lighthouse do DevTools roda no seu notebook, e notebook rápido dá nota melhor. Abas em segundo plano e extensões também atrapalham a execução local, por isso uso janela anônima ou um perfil limpo.
- Rede e localização. O PSI busca a página a partir da infraestrutura do Google. A execução local passa pela sua conexão e pode cair em outro ponto da CDN ou num cache já aquecido.
- Configuração de limitação. Os dois simulam aparelho e rede mais lentos por padrão, mas o DevTools permite mudar isso, e muita gente muda sem perceber.
- Variação entre execuções. O resultado do Lighthouse varia de uma execução para outra até na mesma máquina, por causa da resposta do servidor, de scripts de terceiros e de timing. Uma execução é uma amostra, não um veredito. Rodo de três a cinco e olho a mediana.
Nada disso afeta a seção de dados de campo do PSI. Ela vem do CrUX e é igual para qualquer pessoa que consultar.
Em qual confiar para Core Web Vitals?
Para a pergunta “a gente passa?”, confie no dado de campo, que aparece no PageSpeed Insights e no Search Console. É esse o dado que o Google usa na avaliação das Core Web Vitals. A nota de performance do Lighthouse não entra nela. Avaliação reprovada com nota alta de laboratório é comum, e os motivos estão em o que fazer quando a avaliação das Core Web Vitals reprova.
Para a pergunta “por que esta página está lenta e minha mudança ajudou?”, o Lighthouse é a ferramenta melhor, junto com o painel Performance do DevTools. Você roda em staging, compara antes e depois e repete até o número estabilizar.
Como uso os dois numa auditoria de WordPress
Minha rotina é praticamente a mesma em todo site:
- PageSpeed Insights na home e numa URL de cada template principal (post, página, produto, categoria), lendo só os dados de campo. Celular primeiro.
- Relatório Core Web Vitals do Search Console, para ver quais grupos de URLs reprovam e quantas URLs cada grupo tem.
- Lighthouse e painel Performance do DevTools localmente no pior template, para achar o elemento LCP, as tarefas longas e os deslocamentos de layout.
- Depois de corrigir, Lighthouse de novo em staging, várias execuções, para confirmar que as métricas de laboratório mudaram.
- Quatro semanas depois, PageSpeed Insights de novo, para ver se os dados de campo acompanharam.
No WordPress, o teste de laboratório costuma pegar problemas de plugin e tema que o dado de campo só insinua: CSS do builder bloqueando a renderização, script de slider carregado em todas as páginas, imagem de destaque com lazy load. O dado de campo então mostra se a correção fez diferença para o visitante real. Para as métricas em si, veja LCP no WordPress e INP no WordPress.
E as páginas sem dado de campo?
Página nova e site com pouco tráfego muitas vezes mostram “sem dados” na seção de campo do PSI. O CrUX só publica dados quando há visitas suficientes. Dá para olhar a visão de origem, que agrega o site inteiro. Se ela também estiver vazia, o Lighthouse vira seu sinal principal por falta de opção, e vale adicionar monitoramento de usuário real. A biblioteca web-vitals, do Google, envia LCP, INP e CLS dos seus visitantes para o seu analytics e cobre o buraco até o CrUX ter dados.
Perguntas frequentes
A nota do PageSpeed Insights é a mesma do Lighthouse?
A nota do PSI é uma nota de performance do Lighthouse, tirada de uma execução nos servidores do Google. A nota do seu Lighthouse local usa o mesmo cálculo, mas outra máquina e outra rede, então as duas costumam diferir em vários pontos.
O Google usa a nota do Lighthouse para ranquear?
A documentação de experiência na página do Google fala de Core Web Vitals, que são avaliadas com dados de campo. A nota do Lighthouse é um diagnóstico de laboratório. Trato do lado de ranking em Core Web Vitals são fator de ranking?
Dá para rodar o Lighthouse num site de staging?
Dá. O Lighthouse no DevTools ou na CLI funciona em qualquer URL que sua máquina alcance, inclusive staging e páginas com login. O PageSpeed Insights só testa URL pública.
O guia principal, Core Web Vitals no WordPress, coloca as duas ferramentas no fluxo completo. Se você prefere que alguém rode essa rotina no seu site e entregue uma lista com prioridades, é isso que a minha auditoria de performance WordPress entrega.