Google Lighthouse para SEO

TL;DR — Lighthouse é uma ferramenta gratuita do Google que avalia uma página da web de 0 a 100 em aspectos como velocidade e acessibilidade. Ela executa a página em um “laboratório” desacelerado — um celular lento simulado em uma rede lenta — então a pontuação costuma ser menor do que o seu site parece. É uma ótima lista de tarefas para melhorias, mas uma pontuação alta não faz você subir no ranqueamento do Google.

O que é o Lighthouse

O Google Lighthouse é uma ferramenta gratuita e de código aberto da equipe por trás do Chrome. Você aponta para uma URL, ele executa uma série de verificações na página e entrega um boletim com pontuações em quatro áreas: Performance (a rapidez com que a página carrega), Acessibilidade (pessoas com deficiência conseguem usá-la), Boas Práticas (higiene geral da web) e SEO (verificações básicas de compatibilidade com buscas).

Cada pontuação varia de 0 a 100, com faixas de cores para você saber rapidamente como foi:

• 0–49 é vermelho — ruim
• 50–89 é laranja — precisa melhorar
• 90–100 é verde — bom

A primeira coisa que você precisa entender

O Lighthouse testa sua página em condições falsas e desaceleradas — aproximadamente um celular de gama média em uma conexão 4G lenta. Ele faz isso de propósito, para conseguir detectar problemas que usuários reais em dispositivos mais lentos sentiriam.

É por isso que você pode executar o Lighthouse em um site que carrega instantaneamente no seu notebook rápido e ainda ver uma pontuação de Performance de 55. Você não está vendo o que você experimenta — está vendo o que um celular barato em uma rede mediana experimentaria. Informação útil, mas não é a mesma coisa.

Lighthouse não é PageSpeed Insights (exatamente)

Você provavelmente já viu o Lighthouse sem saber. Quando você executa uma página no PageSpeed Insights (a ferramenta web em pagespeed.web.dev), as pontuações de “laboratório” que ele mostra são do Lighthouse. O PageSpeed Insights apenas envolve o Lighthouse e adiciona um segundo conjunto de números de usuários reais (chamados de dados de campo, ou Chrome UX Report). Mais sobre essa distinção na versão Avançada.

O grande mito para abandonar

Uma pontuação perfeita no Lighthouse não significa topo do ranqueamento. O Lighthouse é uma ferramenta útil para encontrar o que corrigir, mas a pontuação em si não é o que o Google usa para ranquear você. Os números de performance que o Google realmente considera para o ranqueamento vêm de usuários reais, não do laboratório do Lighthouse. Buscar 100 é ótimo para seus visitantes — só não espere que seja um código de trapaça para o ranqueamento.

Quer os pesos das métricas, por que as pontuações variam entre execuções e exatamente como o Lighthouse se relaciona com o Core Web Vitals? Mude para a aba Avançado.

TL;DR — Lighthouse é uma ferramenta automatizada de código aberto que audita uma página em condições de laboratório (4G lento simulado + throttle de CPU 4×) e pontua Performance, Acessibilidade, Boas Práticas e SEO — PWA foi removido no Lighthouse 12. A pontuação de Performance é uma média ponderada de cinco métricas de laboratório: TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. Faixas: 0–49 vermelho, 50–89 laranja, 90–100 verde. São dados de laboratório, então não é o sinal de ranqueamento do Core Web Vitals, não pode medir INP como o campo faz (usa TBT como proxy) e varia entre execuções. Ele alimenta a metade de laboratório do PageSpeed Insights; o PSI adiciona dados de campo do CrUX por cima. Um 100 não compra ranqueamento.

O que o Lighthouse realmente é

A própria descrição do Google é a definição mais clara: “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” (tradução) «Lighthouse é uma ferramenta automatizada de código aberto para ajudar você a melhorar a qualidade das páginas da web.» A mecânica é igualmente simples — “give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page performed.” (tradução) «dê ao Lighthouse uma URL para auditar, ele executa uma série de auditorias na página e então gera um relatório sobre o desempenho da página.»

