Novidades do Lighthouse 6.0

Novas métricas, atualização da pontuação de desempenho, novas auditorias e muito mais.

Connor Clark

Hoje estamos lançando o Lighthouse 6.0.

O Lighthouse é uma ferramenta automatizada de auditoria de sites que ajuda os desenvolvedores com oportunidades e diagnósticos para melhorar a experiência do usuário nos sites. Ela está disponível no Chrome DevTools, npm (como um módulo do Node e CLI) ou como uma extensão do navegador (no Chrome e no Firefox). Ela é usada em muitos serviços do Google, incluindo o web.dev/measure e o PageSpeed Insights.

O Lighthouse 6.0 está disponível imediatamente no npm e no Chrome Canary. Outros serviços do Google que usam o Lighthouse vão receber a atualização até o fim do mês. Ela será lançada no Chrome Stable no Chrome 84 (meados de julho).

Para testar a CLI do Node do Lighthouse, use os seguintes comandos: bash npm install -g lighthouse lighthouse https://www.example.com --view

Esta versão do Lighthouse vem com um grande número de alterações que estão listadas no registro de alterações 6.0. Vamos abordar os destaques neste artigo.

• Novas métricas
• Atualização da pontuação de performance
• Novas auditorias
• Lighthouse CI
• Painel do Chrome DevTools renomeado
• Emulação de dispositivos móveis
• Extensão do navegador
• Orçamentos
• Links do local de origem
• No horizonte
• Até a próxima!

Novas métricas

O Lighthouse 6.0 introduz três novas métricas no relatório. Duas dessas novas métricas, a Largest Contentful Paint (LCP) e a Cumulative Layout Shift (CLS), são implementações de laboratório das Core Web vitals.

Maior exibição de conteúdo (LCP)

A Maior exibição de conteúdo (LCP, na sigla em inglês) é uma medida da experiência de carregamento percebida. Ele marca o ponto durante o carregamento da página em que o conteúdo principal (ou "maior") foi carregado e está visível para o usuário. A LCP é um complemento importante à primeira exibição de conteúdo (FCP, na sigla em inglês), que captura apenas o início da experiência de carregamento. A LCP mostra aos desenvolvedores a rapidez com que um usuário consegue ver o conteúdo de uma página. Uma pontuação de LCP abaixo de 2,5 segundos é considerada "Boa".

Para mais informações, assista esta análise detalhada sobre a LCP de Paul Ireland.

Cumulative Layout Shift (CLS)

A Mudança de layout cumulativa (CLS) é uma medida de estabilidade visual. Quantifica quanto o conteúdo de uma página muda visualmente. Uma pontuação de CLS baixa é um sinal para os desenvolvedores de que os usuários não estão enfrentando mudanças de conteúdo indevidas.Uma pontuação de CLS abaixo de 0,10 é considerada "Bom".

A CLS em um ambiente de laboratório é medida até o fim do carregamento de página. Já no campo, é possível medir a CLS até a primeira interação do usuário ou incluir todas as entradas dele.

Para mais informações, assista esta análise detalhada sobre CLS, de Annie Sullivan.

Tempo total de bloqueio (TBT)

O Tempo total de bloqueio (TBT, na sigla em inglês) quantifica a capacidade de resposta do carregamento, medindo o tempo total em que a linha de execução principal ficou bloqueada por tempo suficiente para evitar a capacidade de resposta da entrada. O TBT mede o tempo total entre a primeira exibição de conteúdo (FCP) e o tempo até a interação (TTI, na sigla em inglês). É uma métrica complementar para TTI e traz mais nuances para a quantificação da atividade da linha de execução principal, que bloqueia a capacidade de um usuário de interagir com sua página.

Além disso, o TBT tem boa correlação com a métrica de campo Latência na primeira entrada (FID, na sigla em inglês), que é uma Core Web Vitals.

Atualização da pontuação de desempenho

A pontuação de desempenho no Lighthouse é calculada com base em uma combinação ponderada de várias métricas para resumir a velocidade de uma página. A fórmula de pontuação de desempenho 6.0 é a seguinte.

Fase	Nome da métrica	Ponderação métrica
Adiantado (15%)	First Contentful Paint (FCP)	15%
Médio (40%)	Índice de velocidade (SI)	15%
	Maior exibição de conteúdo (LCP)	25%
Atrasados (15%)	Tempo para interação da página (TTI, na sigla em inglês)	15%
Linha de execução principal (25%)	Tempo total de bloqueio (TBT)	25%
Previsibilidade (5%)	Cumulative Layout Shift (CLS)	5%

