Aguarde...

26 de novembro de 2024

Por que otimizar sua pontuação do Lighthouse não é suficiente para um site rápido

Por que otimizar sua pontuação do Lighthouse não é suficiente para um site rápido

Está se sentindo bem com sua pontuação do Lighthouse de 100%? Você deveria! Mas você também deve saber que está olhando apenas para parte do quadro de desempenho. Aprenda como as pontuações do Lighthouse são medidas de forma diferente de outras ferramentas, o impacto que isso tem na medição de métricas de desempenho e por que você precisa de monitoramento de usuário real para um quadro completo.

Todos nós já tivemos esse momento. Você está otimizando o desempenho de algum site, examinando cada milissegundo que leva para a página atual carregar. Você ativou o Google Lighthouse no DevTools do Chrome porque todo mundo e seus tios o usam para avaliar o desempenho.

Depois de executar seu 151º relatório e concluir todas as melhorias recomendadas, você experimenta o nirvana: uma pontuação de desempenho perfeita de 100%!

Hora de se dar um tapinha nas costas por um trabalho bem feito. Talvez você possa usar isso para conseguir aquele aumento de salário que você estava querendo! Só que, não faça isso — pelo menos não usando o Google Lighthouse como sua única prova. Eu sei que uma pontuação perfeita produz todos os tipos de sentimentos bons. É isso que estamos buscando, afinal!

O Google Lighthouse é apenas uma ferramenta em um kit de ferramentas de desempenho completo. O que ele não é é uma imagem completa de como seu site funciona no mundo real. Claro, podemos obter muitos insights sobre o desempenho de um site e até mesmo identificar problemas que devem ser resolvidos para acelerar as coisas. Mas, novamente, é uma imagem incompleta .

Em que o Google Lighthouse é ótimo

Ouço outros desenvolvedores se gabando de pontuações perfeitas do Lighthouse e vejo as capturas de tela publicadas em todas as redes sociais. Ei, eu mesmo fiz isso na introdução deste artigo!

O Lighthouse pode ser a ferramenta de relatórios de desempenho da web mais amplamente usada. Eu apostaria que sua ubiquidade se deve mais à conveniência do que à qualidade de seus relatórios.

Abra o DevTools, clique na aba Lighthouse e gere o relatório! Há até muitas maneiras de configurar o Lighthouse para medir o desempenho em situações simuladas, como velocidades lentas de conexão de internet ou criar relatórios separados para dispositivos móveis e desktops. É uma ferramenta muito poderosa para algo que vem embutido em um navegador gratuito. Também é embutido na ferramenta PageSpeed ​​Insights do Google !

E é rápido. Execute um relatório no Lighthouse e você receberá algo em cerca de 10-15 segundos. Tente executar relatórios com outras ferramentas e você se verá enchendo seu café, indo ao banheiro e talvez verificando seu e-mail (em ordem variada) enquanto espera pelos resultados. Há um bom motivo para isso, mas tudo o que quero destacar é que o Google Lighthouse é extremamente rápido no que diz respeito a relatórios de desempenho.

Recapitulando: o Lighthouse é ótimo em muitas coisas!

  • É conveniente acessar,
  • Ele fornece uma boa quantidade de configuração para diferentes níveis de solução de problemas,
  • E gera relatórios em tempo recorde.

E o que dizer daquela trilha sonora verde animada, brilhante e adorável — quem não gosta disso?!

OK, esse é o lado positivo dos relatórios do Lighthouse. É justo destacar suas limitações também. Isso não é para dissuadir você ou qualquer outra pessoa de usar o Lighthouse, mas mais um aviso de que sua pontuação pode não refletir perfeitamente a realidade — ou mesmo corresponder às pontuações que você obteria em outras ferramentas, incluindo o próprio PageSpeed ​​Insights do Google .

Não corresponde a usuários “reais”

Nem todos os dados são criados iguais no Capital Web Performance. É importante saber disso porque os dados representam suposições que as ferramentas de relatórios fazem ao avaliar métricas de desempenho.

Os dados nos quais o Lighthouse confia para seus relatórios são chamados de dados simulados . Você já deve ter um palpite sólido sobre o que isso significa: são dados sintéticos . Agora, antes de chutar os joelhos dos dados simulados por não serem dados “reais”, saiba que é por isso que o Lighthouse é super rápido.

Você sabia que existe uma configuração para “acelerar” a velocidade da conexão de internet? Ela simula diferentes condições que reduzem ou aumentam a velocidade da conexão, algo que você configura diretamente no Lighthouse. Por padrão, o Lighthouse coleta dados em uma conexão rápida, mas podemos configurá-lo para algo mais lento para obter insights sobre carregamentos lentos de páginas. Mas cuidado! O Lighthouse então estima a rapidez com que a página teria carregado em uma conexão diferente .

O fundador do DebugBear, Matt Zeunert, descreve como os dados são executados em um ambiente de limitação simulado, explicando como o Lighthouse usa médias “otimistas” e “pessimistas” para tirar conclusões:

“[A limitação simulada] reduz a variabilidade entre os testes. Mas se houver uma única solicitação lenta de bloqueio de renderização que compartilhe uma origem com várias respostas rápidas, o Lighthouse subestimará o tempo de carregamento da página.O Lighthouse faz a média de estimativas otimistas e pessimistas quando não tem certeza de quais nós bloqueiam a renderização. Na prática, as métricas podem estar mais próximas de qualquer uma delas, dependendo de qual gráfico de dependência é mais correto.”