Ele pontua quatro categorias hoje: Performance, Acessibilidade, Boas Práticas e SEO. Se você leu guias mais antigos que dizem cinco, eles estão desatualizados — a categoria PWA foi removida no Lighthouse 12 (por volta de 2024), seguindo os critérios atualizados de instalabilidade do Chrome. Então, se um post de blog ainda cita uma pontuação PWA, esse é o sinal de que ele é anterior à versão atual.

O enquadramento crucial é uma palavra: lab. O Lighthouse carrega sua página em um ambiente controlado e simulado, não a partir de seus visitantes reais. Esse único fato explica quase toda a confusão que as pessoas têm sobre ele.

Como o Lighthouse funciona — as condições de laboratório

Por padrão, o Lighthouse usa limitação simulada e limita de forma agressiva. Os padrões emulam aproximadamente um dispositivo móvel de médio porte em uma conexão Slow 4G:

• Rede: o preset móvel Slow 4G — cerca de 150 ms de latência e 1,6 Mbps de download / 750 Kbps de upload. O Google descreve isso como emular “the ~85th percentile mobile connection speed even when run on much faster fiber connections.” (tradução) «a velocidade de conexão móvel de aproximadamente 85% dos usuários, mesmo quando o teste é executado em conexões de fibra muito mais rápidas».
• CPU: um multiplicador de CPU constante de 4×, simulando o processador de um telefone de médio porte em seu hardware de desktop mais rápido.

Isso é por design. O Lighthouse não está tentando dizer “é assim que seu site é rápido para todos.” Ele está testando a página contra um grupo mais lento que a média para que problemas apareçam que seu laptop rápido esconde. É por isso que um site que parece instantâneo para você pode pontuar 60 — você é um MacBook de alto desempenho em fibra; o teste é um Android barato em uma rede mediana.

Uma nuance que vale a pena manter em mente: a limitação simulada (o padrão) não é a mesma que a limitação DevTools / aplicada. A limitação simulada modela como a página teria carregado sob essas condições com base em uma observação inicial sem limitação — o Google observa que essa abordagem é “both very fast and deterministic.” (tradução) «muito rápida e determinística». A limitação estilo DevTools realmente desacelera as solicitações, o que o Google diz que é “not a sufficient model of a slow connection.” (tradução) «não é um modelo suficiente de uma conexão lenta». Para medição repetível, o modo simulado padrão é preferido.

A pontuação de Performance — como é calculada

A pontuação de Performance é “a weighted average of the metric scores.” (tradução) «uma média ponderada das pontuações das métricas.» Esses pesos foram definidos no Lighthouse 10 e permanecem como a tabela publicada atual. Lighthouse 13 (implementado em 2026) diz isso explicitamente: ele consolidou um conjunto de auditorias de performance sem pontuação em “Insights” compartilhados também usados pelo painel de Performance do DevTools, mas afirma que “no changes to the performance scoring” (tradução) «não houve mudanças na pontuação de performance» nessa versão — a pontuação é baseada nas métricas abaixo, não nos nomes das auditorias, e elas não mudaram. Cinco métricas compõem a pontuação:

Algumas coisas para internalizar aqui:

• TBT tem o maior peso (30%). É o proxy de laboratório para responsividade. First Input Delay (FID) não existe mais, e métricas mais antigas como Time to Interactive e First Meaningful Paint também foram aposentadas.
• Speed Index é uma métrica do Lighthouse, não um Core Web Vital. Ela ainda conta para 10% da pontuação de Performance do Lighthouse, mesmo não sendo um dos CWV relevantes para ranqueamento do Google.
• Cada métrica é pontuada contra uma curva, não um corte fixo. O Lighthouse pega o valor bruto (geralmente em milissegundos) e o mapeia em uma distribuição log-normal construída a partir de dados reais do HTTP Archive. Os pontos de controle do Google: o 25º percentil desses dados atinge uma pontuação de 50, e o 8º percentil atinge 90. Então, 90+ significa que você está aproximadamente no topo ~8% das páginas nessa métrica — é por isso que os últimos pontos são tão difíceis de ganhar.
• Apenas as pontuações das métricas movem o número. As seções Oportunidades e Diagnósticos do relatório são orientações — elas dizem o que corrigir — mas não mudam diretamente a pontuação de Performance. Corrigi-las melhora as métricas, e as métricas movem a pontuação.