Embora três novas métricas tenham sido adicionadas, três antigas foram removidas: primeira exibição significativa, primeira CPU inativa e FID de potencial máximo. Os pesos das métricas restantes foram modificados para enfatizar a interatividade da linha de execução principal e a previsibilidade do layout.

Para fins de comparação, aqui está a pontuação da versão 5:

Fase	Nome da métrica	Weight
Adiantado (23%)	First Contentful Paint (FCP)	23%
Médio (34%)	Índice de velocidade (SI)	27%
	Primeira exibição significativa (FMP, na sigla em inglês)	7%
Concluído (46%)	Tempo para interação da página (TTI, na sigla em inglês)	33%
	Primeira CPU inativa (FCI)	13%
Linha de execução principal	Potencial máximo de FID	0%

Alguns destaques das mudanças de pontuação entre as versões 5 e 6 do Lighthouse:

• O peso da TTI foi reduzido de 33% para 15%. Isso foi uma resposta direta ao feedback dos usuários sobre a variabilidade de TTI, bem como inconsistências nas otimizações de métricas que levaram a melhorias na experiência do usuário. O TTI ainda é um indicador útil para quando uma página é totalmente interativa. No entanto, com TBT como complemento, a variabilidade é reduzida. Com essa mudança na pontuação, esperamos que os desenvolvedores sejam incentivados a otimizar de maneira mais eficaz a interatividade do usuário.
• O peso da FCP foi reduzido de 23% para 15%. Medir apenas quando o primeiro pixel é pintado (FCP, na sigla em inglês) não forneceu uma imagem completa. Combinar isso com a medição do momento em que os usuários podem ver o que é mais importante para eles (LCP) reflete melhor a experiência de carregamento.
• O FID de potencial máximo foi descontinuado. Ele não é mais exibido no relatório, mas ainda está disponível no JSON. Agora, recomendamos analisar o TBT para quantificar sua interatividade em vez do mpFID.
• A primeira exibição significativa foi descontinuada. Essa métrica era muito variante e não tinha um caminho viável para a padronização, já que a implementação é específica para os componentes internos de renderização do Chrome. Embora algumas equipes considerem que o tempo da FMP vale a pena em seu site, a métrica não receberá outras melhorias.
• A primeira CPU inativa foi descontinuada porque não é diferente o suficiente da TTI. TBT e TTI são as métricas mais importantes para interatividade agora.
• O peso da CLS é relativamente baixo, embora seja esperado aumentá-lo em uma versão principal futura.

Mudanças nas pontuações

Como essas mudanças afetam a pontuação dos sites reais? Publicamos uma análise das alterações de pontuação usando dois conjuntos de dados: um conjunto geral de sites e um conjunto de sites estáticos criado com o Eleventy. Resumindo, cerca de 20% dos sites têm pontuações visivelmente mais altas, cerca de 30% quase não apresentam nenhuma mudança e cerca de 50% observam uma redução de pelo menos cinco pontos.

As alterações na pontuação podem ser divididas em três componentes principais:

• mudanças de peso da pontuação
• correções de bugs para implementações de métricas subjacentes
• mudanças de curva de pontuação individual

As mudanças no peso da pontuação e a introdução de três novas métricas impulsionaram a maioria das mudanças gerais na pontuação. As novas métricas que os desenvolvedores ainda precisam otimizar para ter um peso significativo na pontuação de desempenho da versão 6. Enquanto a pontuação de desempenho média do corpus de teste na versão 5 foi de cerca de 50, as pontuações médias nas novas métricas "Tempo total de bloqueio" e "Maior exibição de conteúdo" ficaram em torno de 30. Juntas, essas duas métricas representam 50% do peso na pontuação de desempenho da versão 6 do Lighthouse, portanto, naturalmente uma grande porcentagem de sites teve reduções.

Correções de bugs no cálculo da métrica subjacente podem resultar em pontuações diferentes. Isso afeta relativamente poucos sites, mas pode ter um impacto considerável em determinadas situações. No geral, cerca de 8% dos sites tiveram uma melhoria na pontuação devido a mudanças na implementação de métricas, e cerca de 4% tiveram uma queda devido a mudanças na implementação de métricas. Aproximadamente 88% dos sites não foram afetados por essas correções.

As alterações na curva de pontuação individual também afetaram as variações geral da pontuação, embora ligeiramente. Garantimos periodicamente que a curva de pontuação se alinhe às métricas observadas no conjunto de dados HTTPArchive. Excluindo os sites afetados por grandes mudanças de implementação, pequenos ajustes na curva de pontuação das métricas individuais melhoraram as pontuações de cerca de 3% dos sites e diminuíram as pontuações de cerca de 4%. Aproximadamente 93% dos sites não foram afetados por essa mudança.

