O Que é Lighthouse e Como Interpretar o Relatório?

O que é o Lighthouse e o que ele mede

Lighthouse é a ferramenta de auditoria de páginas web do Google, embutida no Chrome DevTools e disponível também como pacote de linha de comando. Ela roda a página em um navegador headless e devolve notas de zero a cem em cinco categorias: performance, acessibilidade, boas práticas, SEO e, quando aplicável, PWA.

A categoria de performance é a mais citada porque combina várias métricas de carregamento, como LCP, tempo de bloqueio da thread principal e mudança de layout, em uma única pontuação. Ela não substitui o Core Web Vitals medido em campo, mas serve para testar uma mudança antes de publicar, sem esperar tráfego real se acumular para saber se algo melhorou ou piorou.

Lighthouse e PageSpeed Insights são a mesma ferramenta?

Não são a mesma interface, mas rodam o mesmo motor por baixo. O PageSpeed Insights chama o Lighthouse para gerar a parte de laboratório do relatório e complementa com dado de campo do Chrome UX Report, quando a página tem volume suficiente de visitas reais.

A diferença prática está no propósito de cada um. O Lighthouse embutido no DevTools serve para testar localmente, antes de subir uma mudança, direto na máquina de quem está desenvolvendo. O PageSpeed Insights serve para checar uma URL já publicada e comparar o resultado de laboratório com o comportamento real dos visitantes. Rodar os dois para a mesma página raramente traz a nota idêntica, porque cada execução parte de condições de rede levemente diferentes, mesmo com o mesmo motor por trás.

Lighthouse de laboratório não é o mesmo dado do Search Console

Dado de laboratório vem de uma execução isolada, numa máquina com condições de rede e CPU simuladas. Dado de campo vem do Chrome UX Report, agregando visitas reais de usuários de verdade ao longo de várias semanas.

Suponha um projeto que tira 95 no Lighthouse local e ainda aparece com Core Web Vitals no vermelho no Search Console. Isso acontece porque o laboratório testa uma página isolada, sem cache aquecido, sem a extensão de navegador que o usuário real tem instalada e sem a variedade de aparelhos e conexões que existem fora do teste controlado.

Use o Lighthouse para diagnosticar um problema e testar uma correção antes do deploy. Use o relatório de campo, no Search Console ou no PageSpeed Insights, para saber o que o usuário de verdade está sentindo. Os detalhes de cada métrica de campo, com as metas oficiais de cada uma, estão no artigo sobre Core Web Vitals.

Como rodar o Lighthouse localmente e no CI

Rodar o Lighthouse fora do DevTools, num ambiente controlado, evita a variação de bateria fraca, aba em segundo plano ou extensão instalada que distorce o resultado sem relação nenhuma com o código.

1. Instale a CLI com npm install -g lighthouse, ou rode direto via npx lighthouse <url> sem instalar nada de forma permanente.
2. Feche outras abas e extensões do Chrome antes de rodar localmente. Um bloqueador de anúncio ou um gerenciador de senha injeta script na página e pode melhorar ou piorar a nota de forma artificial.
3. Rode contra o build de produção, nunca contra o servidor de desenvolvimento. O modo dev do Next.js carrega HMR e código sem minificar, o que derruba a nota sem refletir o que o usuário final vai receber.
4. Automatize com o Lighthouse CI, rodando a cada pull request contra uma prévia do deploy. Isso pega uma regressão de performance antes que ela chegue à branch principal.
5. Guarde o histórico de notas por página ao longo do tempo. Uma queda repentina logo depois de um deploy específico aponta direto para o commit responsável.

Como interpretar a pontuação sem perseguir 100

A pontuação de performance não é a média simples das métricas. O Lighthouse pesa mais as métricas que mais afetam a percepção de velocidade, como o tempo de bloqueio da thread principal e o LCP, e pesa menos outras, como o First Contentful Paint. Por isso duas páginas com problemas bem diferentes entre si podem chegar à mesma nota final por caminhos completamente diferentes.

Perseguir 100 pontos sem olhar a métrica específica é desperdício de tempo de engenharia. Suponha uma página que já está em 92 pontos, com todas as métricas individuais dentro da meta: o esforço para chegar a 100 tende a valer bem menos do que investigar uma segunda página do mesmo site que está em 60. Abra o relatório completo, veja qual métrica está fora da meta e ataque essa métrica específica, não o número final isolado.

O passo a passo de otimização do LCP, que costuma ser a métrica com mais peso na nota final, está em como otimizar o LCP do seu site.

Erros comuns que distorcem o relatório

Throttling de rede e CPU simulado no laboratório nunca é idêntico à conexão real de cada usuário que visita o site. Trate a nota como direção, não como valor absoluto. Suponha uma queda de 15 pontos entre duas execuções seguidas da mesma página, sem nenhuma mudança de código no meio: isso geralmente é ruído do ambiente de teste, não uma regressão real que precise de correção.

Rodar o teste numa máquina com pouca memória livre, com o DevTools aberto ao lado ou logo depois de abrir o notebook do zero introduz variação que não tem relação nenhuma com o código da aplicação. Rode a auditoria pelo menos três vezes seguidas e compare a mediana das notas, nunca a primeira execução isolada.

Outro erro frequente é testar só a página inicial. Uma página de produto, com mais imagem e mais script de terceiro como pixel de conversão e chat de atendimento, costuma ter uma nota bem diferente da home. E é geralmente essa página interna onde a receita do negócio depende de verdade da performance.

Se sua aplicação nunca passou por uma auditoria de Lighthouse guiada e você quer saber exatamente o que está pesando na nota, fale com a gente.