Por que sua pontuação muda entre execuções

Esta é a reclamação que mais ouço: “Executei duas vezes e obtive 84 e depois 91 — está quebrado?” Não. O Google é explícito: “A lot of the variability in your overall Performance score and metric values is not due to Lighthouse.” (tradução) «Grande parte da variabilidade da sua pontuação geral de Performance e dos valores das métricas não se deve ao Lighthouse.» Quando o número salta, geralmente são as condições subjacentes que estão mudando:

• Testes A/B ou anúncios diferentes sendo exibidos em cada carregamento
• Mudanças no roteamento da internet — tanto na sua rede local quanto no caminho mais longo entre regiões que uma solicitação percorre
• O próprio servidor web respondendo em velocidades inconsistentes
• Testes em hardwares diferentes (um desktop rápido vs. um laptop cansado) — a limitação de CPU é relativa à máquina host, então um multiplicador “4×” significa algo diferente em uma máquina rápida do que em uma lenta
• Extensões do navegador que injetam JavaScript ou solicitações de rede extras
• Software antivírus ou outros processos em segundo plano competindo por recursos

Por exemplo: execute a mesma URL duas vezes e uma passagem carrega um criativo de anúncio mais pesado ou pega uma resposta mais lenta do servidor — as auditorias dessa execução refletem esse único carregamento, não um defeito que você introduziu. Trate como uma amostra única, não como um veredito.

O modelo mental correto, direto da documentação, é tratar a performance como uma distribuição de pontuações, em vez de um número único. Execute algumas vezes — idealmente em uma janela anônima com extensões desativadas, em hardware e condições de rede combinados — e observe o intervalo ou a mediana, não um único resultado. Quando precisar comparar execuções depois, anote a versão do Lighthouse, o modo de execução e o método de limitação ao lado da pontuação; uma pontuação de uma versão ou configuração diferente não é uma comparação justa, mesmo que o número pareça semelhante.

Como executar o Lighthouse de forma responsável

Use o Lighthouse como um diagnóstico controlado, não um veredito de um clique:

1. Teste a URL exata implantada, não um modelo diferente ou uma compilação local não publicada.
2. Combine o perfil do dispositivo, o método de limitação, a versão do Lighthouse, o estado do cache, a autenticação, o estado de consentimento e a geografia do teste para cada comparação.
3. Comece cada execução com uma navegação nova. Redimensionar uma página de desktop já carregada para um viewport móvel não reproduz uma navegação móvel, a sequência de solicitações, ou a resposta do servidor.
4. Execute pelo menos três vezes. Relate a mediana como o resultado principal e mantenha as execuções individuais, o intervalo, os carimbos de data/hora, os avisos e os traces para que um valor atípico seja visível em vez de descartado silenciosamente.
5. Compare antes e depois sob as mesmas condições. Se o serviço de teste for executado de outra região, registre isso: a distância de rede adicionada ou uma borda de CDN diferente pode alterar os tempos de servidor e carregamento sem uma mudança de código.
6. Verifique o CrUX separadamente antes de fazer uma afirmação sobre usuários reais. Uma mediana de laboratório melhor suporta “esta mudança melhorou este teste controlado”, não “os usuários agora passam no Core Web Vitals”.

As evidências suportam conclusões diferentes:

Isso segue o próprio modelo baseado em distribuição do Lighthouse para variabilidade de pontuação e mantém a distinção laboratório/campo intacta. Evidence for this claim Lighthouse performance scores are weighted from lab metrics; 90–100 is good, 50–89 needs improvement, and 0–49 is poor. Scope: Current published Lighthouse performance-scoring model; metric weights can change by Lighthouse version. Confidence: high · Verified: 2026-07-14 Chrome Developers: Performance scoring

Lighthouse vs. PageSpeed Insights — a distinção que importa

Esses são confundidos constantemente, então seja preciso:

• Lighthouse é o motor. Ele produz dados de laboratório — as pontuações de Performance, Acessibilidade, Boas Práticas e SEO.
• PageSpeed Insights é uma interface web que executa o Lighthouse e adiciona dados de campo do Chrome UX Report (CrUX) — Core Web Vitals reais de usuários reais anônimos, exibidos quando há dados suficientes para a URL ou origem.