Calculadora de pontuação

Publicamos uma calculadora de pontuação para ajudar você a explorar a pontuação de desempenho. A calculadora também oferece uma comparação entre as pontuações da versão 5 e 6 do Lighthouse. Quando você executa uma auditoria com o Lighthouse 6.0, o relatório vem com um link para a calculadora com os resultados preenchidos.

Agradecemos muito a Ana Tudor pelo upgrade do medidor.

Novas auditorias

JavaScript não utilizado

Estamos usando a cobertura de código do DevTools em uma nova auditoria: Unused JavaScript.

Essa auditoria não é totalmente nova. Ela foi adicionada em meados de 2017, mas devido à sobrecarga de desempenho, ela foi desativada por padrão para manter o Lighthouse o mais rápido possível. A coleta desses dados de cobertura é muito mais eficiente agora, então nos sentimos à vontade para ativá-los por padrão.

Auditorias de acessibilidade

O Lighthouse usa a maravilhosa biblioteca axe-core para potencializar a categoria de acessibilidade. No Lighthouse 6.0, adicionamos as seguintes auditorias:

• aria-oculto-body
• aria-hidden-focus
• aria-input-field-name
• aria-toggle-field-name
• form-field-multiple-labels
• heading-order
• duplicar-id-ativo
• duplicar-id-aria

Ícone mascarável

Ícones mascaráveis são um novo formato que faz com que os ícones do PWA tenham uma ótima aparência em todos os tipos de dispositivos. Para que seu PWA tenha a melhor aparência possível, lançamos uma nova auditoria para verificar se o manifest.json é compatível com esse novo formato.

Declaração de conjunto de caracteres

O elemento meta charset declara qual codificação de caracteres precisa ser usada para interpretar um documento HTML. Se esse elemento estiver ausente ou se for declarado tardiamente no documento, os navegadores empregarão várias heurísticas para adivinhar qual codificação precisa ser usada. Se um navegador adivinhar incorretamente e um elemento de metaconjunto de caracteres atrasado for encontrado, o analisador geralmente lançará todo o trabalho feito até o momento e reiniciará, levando a experiências ruins para o usuário. Essa nova auditoria verifica se a página tem uma codificação de caracteres válida e se ela foi definida antecipadamente.

Lighthouse CI

No CDS de novembro do ano passado, anunciamos o Lighthouse CI, a CLI e o servidor de nó de código aberto que rastreia os resultados do Lighthouse em cada confirmação no pipeline de integração contínua, e percorremos um longo caminho desde o lançamento da versão Alfa. O Lighthouse CI agora é compatível com vários provedores de CI, incluindo Travis, Circle, GitLab e GitHub Actions. As imagens do Docker prontas para implantação facilitam a configuração, e a reformulação abrangente do painel agora revela tendências em todas as categorias e métricas no Lighthouse para uma análise detalhada.

Comece a usar o Lighthouse CI no seu projeto hoje mesmo seguindo nosso guia para iniciantes.

Painel do Chrome DevTools renomeado

O painel Auditorias agora se chama Lighthouse. Chega de falar!

Dependendo do tamanho da janela do DevTools, o painel provavelmente está atrás do botão ». É possível arrastar a guia para alterar a ordem.

Para revelar o painel rapidamente com o Menu de comando:

1. Pressione "Control + Shift + J" (ou "Command + Option + J" no Mac) para abrir o DevTools.
2. Pressione Control+Shift+P (ou Command+Shift+P no Mac) para abrir o menu Comando.
3. Comece a digitar "Lighthouse".
4. Pressione Enter.

Emulação de dispositivos móveis

O Lighthouse segue uma mentalidade que prioriza dispositivos móveis. Os problemas de desempenho são mais aparentes em condições típicas de dispositivos móveis, mas os desenvolvedores geralmente não testam nessas condições. É por isso que a configuração padrão do Lighthouse aplica a emulação de dispositivos móveis. A emulação consiste em:

• Simulação de condições lentas de rede e CPU (por um mecanismo de simulação chamado Lantern).
• Emulação de tela do dispositivo (a mesma do Chrome DevTools).

Desde o início, o Lighthouse usa o Nexus 5X como dispositivo de referência. Nos últimos anos, a maioria dos engenheiros de performance tem usado o Moto G4 para testes. Agora o Lighthouse segue o exemplo e mudou seu dispositivo de referência para o Moto G4. Na prática, essa mudança não é muito perceptível, mas aqui estão todas as mudanças detectáveis por uma página da Web:

