Web Performance

Como ler um relatório do Lighthouse sem entrar em pânico

Um guia prático para entender o que importa na sua auditoria de desempenho — e o que você pode ignorar com segurança

The Wux Webtools Team The Wux Webtools Team 9 min de leitura Assistido por IA, revisado por humanos
Stylized lighthouse beam illuminating a clear path through fog, representing clarity in performance diagnostics
Tabela de conteúdos
  1. A primeira regra: sua pontuação não é o seu site
  2. O que ler primeiro: Core Web Vitals
  3. Oportunidades vs. diagnósticos: saiba a diferença
  4. As auditorias que geralmente você pode ignorar
  5. O que fazer quando tudo está vermelho
  6. Dados de laboratório vs. dados de campo: a checagem de realidade
  7. Quando executar o Lighthouse novamente
  8. As ferramentas que ajudam você a agir sobre as constatações do Lighthouse
  9. Principais conclusões
  10. FAQ
  11. Fontes

A primeira regra: sua pontuação não é o seu site

Abra um relatório do Lighthouse pela primeira vez e você se depara com uma parede de números, caixas codificadas por cores e avisos sobre coisas das quais nunca ouviu falar. A reação natural é entrar em pânico. A pontuação está vermelha. Há dezessete auditorias com falha. Certamente o site está quebrado?

Provavelmente não está. O Lighthouse é uma ferramenta de diagnóstico, não um boletim. A pontuação é um benchmark sintético executado em condições de laboratório — muitas vezes em uma conexão limitada, simulando um telefone intermediário de 2017. Ela mostra como seu site se comporta nesse cenário específico, não como usuários reais o experimentam no mundo real.

Isso importa porque a maioria das equipes se fixa na pontuação e perde o contexto. Uma pontuação de 65 pode ser adequada para uma aplicação web complexa com dados em tempo real. Uma pontuação de 95 ainda pode entregar uma experiência ruim se as coisas erradas estiverem otimizadas. A pontuação é um ponto de partida para investigação, não uma métrica de sucesso.

O que ler primeiro: Core Web Vitals

Ignore a pontuação geral de desempenho. Role até a seção Métricas e observe três números: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) e Interaction to Next Paint (INP). Esses são os Core Web Vitals, e são as únicas métricas de desempenho que o Google usa como sinal de ranqueamento.

  • LCP mede quanto tempo leva para o maior elemento visível ser renderizado. Meta: abaixo de 2,5 segundos. Se estiver acima de 4 segundos, os usuários estão esperando tempo demais para ver conteúdo significativo.
  • CLS mede a estabilidade visual — o quanto a página salta enquanto carrega. Meta: abaixo de 0,1. Se estiver acima de 0,25, os usuários estão clicando acidentalmente no item errado porque os botões se moveram.
  • INP mede a responsividade — quão rapidamente a página reage a cliques, toques e pressionamentos de tecla. Meta: abaixo de 200ms. Se estiver acima de 500ms, o site parece lento.

Essas três métricas se correlacionam com frustrações reais dos usuários. Corrija-as antes de se preocupar com qualquer outra coisa.

Oportunidades vs. diagnósticos: saiba a diferença

O Lighthouse divide suas constatações em duas categorias: Oportunidades e Diagnósticos. Oportunidades são classificadas pela economia de tempo estimada. Diagnósticos são contexto adicional — coisas que podem ser problemas, ou talvez não sejam.

Comece por Oportunidades. Se o Lighthouse diz que "Eliminar recursos que bloqueiam a renderização" poderia economizar 1,2 segundo, isso é uma vitória concreta. Se ele diz que "Reduzir JavaScript não utilizado" poderia economizar 0,1 segundo, provavelmente não vale a refatoração.

Diagnósticos são mais complicados. "Evitar um tamanho excessivo do DOM" parece ruim, mas se seu CLS está bom e seu INP é rápido, um DOM grande talvez não esteja prejudicando ninguém. Diagnósticos são pistas, não obrigações. Investigue aqueles que se alinham às suas métricas reais.

As auditorias que geralmente você pode ignorar

Alguns avisos do Lighthouse são vestigiais ou agressivos demais. Aqui estão os que causam mais pânico desnecessário:

  • "Não usa listeners passivos para melhorar o desempenho de rolagem" — Esta é uma micro-otimização que raramente muda o resultado. A menos que você tenha evidências de rolagem travada, ignore.
  • "Elementos de imagem não têm width e height explícitos" — Isso importa para o CLS, mas apenas se as imagens estiverem causando mudanças de layout. Se seu CLS já está bom, não refatore apenas por causa da auditoria.
  • "Servir imagens em formatos de última geração" — Sim, WebP e AVIF são menores. Mas se suas imagens já estão otimizadas e seu LCP é rápido, isso é desejável, não uma crise.
  • "Evitar payloads de rede enormes" — O Lighthouse sinaliza qualquer coisa acima de 1,6 MB. Mas uma página de 2 MB que carrega rápido é melhor do que uma página de 500 KB que bloqueia a renderização. Foque em como os bytes são entregues, não apenas no total.