Então, no PSI você está vendo dois conjuntos de dados lado a lado. A seção de “dados de campo” no topo (usuários reais, do CrUX) é separada da seção de “dados de laboratório” do Lighthouse abaixo dela — e eles frequentemente discordam. Quando alguém diz “minha pontuação do PageSpeed Insights”, quase sempre se refere à pontuação de Performance do Lighthouse, não aos dados de campo.

Lighthouse e Core Web Vitals — como eles se relacionam

O Lighthouse mede alguns Core Web Vitals no laboratório: ele reporta LCP e CLS como métricas de laboratório. Mas há um limite rígido:

O Lighthouse não consegue medir INP da mesma forma que o campo. Interaction to Next Paint precisa de interações reais de usuários para ser medido — não há usuário real clicando em uma execução de laboratório. Então o Lighthouse usa Total Blocking Time como um proxy de laboratório para responsividade. TBT correlaciona-se com INP, mas um TBT aprovado não garante um INP aprovado para usuários reais. Eles são relacionados, não iguais.

Este é o cerne da lacuna entre laboratório e campo. Os dados de campo — do CrUX, exibidos no Search Console e no topo do PageSpeed Insights — são o que refletem usuários reais e o que alimenta os sinais de experiência de página do Google. Os dados de laboratório do Lighthouse servem para depuração e para detectar regressões antes de você publicar. A orientação do próprio Google é “prioritize field data for understanding real-world user experiences” (tradução) «priorizar dados de campo para entender experiências reais de usuários» e usar “lab data for debugging, testing features before deployment.” (tradução) «dados de laboratório para depuração, testando recursos antes da implantação.»

Onde executar

Mesmo motor, superfícies diferentes:

• Chrome DevTools — integrado ao navegador (o painel Lighthouse). Melhor para páginas atrás de login, pois você pode auditar páginas autenticadas.
• PageSpeed Insights — a interface web sem instalação em pagespeed.web.dev; executa o Lighthouse e adiciona dados de campo do CrUX.
• CLI — npm install -g lighthouse, depois lighthouse <url>; scriptável.
• Módulo Node — importe-o programaticamente em suas próprias ferramentas e CI.
• Lighthouse CI — a configuração oficial para detectar regressões de performance em cada deploy. O fluxo de trabalho é coletar → afirmar → enviar: collect executa o Lighthouse várias vezes contra uma URL (três execuções por padrão) e usa o relatório mediano em vez de confiar em uma única passagem; assert verifica esse relatório contra limites que você configura — defina como warn ou error por categoria ou métrica; upload armazena o relatório para que você possa acompanhar as linhas de tendência ao longo dos builds. Trate os limites como a política de regressão da sua equipe, não como um veredito de dados de campo ou uma garantia de ranqueamento — eles estão detectando “isso piorou”, não certificando “isso é rápido para os usuários”.
• Extensão do Chrome — existe, mas o DevTools é o caminho recomendado no navegador.

Os fluxos de trabalho CLI e Node precisam de uma instalação local do Chrome para funcionar.

Os mitos que valem a pena desmascarar

• “Uma pontuação 100 no Lighthouse = melhores ranqueamentos.” Não. A pontuação de Performance é dado de laboratório; não é um sinal de ranqueamento. Os sinais de experiência de página do Google usam dados de campo dos Core Web Vitals (CrUX), e mesmo isso é um sinal leve entre muitos — relevância e qualidade do conteúdo dominam. Busque uma pontuação forte porque é boa para os usuários, não porque é uma alavanca de ranqueamento.
• “Lighthouse = dados de campo / o que usuários reais experimentam.” Não. São condições de laboratório limitadas, piores do que a maioria dos usuários reais vê. Usuários reais têm caches quentes, bfcache e dispositivos variados. O Lighthouse é um teste de estresse de pior caso, não uma leitura do usuário médio.
• “PageSpeed Insights é o Lighthouse.” Parcialmente. O PSI executa o Lighthouse para a seção de laboratório e adiciona o CrUX para a seção de campo. Os números de campo — os ligados à experiência de página — são do CrUX, não do Lighthouse.
• “A categoria PWA ainda conta.” Não conta. O PWA foi removido como categoria pontuada no Lighthouse 12.

