Lighthouse: como medir a velocidade de um site e encontrar melhorias

O Lighthouse é uma ferramenta de auditoria automatizada que identifica problemas e possíveis melhorias no desempenho, acessibilidade, boas práticas e otimização para mecanismos de busca (SEO) de uma página da web. Analise o carregamento de uma página no Chrome DevTools, rastreie uma métrica lenta até as requisições, arquivos ou tarefas de execução envolvidas, altere uma coisa e meça novamente sob as mesmas condições. Uma única pontuação não representa a experiência de todos os visitantes nem determina a classificação de uma página nos resultados de busca.

Lighthouse e PageSpeed Insights: qual é a diferença?

A visão geral oficial do Lighthouse explica como executar auditorias pelo Chrome DevTools, pela linha de comando ou por um módulo Node. Iniciantes podem começar com o painel incluído no Chrome para computador, sem instalar uma extensão. Esse caminho também é útil para páginas com sessão iniciada ou páginas de desenvolvimento local.

A documentação do PageSpeed Insights distingue dados de laboratório de dados de campo. Dados de laboratório são um diagnóstico do Lighthouse gerado sob condições específicas. Dados de experiência de usuários reais vêm do Relatório de Experiência do Usuário do Chrome (CrUX), abrangendo o período de coleta dos últimos 28 dias. Se uma página tiver amostras insuficientes, o serviço pode mostrar dados para a origem (mesmo esquema de URL, host e porta) ou nenhum dado de usuários reais. Ter um resultado de laboratório não significa que as estatísticas de visitantes reais estão disponíveis para essa página em particular.

Para uma verificação rápida de uma URL pública, insira-a no PageSpeed Insights, analise-a e selecione os resultados para dispositivos móveis e desktop separadamente. Para páginas visíveis apenas após login ou URLs locais que não podem ser acessadas externamente, use o DevTools local em vez do serviço externo. Não envie URLs privadas ou tokens de acesso a um serviço de análise externo.

As medições de um relatório descrevem sua URL de destino e as condições de execução. Uma demonstração usando uma URL de exemplo pública não mede o site que publica o guia nem o seu próprio site. Mantenha a seção de experiência do usuário real separada da seção de diagnóstico do Lighthouse ao ler um relatório.

Escolha primeiro a página e as condições de medição

• Alvo: especifique a URL para testar, incluindo artigos representativos, listagens ou páginas de produtos em vez de apenas a página inicial. Não combine diferentes modelos como se fossem resultados de antes e depois para a mesma página.
• Estado: registre se esta é uma visita pela primeira vez ou repetida, o estado de login e como os banners de consentimento são tratados. Para uma página pública que não exige login, um perfil separado ou uma janela anônima pode ajudar a reduzir os efeitos de extensões.
• Ambiente: registre as versões do Chrome e do Lighthouse, a seleção de mobile ou desktop, o método de limitação de rede e CPU e o tempo de medição. Evite executar grandes downloads ou outros trabalhos pesados ao mesmo tempo.
• Armazenamento: Limpar o armazenamento remove os dados do site para aproximar uma visita inicial. Isso pode afetar o estado de login e consentimento, portanto, não habilite casualmente em uma sessão contendo trabalho importante. Ao auditar uma página em que você está logado, escolha configurações que preservem o estado necessário e use-as consistentemente em comparações posteriores.

Auditar enquanto estiver logado como administrador pode carregar scripts, barras de ferramentas e políticas de cache diferentes daqueles usados por um visitante anônimo. Meça a página pública separadamente quando a questão se refere a leitores comuns. Se o alvo for um recurso para usuários logados, registre esse estado explicitamente.

Analise o carregamento de uma página no Chrome DevTools

1. Abra a página no Chrome para desktop. Verifique se o endereço público está correto, por exemplo, e se a página não foi redirecionada para uma tela de erro.
2. Abra o DevTools, por exemplo com F12 ou Ctrl+Shift+I no Windows. Se a aba Lighthouse estiver oculta, encontre-a através do menu de estouro de abas ou Mais ferramentas no menu do DevTools. Os nomes dos menus podem variar conforme o idioma e a versão do navegador.
3. Para uma auditoria inicial de carregamento de página, selecione Navegação em Modo. Escolha Mobile ou Desktop em Dispositivo. O modo Mobile é um teste de laboratório com restrições selecionadas, e não uma reprodução do desempenho de todos os telefones reais.
4. Selecione Desempenho em Categorias, adicionando Acessibilidade, Boas Práticas ou SEO quando necessário. Verifique as configurações de limpeza de armazenamento e limitação de recursos e mantenha seus valores iguais durante as comparações.
5. Selecione Analisar carregamento da página, ou o botão de início equivalente na sua versão. A página será recarregada, então salve formulários não finalizados ou outro trabalho não salvo antes. Evite interagir com a página durante a análise e aguarde o relatório.
6. Verifique a URL solicitada, URL final, configurações e versões. Salve o relatório como HTML ou JSON, selecionando o formato necessário se o menu de exportação oferecer essa escolha. Relatórios podem conter endereços internos ou informações de diagnóstico, então considere seu conteúdo antes de compartilhar.