O que fazer quando tudo está vermelho

Se sua pontuação no Lighthouse está abaixo de 50 e a maioria das auditorias está falhando, você provavelmente está lidando com uma de três causas raiz:

  1. Fontes não otimizadas. Web fonts ainda são a vitória de desempenho mais fácil na maioria dos sites. Verifique se você está carregando seis pesos de fonte quando usa apenas dois, ou enviando arquivos WOFF em vez de WOFF2.
  2. CSS e JavaScript que bloqueiam a renderização. Se seu First Contentful Paint (FCP) está acima de 3 segundos, algo está impedindo o navegador de pintar. Procure arquivos CSS grandes ou scripts síncronos no <head>.
  3. Imagens grandes demais. Se o elemento LCP é uma imagem e ela tem 4 MB, esse é o seu problema. Comprima-a, aplique lazy-load em imagens abaixo da dobra e use sintaxe de imagem responsiva.

Corrija uma dessas coisas e execute o Lighthouse novamente. Muitas vezes você verá um salto de 20 a 30 pontos. Depois, ataque a próxima.

Dados de laboratório vs. dados de campo: a checagem de realidade

O Lighthouse roda em laboratório. Ele simula uma conexão lenta e um dispositivo lento, mas não consegue simular o comportamento real dos usuários — como as pessoas rolam, no que clicam, se estão em um Wi-Fi instável.

Para uma checagem de realidade, compare seus resultados do Lighthouse com dados de campo do Chrome User Experience Report (CrUX). O CrUX mostra como usuários reais do Chrome experienciam seu site nos últimos 28 dias. Se o Lighthouse diz que seu LCP é de 4 segundos, mas o CrUX mostra 2 segundos, confie no CrUX. Se ambos estão ruins, você tem um problema real.

Você pode encontrar dados do CrUX no PageSpeed Insights (a versão web do Lighthouse) ou no Google Search Console em "Core Web Vitals". Se houver divergência, investigue o motivo. Talvez seus usuários reais estejam em redes mais rápidas. Talvez o Lighthouse esteja testando um build de desenvolvimento não otimizado.

Quando executar o Lighthouse novamente

O Lighthouse é ruidoso. Execute-o três vezes seguidas e você obterá três pontuações diferentes, mesmo na mesma página. Isso acontece porque o desempenho é variável — processos em segundo plano, jitter de rede e heurísticas do navegador afetam o resultado.

Para obter uma linha de base estável, execute o Lighthouse em modo anônimo com todas as extensões desativadas, ou use a CLI com a flag --preset=desktop para resultados mais consistentes. Execute três vezes e faça a média das pontuações. Se você estiver vendo oscilações grandes (mais de 10 pontos), há algo errado — talvez o servidor esteja lento, ou a página esteja carregando recursos diferentes a cada vez.

Execute o Lighthouse novamente após cada mudança significativa. Implantou uma nova estratégia de fontes? Verifique o LCP. Aplicou lazy-load em imagens? Verifique o CLS. Adicionou um script de terceiros? Verifique o INP. Desempenho não é uma correção pontual; é um orçamento que você defende.

As ferramentas que ajudam você a agir sobre as constatações do Lighthouse

O Lighthouse diz o que está lento. Ele nem sempre diz como corrigir. Para isso, você precisa de ferramentas adicionais:

  • WebPageTest oferece uma visualização em filmstrip de como a página carrega, quadro a quadro. Essencial para diagnosticar problemas de LCP e CLS.
  • Painel Performance do Chrome DevTools mostra exatamente qual JavaScript está bloqueando a thread principal. Use-o para encontrar a origem de uma pontuação INP ruim.
  • Ferramentas de compressão de imagens permitem otimizar imagens diretamente no navegador, o que é mais rápido e mais privado do que enviar para um serviço de terceiros. O processamento de imagens no lado do cliente é uma vitória de privacidade porque suas imagens nunca saem da sua máquina.

O Lighthouse é o ponto de partida. Essas ferramentas ajudam você a terminar o trabalho.