Resumo

O Lighthouse é uma das ferramentas gratuitas mais úteis em SEO técnico e desempenho web — uma forma rápida e repetível de descobrir o que está deixando uma página lenta e de se proteger contra regressões em CI. Apenas mantenha-o na altitude certa: é um diagnóstico de laboratório, não um veredito sobre a experiência do usuário real e não uma pontuação de ranqueamento. Use-o para encontrar e corrigir; use dados de campo (CrUX, Core Web Vitals no Search Console) para julgar se os usuários reais estão realmente tendo uma boa experiência.

Resumo de IA

Uma visão condensada da versão Avançada:

• Lighthouse = ferramenta de auditoria automatizada de laboratório, open-source da equipe do Chrome. Forneça uma URL; ele audita a página e pontua Performance, Acessibilidade, Boas Práticas, SEO. O PWA foi removido no Lighthouse 12 (~2024).
• Laboratório, não campo. Ele carrega a página sob limitação simulada — aproximadamente Slow 4G + 4× CPU — por design, para revelar o que dispositivos/redes mais lentos experimentam. É por isso que um site “rápido” pode pontuar baixo.
• Pontuação de Performance = média ponderada de cinco métricas de laboratório: TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. FID e First Meaningful Paint foram removidos.
• Faixas: 0–49 vermelho (ruim), 50–89 laranja (precisa de melhorias), 90–100 verde (bom). As pontuações das métricas são mapeadas em uma curva log-normal do HTTP Archive, então os pontos mais altos são os mais difíceis. Oportunidades/Diagnósticos orientam correções, mas não mudam diretamente a pontuação.
• As pontuações variam de execução para execução — anúncios, testes A/B, extensões, condições de rede/servidor e carga da máquina (a limitação de CPU é relativa ao host). Trate-as como uma distribuição, não um número único; execute em modo anônimo com extensões desativadas, e registre a versão do Lighthouse e as configurações que você usou.
• Lighthouse CI automatiza isso: ele coleta várias execuções (três por padrão), pega a mediana e verifica os limites da sua equipe — uma política de captura de regressões, não um veredito de dados de campo.
• Lighthouse ≠ PageSpeed Insights: o PSI executa o Lighthouse (laboratório) e adiciona dados de campo do CrUX (usuários reais). Eles frequentemente discordam.
• O Lighthouse mede LCP/CLS em laboratório, mas não consegue medir INP da forma que o campo faz — ele usa TBT como proxy. Os dados de campo (CrUX) são o que refletem os usuários reais e alimentam os sinais de experiência de página.
• Não é um sinal de ranqueamento. Um 100 não significa os melhores ranqueamentos, e uma pontuação baixa de laboratório não significa uma experiência ruim para o usuário real. Use o Lighthouse para depurar; use dados de campo para julgar.

Documentação oficial

Documentação de fonte primária da equipe do Google Chrome.

• Visão geral do Lighthouse — o que é o Lighthouse, as categorias de auditoria e todas as formas de executá-lo (DevTools, CLI, Node, PageSpeed Insights, extensão, Lighthouse CI).
• Pontuação de performance do Lighthouse — os pesos das métricas, as faixas de cores 0–49 / 50–89 / 90–100 e a curva de pontuação log-normal.
• Auditorias PWA do Lighthouse — traz o aviso de descontinuação da categoria PWA removida.
• Limitação do Lighthouse (GitHub) — limitação simulada vs. aplicada, o preset Slow 4G e o multiplicador de 4× CPU.
• Changelog do Lighthouse (GitHub) — as mudanças da v12: remoção do PWA, remoção do First Meaningful Paint, INP elevado.
• Calculadora de pontuação do Lighthouse — insira valores de métricas e veja a pontuação de Performance resultante; útil para definir metas.

Laboratório vs. campo (web.dev)

• Métricas de performance centradas no usuário — por que o teste de laboratório “não é necessariamente reflexo de como os usuários reais experimentam seu site.”

Citações da fonte

Declarações registradas da documentação do Lighthouse do Google. Cada link é um link profundo que salta para a passagem citada na página de origem.

O que é o Lighthouse e como ele funciona