E, novamente, o ambiente é uma configuração, não realidade. É improvável que suas condições limitadas correspondam às velocidades de conexão de um usuário real médio no site, pois eles podem ter uma conexão de rede mais rápida ou executar em uma CPU mais lenta. O que o Lighthouse fornece é mais como um teste “sob demanda” que está imediatamente disponível.

Isso torna os dados simulados ótimos para executar testes rapidamente e sob certas condições artificialmente adoçadas. No entanto, eles sacrificam a precisão ao fazer suposições sobre as velocidades de conexão dos visitantes do site e calculam as médias de uma forma que as divorcia da realidade.

Embora a limitação simulada seja o padrão no Lighthouse, ele também oferece suporte a métodos de limitação mais realistas. Executar esses testes levará mais tempo, mas fornecerá dados mais precisos. A maneira mais fácil de executar o Lighthouse com configurações mais realistas é usar uma ferramenta online como o teste de velocidade do site DebugBear ou o WebPageTest.

Não afeta as pontuações do Core Web Vitals

Esses Core Web Vitals sobre os quais todos falam são as métricas padrão do Google para medir o desempenho. Eles vão além dos simples relatórios “Sua página carregou em X segundos” ao analisar uma série de detalhes mais pertinentes que são diagnósticos de como a página carrega, recursos que podem estar bloqueando outros recursos, interações lentas do usuário e o quanto a página muda de recursos e conteúdo de carregamento.

O ponto principal aqui é que os dados simulados que o Lighthouse produz podem (e frequentemente o fazem) diferir das métricas de desempenho de outras ferramentas. Passei um bom tempo explicando isso em outro artigo. O ponto principal é que as pontuações do Lighthouse não impactam os dados do Core Web Vitals . O motivo para isso é que o Core Web Vitals depende de dados sobre usuários reais extraídos do relatório Chrome User Experience (CrUX) atualizado mensalmente . Embora os dados do CrUX possam ser limitados pela data em que os dados foram extraídos, eles são um reflexo mais preciso dos comportamentos do usuário e das condições de navegação do que os dados simulados no Lighthouse.

O ponto final que quero chegar é que o Lighthouse é simplesmente ineficaz em medir métricas de desempenho do Core Web Vitals. Aqui está como eu explico isso no meu artigo personalizado:

“[Os] dados sintéticos são fundamentalmente limitados pelo fato de que 

eles só olham para uma única experiência em um ambiente pré-definido . Esse ambiente muitas vezes nem mesmo corresponde ao usuário real médio no site, que pode ter uma conexão de rede mais rápida ou uma CPU mais lenta.”

Enfatizei a parte importante. Na vida real, os usuários provavelmente terão mais de uma experiência em uma página específica. Não é como se você navegasse até um site, deixasse ele carregar, ficasse lá e então fechasse a página; é mais provável que você faça algo naquela página. E para uma métrica Core Web Vital que procura pintura lenta em resposta à entrada do usuário — ou seja, Interação com a Próxima Pintura (INP) — não há como o Lighthouse medir isso!

É o mesmo acordo para uma métrica como Cumulative Layout Shift (CLS) que mede a “estabilidade visível” de um layout de página porque as mudanças de layout geralmente acontecem mais abaixo na página depois que um usuário rola para baixo. Se o Lighthouse dependesse de dados do CrUX (o que não acontece), ele seria capaz de fazer suposições com base em usuários reais que interagem com a página e podem experimentar o CLS. Em vez disso, o Lighthouse espera pacientemente pelo carregamento completo da página e nunca interage com partes da página, não tendo, portanto, como saber nada sobre o CLS.

Mas ainda é um “bom começo”

É isso que eu quero que você leve no final do dia. Um relatório do Lighthouse é incrivelmente bom em produzir relatórios rapidamente, graças aos dados simulados que ele usa. Nesse sentido, eu diria que o Lighthouse é um prático “gut check” e talvez até mesmo um primeiro passo para identificar oportunidades de otimizar o desempenho.

Mas uma imagem completa, não é. Para isso, o que queremos é uma ferramenta que se apoie em dados reais do usuário. Ferramentas que integram dados CrUX são muito boas nisso. Mas, novamente, esses dados são extraídos todo mês (28 dias para ser exato), então eles podem não refletir os comportamentos e interações mais recentes do usuário, embora sejam atualizados diariamente em uma base contínua e seja realmente possível consultar registros históricos para tamanhos de amostra maiores.

Melhor ainda é usar uma ferramenta que monitora os usuários em tempo real.

Dados extraídos diretamente do site de origem são realmente os dados padrão ouro que queremos porque vêm da fonte da verdade. Isso torna as ferramentas que se integram ao seu site a melhor maneira de obter insights e diagnosticar problemas porque elas dizem exatamente como seus visitantes estão vivenciando seu site.

Eu escrevi sobre usar a Performance API em JavaScript para avaliar métricas personalizadas e Core Web Vitals, então é possível fazer isso por conta própria. Mas há muitos serviços existentes por aí que fazem isso para você, completos com visualizações, registros históricos e monitoramento de usuário em tempo real (geralmente abreviado como RUM). Quais serviços? Bem, o DebugBear é um ótimo lugar para começar. Eu citei Matt Zeunert anteriormente, e o DebugBear é seu produto.

Então, se o que você quer é uma imagem completa do desempenho do seu site, vá em frente e comece com o Lighthouse. Mas não pare aí porque você está vendo apenas parte da imagem. Você vai querer aumentar suas descobertas e diagnosticar o desempenho com monitoramento de usuário real para a imagem mais completa e precisa.

Postado em BlogTags:
Escreva um comentário