Principais conclusões

  • Sua pontuação no Lighthouse é um benchmark de laboratório, não uma medida da experiência de usuários no mundo real. Compare-a com dados de campo do CrUX antes de entrar em pânico.
  • Foque primeiro nos Core Web Vitals (LCP, CLS, INP). Essas são as métricas que se correlacionam com a frustração do usuário e com impacto em SEO.
  • Priorize Oportunidades pela economia de tempo estimada. Ignore Diagnósticos que não se alinham aos seus problemas reais de desempenho.
  • Algumas auditorias — como listeners passivos ou formatos de imagem de última geração — são micro-otimizações. Corrija as coisas grandes primeiro.
  • Execute o Lighthouse três vezes e faça a média dos resultados. O desempenho é variável, e uma única execução pode ser enganosa.

FAQ

Q: Por que minha pontuação no Lighthouse muda toda vez que eu o executo?
A: O Lighthouse mede desempenho sob condições variáveis — velocidade da rede, carga da CPU e heurísticas do navegador afetam o resultado. Execute-o três vezes em modo anônimo e faça a média das pontuações para uma linha de base mais estável.

Q: Devo otimizar primeiro para mobile ou desktop?
A: Mobile. O Lighthouse usa por padrão uma simulação mobile porque a maior parte do tráfego web é mobile, e dispositivos mobile são mais lentos. Se sua pontuação mobile estiver boa, sua pontuação desktop geralmente estará bem.

Q: Minha pontuação no Lighthouse é 95, mas meu site ainda parece lento. O que está errado?
A: O Lighthouse mede o carregamento da página, não a interatividade após o carregamento. Verifique sua pontuação INP e use o painel Performance do Chrome DevTools para perfilar o que acontece quando usuários clicam ou rolam. Você pode ter um problema de JavaScript que o Lighthouse não captura.

Q: Preciso de uma pontuação perfeita de 100?
A: Não. Uma pontuação de 90+ é excelente. Perseguir 100 muitas vezes significa otimizar coisas que não importam para os usuários. Foque em métricas reais — LCP, CLS, INP — e ignore a pontuação.

Q: Posso confiar no Lighthouse se uso muitos scripts de terceiros?
A: O Lighthouse sinalizará scripts de terceiros como um problema, mas nem sempre consegue distinguir entre os necessários e os desnecessários. Use as auditorias "Evitar payloads de rede enormes" e "Reduzir tempo de execução de JavaScript" para identificar os piores infratores; depois decida se vale a pena mantê-los.

Fontes

Flowchart for reading a Lighthouse report: ignore score first, check LCP CLS INP, review Opportunities by time savings, then use Diagnostics as context
InfographicHow to triage a Lighthouse report — A simple order of operations turns a scary report into a short prioritized checklist
Two-column comparison of Lighthouse items to prioritize versus warnings that can often wait, with examples and numeric thresholds
InfographicLighthouse signals: fix now vs usually ignore — Not every red warning deserves engineering time
Side-by-side diagram comparing Lighthouse lab data and CrUX field data, including 28-day real-user window and example LCP mismatch
InfographicLab data vs field data at a glance — Use lab data to diagnose and field data to confirm what users really feel

Perguntas frequentes

Por que minha pontuação no Lighthouse muda toda vez que eu o executo?
O Lighthouse mede desempenho sob condições variáveis — velocidade da rede, carga da CPU e heurísticas do navegador afetam o resultado. Execute-o três vezes em modo anônimo e faça a média das pontuações para uma linha de base mais estável.
Devo otimizar primeiro para mobile ou desktop?
Mobile. O Lighthouse usa por padrão uma simulação mobile porque a maior parte do tráfego web é mobile, e dispositivos mobile são mais lentos. Se sua pontuação mobile estiver boa, sua pontuação desktop geralmente estará bem.
Minha pontuação no Lighthouse é 95, mas meu site ainda parece lento. O que está errado?
O Lighthouse mede o carregamento da página, não a interatividade após o carregamento. Verifique sua pontuação INP e use o painel Performance do Chrome DevTools para perfilar o que acontece quando usuários clicam ou rolam. Você pode ter um problema de JavaScript que o Lighthouse não captura.
Preciso de uma pontuação perfeita de 100?
Não. Uma pontuação de 90+ é excelente. Perseguir 100 muitas vezes significa otimizar coisas que não importam para os usuários. Foque em métricas reais — LCP, CLS, INP — e ignore a pontuação.
Posso confiar no Lighthouse se uso muitos scripts de terceiros?
O Lighthouse sinalizará scripts de terceiros como um problema, mas nem sempre consegue distinguir entre os necessários e os desnecessários. Use as auditorias "Evitar payloads de rede enormes" e "Reduzir tempo de execução de JavaScript" para identificar os piores infratores; depois decida se vale a pena mantê-los.

Fontes e leituras adicionais

  1. Lighthouse performance scoring — Google Developers
  2. Core Web Vitals — web.dev
  3. Chrome User Experience Report — Google Developers
  4. WebPageTest Documentation — WebPageTest.org
Sobre o autor
The Wux Webtools Team

Última atualização:

Continue lendo