• “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” (tradução) «Lighthouse é uma ferramenta automatizada de código aberto para ajudar você a melhorar a qualidade das páginas da web.» — developer.chrome.com, Lighthouse overview. Ir para a citação
• “Give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page performed.” (tradução) «Dê ao Lighthouse um URL para auditar; ele executa uma série de auditorias na página e então gera um relatório sobre o desempenho da página.» — developer.chrome.com, Lighthouse overview. Ir para a citação

Como funciona a pontuação de Performance

• “The Performance score is a weighted average of the metric scores.” (tradução) «A pontuação de Performance é uma média ponderada das pontuações das métricas.» — developer.chrome.com, Lighthouse performance scoring. Ir para a citação
• “Once Lighthouse has gathered the performance metrics (mostly reported in milliseconds), it converts each raw metric value into a metric score from 0 to 100 by looking where the metric value falls on its Lighthouse scoring distribution.” (tradução) «Depois que o Lighthouse reúne as métricas de performance, em sua maioria relatadas em milissegundos, ele converte cada valor bruto em uma pontuação de 0 a 100 observando onde o valor se enquadra na distribuição de pontuação do Lighthouse.» — developer.chrome.com, Lighthouse performance scoring. Ir para a citação
• Sobre as faixas de pontuação: “0 to 49 (red): Poor” — com 50–89 laranja (precisa de melhorias) e 90–100 verde (bom). (tradução) «0 a 49 (vermelho): ruim». Ir para a citação

Por que as pontuações variam

• “A lot of the variability in your overall Performance score and metric values is not due to Lighthouse. When your Performance score fluctuates it’s usually because of changes in underlying conditions.” (tradução) «Grande parte da variabilidade da sua pontuação geral de Performance e dos valores das métricas não se deve ao Lighthouse. Quando sua pontuação de Performance oscila, geralmente é por causa de mudanças nas condições subjacentes.» — developer.chrome.com, Lighthouse performance scoring. Ir para a citação

Laboratório vs. campo

• “While testing in the lab is a reasonable proxy for performance, it isn’t necessarily reflective of how actual users experience your site.” (tradução) «Embora testar no laboratório seja um proxy razoável de performance, isso não necessariamente reflete como os usuários reais vivenciam seu site.» — web.dev, User-centric performance metrics. Ir para a citação

Obtendo uma leitura confiável do Lighthouse — checklist

Antes de agir com base em uma pontuação do Lighthouse, certifique-se de que o número significa algo:

• Execute-o em uma janela anônima com extensões desativadas (extensões injetam JS e distorcem a pontuação).
• Execute-o várias vezes e observe a variação — trate-a como uma distribuição, não como um número único.
• Confirme que você está comparando o mesmo formato (mobile vs. desktop — a limitação de velocidade difere).
• Saiba qual conjunto de dados você está lendo: lab (Lighthouse) vs. campo (CrUX) no PageSpeed Insights. Não os misture.
• Para questões de ranqueamento/experiência de página, observe os dados de campo (Core Web Vitals no Search Console / CrUX), não a pontuação de laboratório do Lighthouse.
• Lembre-se de que o Lighthouse não consegue medir INP da mesma forma que o campo — TBT é um proxy, não uma garantia.
• Corrija com base nas listas de Oportunidades/Diagnósticos, mas verifique a mudança observando a métrica se mover (apenas métricas alteram a pontuação).
• Para medição repetível em automação, use o Lighthouse CI com orçamentos em vez de avaliar execuções isoladas.
• Controle o que a página mostra ao carregar: banners de cookie/consentimento, estado de login e cache (frio vs. quente) alteram as auditorias que são executadas — escolha um estado e seja consistente com ele.
• Fique atento a conteúdo não determinístico — testes A/B, anúncios rotativos e outros scripts de terceiros podem servir um payload diferente a cada execução e alterar a pontuação independentemente do que você mudou.
• Deixe a página realmente terminar de carregar antes de acionar a auditoria (ou use um modo que aguarde isso) — interromper uma execução cedo interpreta mal a página.
• Registre a versão do Lighthouse e as configurações de execução (modo, método de limitação de velocidade, dispositivo) junto com a pontuação — uma pontuação “igual” de uma versão ou configuração diferente não é realmente comparável.
• Ignore qualquer guia que ainda pontue a categoria PWA — ela foi removida no Lighthouse 12.