Escolha um modo diferente para cenários que não sejam uma auditoria básica de carregamento. A documentação de fluxo de usuário Lighthouse distingue Navegação para uma navegação, Timespan para um período que pode incluir interações, e Snapshot para o estado atual da página. Não compare os resultados de Timespan ou Snapshot como se fossem a pontuação completa de desempenho da Navegação. Considere o Snapshot quando a questão envolver um estado específico, como acessibilidade enquanto um menu está aberto.

Leia as métricas e pistas de diagnóstico antes da pontuação

A explicação do cálculo da pontuação de desempenho descreve uma média ponderada de valores transformados das métricas. Reduzir a quantidade de avisos de diagnóstico não aumenta a pontuação em um valor equivalente. Pontuações de 90 a 100 aparecem como boas, de 50 a 89 como precisando de melhorias e de 0 a 49 como ruins. Essas faixas interpretam uma execução; não definem todos os atrasos aceitáveis para usuários reais.

A documentação TBT define uma tarefa longa como aquela que excede 50 milissegundos, contando o excesso além de 50 milissegundos como tempo de bloqueio. TBT não é a mesma métrica que Interaction to Next Paint (INP), que se refere à capacidade de resposta às interações do usuário. Verifique as métricas Core Web Vitals de usuários reais — LCP, INP e CLS — separadamente nos dados de campo.

Expanda os Insights e diagnósticos do relatório para encontrar os elementos e recursos afetados. Se o elemento LCP for uma imagem na viewport inicial, comece pelo tamanho da transferência e pelo tempo de solicitação. Para grandes deslocamentos de layout, verifique se há espaço reservado para imagens e anúncios. Apenas adiar o carregamento de uma imagem importante da primeira tela ou atrasar todos os scripts da mesma maneira pode prejudicar a exibição ou funcionalidade necessária, então identifique primeiro a causa e o uso.

Para uma investigação mais aprofundada, continue com gravações e Insights no painel de Desempenho, conforme explicado na orientação do Lighthouse e painel de Desempenho do Chrome. Pontuações altas de Acessibilidade ou SEO não certificam conformidade completa com acessibilidade ou altos rankings de busca. O uso do teclado e a qualidade real do conteúdo, entre outras questões fora das verificações automáticas, ainda precisam de revisão.

Altere uma coisa e meça novamente nas mesmas condições

1. Escolha um problema com impacto substancial no usuário e uma causa específica. Para uma imagem muito grande na área visível inicial, por exemplo, primeiro experimente uma imagem adequada ao tamanho exibido.
2. Mantenha os arquivos, configurações e relatórios originais. Faça alterações localmente ou em um ambiente de teste e verifique se os caches servem os novos arquivos após a implantação. Não esconda funcionalidades necessárias nem exiba uma página diferente apenas para a auditoria em busca de uma pontuação mais alta.
3. Repita as medições com o mesmo URL, estado de login, modo do dispositivo e configurações de limitação de rede e CPU. Compare métricas brutas e o intervalo e a mediana das execuções repetidas, em vez de apenas um melhor resultado. Se você escolher cinco execuções por condição, por exemplo, use esse mesmo número tanto antes quanto depois da mudança.
4. Verifique se a métrica alvo melhora e se o layout, botões, formulários e interações do teclado continuam funcionando. Se a mudança não ajudar ou quebrar a funcionalidade, restaure os arquivos e configurações salvos e investigue outra causa.

O guia sobre variabilidade das medições explica que mudanças na rede, no dispositivo, no servidor ou na página podem alterar a pontuação sem mudanças no código. O estado dos anúncios e dos banners de consentimento também integra as condições de comparação. Registre no relatório a data, a URL, as versões das ferramentas, as configurações, as métricas e a alteração realizada. Avalie as métricas dos usuários reais após um período de coleta e uma quantidade de amostras suficientes.

Quando a análise falha ou os resultados diferem substancialmente

Se uma página não carregar, o acesso estiver bloqueado ou os redirecionamentos falharem, verifique a URL final e uma resposta HTTP normal antes de interpretar uma pontuação. Não remova a autenticação para expor uma página privada a um teste externo. Para medição local, verifique as configurações de login e de limpeza de armazenamento. Se extensões puderem estar envolvidas, repita o mesmo alvo em um ambiente com menos influência de extensões.

Uma diferença entre o PageSpeed Insights e a pontuação do seu PC não é automaticamente uma falha. Primeiro compare as versões do Lighthouse, caminhos de acesso ao servidor, configurações de dispositivo e de limitação de rede e CPU, e o estado dos cookies. Não tente fazer as pontuações de mobile e desktop coincidirem; compare as mudanças antes e depois dentro de cada condição e considere as métricas de visitantes reais.