• O tamanho da tela é alterado de 412 x 660 px para 360 x 640 px.
• A string do user agent mudou um pouco. A parte do dispositivo que era Nexus 5 Build/MRA58N agora será Moto G (4).

A partir do Chrome 81, o Moto G4 também está disponível na lista de emulação de dispositivos do Chrome DevTools.

Extensão do navegador

A extensão do Chrome para o Lighthouse é uma maneira conveniente de executar o Lighthouse localmente. Infelizmente, era complicado oferecer suporte. Achamos que, como o painel Lighthouse do Chrome DevTools é uma experiência melhor (o relatório se integra a outros painéis), poderíamos reduzir a sobrecarga de engenharia simplificando a extensão do Chrome.

Em vez de executar o Lighthouse localmente, a extensão agora usa a API PageSpeed Insights. Reconhecemos que isso não será um substituto suficiente para alguns de nossos usuários. Estas são as principais diferenças:

• O PageSpeed Insights não pode auditar sites não públicos, já que é executado por um servidor remoto, e não pela instância local do Chrome. Se você precisar auditar um site não público, use o painel Lighthouse do DevTools ou a CLI do nó.
• Não há garantia de que o PageSpeed Insights vai usar a versão mais recente do Lighthouse. Se você quiser usar a versão mais recente, use a CLI do Node. A extensão do navegador receberá a atualização cerca de uma a duas semanas após o lançamento.
• O PageSpeed Insights é uma API do Google. O uso dela constitui aceitação dos Termos de Serviço das APIs do Google. Se você não quiser ou não aceitar os Termos de Serviço, use o painel Lighthouse do DevTools ou a CLI do Node.

A boa notícia é que simplificar a história do produto nos permitiu focar em outros problemas de engenharia. Por isso, lançamos a extensão Lighthouse para Firefox.

Orçamentos

O Lighthouse 5.0 introduziu os orçamentos de desempenho que permitiam a adição de limites para quanto de cada tipo de recurso (como scripts, imagens ou css) uma página pode veicular.

O Lighthouse 6.0 adiciona suporte a métricas de orçamento para que você possa definir limites para métricas específicas, como a FCP. Por enquanto, os orçamentos estão disponíveis apenas para a CLI do Node e para a CI do Lighthouse.

Links de local de origem

Alguns dos problemas que o Lighthouse encontra em uma página podem ser rastreados até uma linha específica de código-fonte, e o relatório vai indicar o arquivo e a linha exatos relevantes. Para facilitar a exploração no DevTools, clique nos locais especificados no relatório para abrir os arquivos relevantes no painel Sources.

O DevTools revela a linha exata de código que causa o problema.

No horizonte

O Lighthouse começou a experimentar a coleta de mapas de origem para potencializar novos recursos, como:

• Detectar módulos duplicados em pacotes JavaScript.
• Detecção de polyfills ou transformações excessivas em código enviado para navegadores modernos.
• Melhoria da auditoria de JavaScript não usado para fornecer granularidade no nível do módulo
• Visualizações de mapa de árvore destacando os módulos que exigem ação.
• Exibir o código-fonte original dos itens do relatório com um "local de origem".

A auditoria de JavaScript não utilizado usando mapas de origem para mostrar código não utilizado em módulos agrupados específicos

Esses recursos serão ativados por padrão em uma versão futura do Lighthouse. Por enquanto, é possível visualizar as auditorias experimentais do Lighthouse com a seguinte sinalização da CLI:

lighthouse https://web.dev --view --preset experimental

Valeu!

Agradecemos por usar o Lighthouse e seu feedback. Seu feedback nos ajuda a melhorar o Lighthouse e esperamos que o Lighthouse 6.0 facilite o aprimoramento do desempenho de seus sites.

O que você pode fazer agora?

• Abra o Chrome Canary e teste o painel Lighthouse.
• Use a CLI do nó: npm install -g lighthouse && lighthouse https://yoursite.com --view.
• Execute o Lighthouse CI no seu projeto.
• Leia a documentação de auditoria do Lighthouse.
• Divirta-se tornando a Web melhor!

Somos apaixonados pela Web e adoramos trabalhar com a comunidade de desenvolvedores para criar ferramentas que possam ajudar a melhorar a Web. O Lighthouse é um projeto de código aberto, e agradecemos a todos os colaboradores que ajudam em tudo, desde correções de erros de digitação até refatorações de documentação e novas auditorias. Quer contribuir? Acesse o repositório do Lighthouse no GitHub (link em inglês).