Pontuação de desempenho do Lighthouse — resumo rápido

As cinco métricas e seus pesos (ponderação do Lighthouse 10)

Aposentadas / removidas: FID, Time to Interactive, First Meaningful Paint.

Faixas de cores da pontuação

Mapeado em uma curva log-normal do HTTP Archive: ~25º percentil → 50, ~8º percentil → 90. Os últimos pontos são os mais difíceis de conquistar.

Condições padrão de laboratório

• Rede: mobile Slow 4G (~150 ms de latência, ~1,6 Mbps de download / 750 Kbps de upload)
• CPU: multiplicador constante de 4× (mobile de gama média em hardware de desktop)
• Limitação de velocidade: simulada por padrão (rápida, determinística), não aplicada via DevTools

Lighthouse vs. PageSpeed Insights

Fatos rápidos

• Categorias atuais: Performance, Acessibilidade, Boas Práticas, SEO (PWA removido no Lighthouse 12).
• Não é um sinal de ranqueamento. Um 100 ≠ melhores posições.
• Não consegue medir INP como o campo — usa TBT como proxy.
• As pontuações variam de execução para execução — isso é esperado.

Formas de executar o Lighthouse (e ferramentas relacionadas)

• Chrome DevTools — painel Lighthouse — integrado ao Chrome; ideal para auditar páginas atrás de um login.
• PageSpeed Insights (pagespeed.web.dev) — sem instalação; executa o Lighthouse e adiciona dados de campo do CrUX junto.
• Lighthouse CLI — npm install -g lighthouse, depois lighthouse <url>; scriptável, precisa de um Chrome local.
• Módulo Node do Lighthouse — integre-o programaticamente às suas próprias ferramentas.
• Lighthouse CI (@lhci/cli) — execute o Lighthouse a cada deploy, defina orçamentos e faça o build falhar em regressões. A ferramenta certa para evitar que uma pontuação caia silenciosamente.
• Calculadora de pontuação do Lighthouse (scorecalc) — insira valores de métricas para ver a pontuação de Performance resultante e definir metas realistas.
• Extensão do Chrome — disponível, mas o DevTools é o caminho recomendado no navegador.

Para dados de usuários reais (campo) que complementem essas ferramentas de laboratório, veja o relatório Core Web Vitals no Google Search Console e a seção de campo do CrUX no PageSpeed Insights.

Hábitos do Lighthouse que criam falsa confiança

• Buscar 100 como meta de negócio. Uma pontuação perfeita em laboratório não é um aumento de ranqueamento e pode distrair dos Core Web Vitals de campo e dos resultados reais dos usuários. Use o relatório para encontrar gargalos e depois verifique se os usuários se beneficiaram.
• Tratar uma execução como veredito. O Lighthouse é um teste simulado e varia naturalmente. Execute-o várias vezes nas mesmas condições e procure um padrão consistente em vez de reagir a uma única pontuação.
• Chamar o TBT de laboratório de INP de campo. O TBT é um proxy de laboratório útil para bloqueio do thread principal; o INP mede interações reais em campo. Um bom TBT é evidência, não prova, de que o INP é bom.
• Corrigir todas as auditorias na ordem listada. As estimativas de oportunidade se sobrepõem, e algumas auditorias têm pouco impacto no gargalo real da página. Comece pelo trace, pelas métricas de maior peso e pelos recursos responsáveis por elas.
• Comparar pontuações de mobile e desktop diretamente. Os perfis de emulação e as distribuições de pontuação diferem. Compare coisas semelhantes.

Mudanças na pontuação do Lighthouse entre execuções

Sintoma: A mesma página muda entre faixas de cor sem um deploy.

Causa provável: Resposta variável do servidor, scripts de terceiros, carga da máquina compartilhada ou configurações de teste diferentes alteraram a execução sintética.

Correção e confirmação: Combine a URL, o perfil de dispositivo, a limitação de rede, o estado do cache e a localização do teste; execute vários testes; depois compare o trace mediano e os tempos das métricas.

Core Web Vitals de campo passam, mas o Lighthouse está vermelho

Sintoma: Os dados de campo do PSI passam enquanto a pontuação de Performance do Lighthouse é ruim.

Causa provável: As duas seções medem populações diferentes: o CrUX resume usuários reais ao longo do tempo, enquanto o Lighthouse executa um carregamento de página simulado.

Correção e confirmação: Trate a avaliação de campo como o resultado do usuário e use o trace de laboratório para reproduzir e diagnosticar um cenário de dispositivo lento. Confirme qualquer correção tanto em execuções de laboratório repetidas quanto na próxima janela de relatório de dados de campo.

O Lighthouse não consegue medir o INP

Sintoma: O relatório mostra TBT, mas nenhum valor de INP em laboratório.

Causa provável: O INP exige interações reais durante uma visita à página; uma execução do Lighthouse apenas com navegação não tem um histórico de interações representativo.

Correção e confirmação: Use o TBT e o trace para encontrar tarefas longas em laboratório e depois meça o INP com dados de campo ou uma gravação focada em interações.

Uma auditoria persiste após a correção óbvia

Sintoma: O Lighthouse ainda sinaliza um recurso depois que ele foi otimizado ou removido.

Causa provável: Uma resposta em cache, outro template, uma cópia de terceiros ou uma solicitação diferente na cadeia ainda aciona a auditoria.

Correção e confirmação: Teste a URL exata publicada com cache frio, abra a lista de recursos afetados da auditoria e mapeie cada solicitação listada de volta ao seu dono.

Teste-se: Google Lighthouse

Cinco perguntas rápidas sobre dados e pontuação do Lighthouse. Escolha uma resposta para cada uma e depois confira.

Recursos que valem seu tempo

Oficial

• Visão geral do Lighthouse — o definitivo o quê/como/onde executar.
• Pontuação de desempenho do Lighthouse — pesos, faixas e a curva de pontuação.
• Documentação de throttling do Lighthouse (GitHub) — as condições de laboratório em detalhes.
• Calculadora de pontuação do Lighthouse — engenharia reversa das metas de métricas para uma pontuação.
• Métricas de desempenho centradas no usuário — o argumento laboratório vs. usuários reais, da Google.

Onde o Lighthouse se encaixa

• Combine a pontuação de laboratório com dados de campo: o relatório Core Web Vitals no Google Search Console e a seção CrUX do PageSpeed Insights. O laboratório encontra os problemas; o campo diz se os usuários reais os sentem.

Da indústria

• Diferenças entre dados de campo e dados de laboratório (web.dev) — a própria análise da Google sobre quando confiar em números de laboratório vs. campo e por que eles divergem.
• Core Web Vitals (web.dev) — a referência canônica sobre quais métricas CWV o Lighthouse pode e não pode medir, incluindo a lacuna do INP.
• Largest Contentful Paint (web.dev) — mergulho profundo nos limites de LCP e por que leituras de laboratório e campo frequentemente discordam.
• Lighthouse CI no GitHub — repositório oficial e guia de configuração para integrar o Lighthouse em pipelines automatizados de CI/CD.
• HTTP Archive Web Almanac — capítulo de desempenho — dados anuais sobre pontuações reais do Lighthouse e taxas de aprovação do Core Web Vitals em milhões de páginas; útil para comparar suas pontuações com a web em geral.
• web.dev — Meça o desempenho da página — o ponto de partida recomendado pela Google para combinar resultados do Lighthouse com ferramentas de dados de campo.

Números que valem a pena citar

• Pesos da pontuação de desempenho (Lighthouse 10): TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. Fonte
• Faixas de pontuação: 0–49 vermelho (ruim), 50–89 laranja (precisa de melhorias), 90–100 verde (bom). Um 90 corresponde aproximadamente ao 8º percentil dos dados do HTTP Archive; um 50 ao 25º percentil. Fonte
• Throttling padrão: mobile Slow 4G (~150 ms de latência, ~1,6 Mbps de download) mais um multiplicador de CPU 4× — emulando aproximadamente a conexão móvel do ~85º percentil. Fonte
• Categorias: quatro hoje (Performance, Acessibilidade, Boas Práticas, SEO) — PWA removido no Lighthouse 12 (~2024). Fonte

Registro de alterações