Lighthouse: otimize a velocidade do site

Kayce Basques

Sofia Emelianova

Visão geral

Use o painel Lighthouse para realizar uma auditoria abrangente do seu site. O painel do Lighthouse gera um relatório que mostra informações sobre o seguinte:

• Desempenho
• Acessibilidade
• Práticas recomendadas
• SEO

… e muitas outras métricas.

O tutorial a seguir ajuda você a começar a usar o Lighthouse no Chrome DevTools.

Para saber mais sobre outras maneiras de melhorar a qualidade do seu site com o Lighthouse, consulte os documentos do Lighthouse.

Objetivo do tutorial

Este tutorial ensina como usar o Chrome DevTools para encontrar maneiras de acelerar o carregamento dos seus sites.

Continue lendo ou assista a versão em vídeo deste tutorial:

Este vídeo foi criado com o Chrome 68. A maioria dos detalhes ainda é válida, mas alguns recursos foram atualizados. Por exemplo, o painel Audits agora é chamado de Lighthouse e tem uma aparência diferente, mas todas as opções ainda estão disponíveis.

Pré-requisitos

Você precisa ter experiência básica em desenvolvimento para a Web, semelhante ao que é ensinado nesta aula de introdução ao desenvolvimento para a Web.

Você não precisa saber nada sobre a performance de carregamento.

Introdução

Aqui é Tony. Tony é muito famoso na sociedade dos gatos. Ele criou um site para que os fãs possam saber quais são os alimentos favoritos dele. Os fãs adoram o site, mas Tony continua recebendo reclamações de que o site está lento. Tony pediu sua ajuda para acelerar o site.

Tony, o gato.

Etapa 1: auditar o site

Sempre comece com uma auditoria quando quiser melhorar a performance de carregamento de um site. A auditoria tem duas funções importantes:

• Ele cria um valor de referência para que você possa medir as mudanças subsequentes.
• Ele oferece dicas práticas sobre quais mudanças terão o maior impacto.

Configurar

Primeiro, você precisa configurar um novo ambiente de trabalho para o site de Tony, para que você possa fazer alterações mais tarde:

1. Remixe o projeto do site no Glitch. O novo projeto é aberto em uma guia. Essa guia será chamada de guia do editor.

   

   O nome do projeto muda de tony para um nome gerado aleatoriamente. Agora você tem sua própria cópia editável do código. Mais tarde, você vai fazer mudanças nesse código.

2. Na parte de baixo da guia do editor, clique em Visualizar > Visualizar em uma nova janela. A demonstração será aberta em uma nova guia. Essa guia será chamada de guia de demonstração. Pode levar um tempo até que o site seja carregado.

   

3. Abra o DevTools com a demonstração.

   

Importante:nas capturas de tela restantes deste tutorial, o DevTools aparece em uma janela separada.

Definir um valor de referência

A linha de base é um registro de como o site se saiu antes das melhorias de performance.

1. Abra o painel Lighthouse. Ele pode estar oculto atrás de Mais painéis.

   Observação:este painel é alimentado pelo Lighthouse, uma ferramenta automatizada para melhorar a qualidade dos seus apps da Web.

   

2. Compare as configurações do relatório do Lighthouse com as da captura de tela. Confira uma explicação das diferentes opções:

   • check_box Limpar armazenamento. Ativar essa caixa de seleção limpa todo o armazenamento associado à página antes de cada auditoria. Deixe essa configuração ativada se quiser auditar a experiência dos visitantes que acessam seu site pela primeira vez. Desative essa configuração quando quiser a experiência de visita repetida.
   • check_box Ativar a amostragem de JS. Essa opção fica desativada por padrão. Quando ativado, ele adiciona pilhas de chamadas JavaScript detalhadas ao rastro de performance, mas pode retardar a geração de relatórios. O rastro está disponível em more_vert Menu de ferramentas > Exibir rastro não limitado depois que o relatório do Lighthouse é gerado.
   • Limitação simulada (padrão) . Essa opção simula as condições típicas de navegação em um dispositivo móvel. Ele é chamado de "simulado" porque o Lighthouse não limita o desempenho durante o processo de auditoria. Em vez disso, ele apenas extrapola o tempo que a página levaria para carregar em condições de dispositivos móveis. A configuração Limitação do DevTools (avançado), por outro lado, limita a CPU e a rede, com a desvantagem de um processo de auditoria mais longo.
   • Modo > Navegação (padrão). Esse modo analisa um único carregamento de página, e é isso que precisamos neste tutorial. Para mais informações, consulte Os três modos.
   • Dispositivo > Móvel. A opção para dispositivos móveis muda a string do user agent e simula uma janela de visualização para dispositivos móveis. A opção para computador basicamente desativa as mudanças para dispositivos móveis.
   • Categorias > check_box Performance. Uma única categoria ativada faz com que o Lighthouse gere um relatório apenas com o conjunto de auditorias correspondente. Você pode deixar as outras categorias ativadas se quiser conferir os tipos de recomendações que elas oferecem. Desativar categorias irrelevantes acelera um pouco o processo de auditoria.

3. Clique em Analisar o carregamento de página. Após 10 a 30 segundos, o painel do Lighthouse mostra um relatório sobre a performance do site.

   

Como lidar com erros de relatório

Se você receber um erro no relatório do Lighthouse, tente executar a guia de demonstração em uma janela anônima sem outras guias abertas. Isso garante que você esteja executando o Chrome em um estado limpo. As extensões do Chrome, em particular, podem interferir no processo de auditoria.

Entender seu relatório

O número na parte de cima do relatório é a pontuação geral de desempenho do site. Mais tarde, conforme você faz mudanças no código, esse número vai aumentar. Uma pontuação mais alta significa uma performance melhor.

Métricas

Role a tela para baixo até a seção Métricas e clique em Abrir visualização. Para ler a documentação de uma métrica, clique em Saiba mais....

Esta seção fornece medições quantitativas da performance do site. Cada métrica fornece insights sobre um aspecto diferente da performance. Por exemplo, First Contentful Paint informa quando o conteúdo é pintado pela primeira vez na tela, o que é um marco importante na percepção do usuário sobre o carregamento da página, enquanto Time To Interactive marca o ponto em que a página parece pronta o suficiente para processar as interações do usuário.

Capturas de tela

A seguir, há uma coleção de capturas de tela que mostram como a página ficou durante o carregamento.

Oportunidades

Em seguida, há a seção Oportunidades, que oferece dicas específicas sobre como melhorar o desempenho de carregamento dessa página específica.

Clique em uma oportunidade para saber mais sobre ela.

Clique em Saiba mais para acessar a documentação sobre por que uma oportunidade é importante e recomendações específicas sobre como corrigir o problema.

Diagnóstico

A seção Diagnóstico fornece mais informações sobre os fatores que contribuem para o tempo de carregamento da página.

Auditorias aprovadas

A seção Auditorias aprovadas mostra o que o site está fazendo corretamente. Clique para expandir a seção.

Etapa 2: fazer experimentos

A seção Oportunidades do relatório do Lighthouse dá dicas sobre como melhorar o desempenho da página. Nesta seção, você implementa as mudanças recomendadas na base de código, auditando o site após cada mudança para medir como ela afeta a velocidade do site.

Ativar a compactação de texto

O relatório indica que ativar a compactação de texto é uma das principais oportunidades para melhorar a performance da página.

A compactação de texto é quando você reduz ou compacta o tamanho de um arquivo de texto antes de enviá-lo pela rede. É como compactar uma pasta antes de enviá-la por e-mail para reduzir o tamanho.

Antes de ativar a compactação, confira algumas maneiras de verificar manualmente se os recursos de texto estão compactados.

Abra o painel Network e marque Settings > Use large request rows.

Ponto principal:se a coluna Tamanho não aparecer na tabela de solicitações de rede, clique com o botão direito do mouse no cabeçalho da tabela e selecione Tamanho.

Cada célula Tamanho mostra dois valores. O valor de cima é o tamanho do recurso transferido. O valor de baixo é o tamanho do recurso descompactado. Se os dois valores forem iguais, o recurso não estará sendo compactado quando enviado pela rede. Neste exemplo, os valores de cima e de baixo de bundle.js são 1.4 MB.

Também é possível verificar a compactação inspecionando os cabeçalhos HTTP de um recurso:

1. Clique em bundle.js e abra a guia Headers.

   

2. Pesquise um cabeçalho content-encoding na seção Cabeçalhos de resposta. Você não vai encontrar uma, o que significa que bundle.js não foi compactado. Quando um recurso é compactado, esse cabeçalho geralmente é definido como gzip, deflate ou br. Consulte Diretivas para uma explicação desses valores.

Chega de explicações. É hora de fazer algumas mudanças. Ative a compactação de texto adicionando algumas linhas de código:

1. Na guia do editor, abra server.js e adicione as duas linhas (realçadas) a seguir:

   ...
   const fs = require('fs');
   const compression = require('compression');
   
   app.use(compression());
   app.use(express.static('build'));
   ...
   

2. Coloque app.use(compression()) antes de app.use(express.static('build')).

   

   Observação:normalmente, você precisa instalar o pacote compression com algo como npm i -S compression, mas isso já foi feito para você.

3. Aguarde o Glitch implantar o novo build do site. Um emoji feliz no canto inferior esquerdo indica que a implantação foi bem-sucedida.

Use os fluxos de trabalho que você aprendeu anteriormente para verificar manualmente se a compactação está funcionando:

1. Volte para a guia de demonstração e atualize a página.

   A coluna Tamanho agora mostra dois valores diferentes para recursos de texto, como bundle.js. O valor superior de 269 KB para bundle.js é o tamanho do arquivo enviado pela rede, e o valor inferior de 1.4 MB é o tamanho do arquivo não compactado.

   

2. A seção Cabeçalhos de resposta de bundle.js agora precisa incluir um cabeçalho content-encoding: gzip.

   

Execute o relatório do Lighthouse na página novamente para medir o impacto da compactação de texto na performance de carregamento da página:

1. Abra o painel Lighthouse e clique em Realizar uma auditoria na barra de ações na parte de cima.

   

2. Deixe as configurações como antes e clique em Analisar a carga da página.

   

Uhuuu! Parece que está progredindo. Sua pontuação de desempenho geral deve ter aumentado, o que significa que o site está ficando mais rápido.

Compactação de texto no mundo real

A maioria dos servidores tem correções simples como essa para ativar a compactação. Basta pesquisar como configurar qualquer servidor que você usa para compactar texto.

Redimensionar imagens

Seu novo relatório diz que dimensionar imagens corretamente é outra grande oportunidade.

Redimensionar imagens ajuda a acelerar o tempo de carregamento, reduzindo o tamanho do arquivo. Se o usuário estiver visualizando suas imagens em uma tela de dispositivo móvel com 500 pixels de largura, não faz sentido enviar uma imagem de 1.500 pixels de largura. O ideal é enviar uma imagem com no máximo 500 pixels de largura.

1. No relatório, clique em Definir um tamanho adequado para as imagens para saber quais imagens precisam ser redimensionadas. Parece que as quatro imagens são maiores do que o necessário.

   

2. Na guia do editor, abra src/model.js.

3. Substitua const dir = 'big' por const dir = 'small'. Esse diretório contém cópias das mesmas imagens que foram redimensionadas.

4. Audite a página novamente para saber como essa mudança afeta o desempenho de carregamento.

   

Parece que a mudança tem apenas um pequeno impacto na pontuação de desempenho geral. No entanto, uma coisa que a pontuação não mostra claramente é quantos dados de rede você está salvando para os usuários. O tamanho total das fotos antigas era de cerca de 6,1 MB, enquanto agora é de apenas 633 KB. É possível verificar isso na barra de status na parte de baixo do painel Rede.

Redimensionar imagens no mundo real

Para um app pequeno, fazer um redimensionamento único como esse pode ser suficiente. Mas, para um app grande, isso obviamente não é escalonável. Confira algumas estratégias para gerenciar imagens em apps grandes:

• Redimensione as imagens durante o processo de build.
• Crie vários tamanhos de cada imagem durante o processo de build e use srcset no código. No momento da execução, o navegador escolhe o tamanho ideal para o dispositivo em que está sendo executado. Consulte Imagens com tamanho relativo.
• Use um CDN de imagem que permita redimensionar dinamicamente uma imagem quando você solicitar.
• Pelo menos, otimize cada imagem. Isso pode gerar grandes economias. A otimização é quando você executa uma imagem em um programa especial que reduz o tamanho do arquivo de imagem. Consulte Otimização de imagens essenciais para mais dicas.

Eliminar recursos que bloqueiam a renderização

Seu relatório mais recente diz que eliminar recursos que bloqueiam a renderização é agora a maior oportunidade.

Um recurso bloqueador de renderização é um arquivo JavaScript ou CSS externo que o navegador precisa fazer o download, analisar e executar antes de mostrar a página. O objetivo é executar apenas o código principal do CSS e do JavaScript necessário para mostrar a página corretamente.

A primeira tarefa, então, é encontrar o código que não precisa ser executado no carregamento da página.

1. Clique em Eliminar recursos que impedem a renderização para conferir os recursos que estão bloqueando: lodash.js e jquery.js.

   

2. Dependendo do sistema operacional, pressione o seguinte para abrir o Command Menu:

   • No Mac, Command+Shift+P
   • No Windows, Linux ou ChromeOS, Control+Shift+P

3. Comece a digitar Coverage e selecione Mostrar cobertura.

   

   A guia Cobertura é aberta na gaveta.

   

4. Clique em Atualizar Recarregar. A guia Cobertura mostra uma visão geral de quanto do código em bundle.js, jquery.js e lodash.js está sendo executado enquanto a página é carregada.

   

   Esta captura de tela mostra que cerca de 74% e 30% dos arquivos jQuery e Lodash não são usados, respectivamente.

5. Clique na linha jquery.js. O DevTools abre o arquivo no painel Sources. Uma linha de código foi executada se ela tiver uma barra verde ao lado. Uma barra vermelha ao lado de uma linha de código significa que ela não foi executada e definitivamente não é necessária no carregamento da página.

   

6. Role um pouco pelo código jQuery. Algumas das linhas que são "executadas" são apenas comentários. Executar esse código em um minificador que remove comentários é outra maneira de reduzir o tamanho desse arquivo.

Em resumo, quando você trabalha com seu próprio código, a guia Cobertura pode ajudar a analisar o código, linha por linha, e enviar apenas o código necessário para o carregamento da página.

Os arquivos jquery.js e lodash.js são necessários para carregar a página? A guia Bloqueio de solicitações pode mostrar o que acontece quando os recursos não estão disponíveis.

1. Clique na guia Rede e abra o Command Menu novamente.

2. Comece a digitar blocking e selecione Mostrar o bloqueio de solicitações. A guia Bloqueio de solicitações é aberta.

   

3. Clique em Adicionar padrão, digite /libs/* na caixa de texto e pressione Enter para confirmar.

   

4. Recarregue a página. As solicitações do jQuery e do Lodash estão em vermelho, o que significa que foram bloqueadas. A página ainda carrega e é interativa, então parece que esses recursos não são necessários.

   

5. Clique em Remover todos os padrões para excluir o padrão de bloqueio /libs/*.

Em geral, a guia Bloqueio de solicitações é útil para simular como a página se comporta quando um determinado recurso não está disponível.

Agora, remova as referências a esses arquivos do código e audite a página novamente:

1. Na guia do editor, abra template.html.

2. Exclua as tags <script> correspondentes:

   <head>
       ...
       <meta name="viewport" content="width=device-width, initial-scale=1">
       <script src="/libs/lodash.js"></script>
       <script src="/libs/jquery.js"></script>
       <title>Tony's Favorite Foods</title>
   </head>
   

3. Aguarde a reconstrução e a reimplantação do site.

4. Faça uma auditoria na página novamente no painel do Lighthouse. Sua pontuação geral deve ter melhorado novamente.

   

Otimizar o caminho crítico de renderização no mundo real

O caminho crítico de renderização se refere ao código necessário para carregar uma página. Em geral, é possível acelerar o carregamento da página enviando apenas o código crítico durante o carregamento da página e, em seguida, carregando tudo de forma lenta.

• É improvável que você encontre scripts que possam ser removidos imediatamente, mas é comum que muitos scripts não precisem ser solicitados durante o carregamento da página e possam ser solicitados de forma assíncrona. Consulte Usar async ou defer.
• Se você estiver usando uma framework, verifique se ela tem um modo de produção. Esse modo pode usar um recurso como tree shaking para eliminar o código desnecessário que está bloqueando a renderização crítica.

Fazer menos trabalho na linha de execução principal

Seu relatório mais recente mostra algumas economias potenciais menores na seção Oportunidades, mas, se você rolar até a seção Diagnóstico, parece que o maior gargalo é muita atividade na linha de execução principal.

A linha de execução principal é onde o navegador faz a maior parte do trabalho necessário para exibir uma página, como analisar e executar HTML, CSS e JavaScript.

Observação:esta seção oferece uma introdução bastante breve ao painel "Performance". Consulte a Referência de recursos de desempenho para saber como usá-la para analisar o desempenho da página.

O objetivo é usar o painel Performance para analisar o trabalho que a linha de execução principal está fazendo enquanto a página é carregada e encontrar maneiras de adiar ou remover o trabalho desnecessário.

1. Abra Performance > Configurações de captura e defina Rede como 3G lento e CPU como 6x mais lento.

   

   Os dispositivos móveis geralmente têm mais restrições de hardware do que laptops ou desktops. Por isso, essas configurações permitem que você experimente o carregamento da página como se estivesse usando um dispositivo menos potente.

2. Clique em Atualizar Recarregar. O DevTools recarrega a página e gera uma visualização de tudo o que ela precisou fazer para carregar a página. Essa visualização será chamada de traço.

   

O rastro mostra a atividade cronologicamente, da esquerda para a direita. Os gráficos de QPS, CPU e NET na parte de cima oferecem uma visão geral dos frames por segundo, da atividade da CPU e da atividade de rede.

A parede amarela que você vê na seção Informações gerais significa que a CPU estava completamente ocupada com a atividade de script. Isso é uma pista de que você pode acelerar o carregamento da página fazendo menos trabalho com JavaScript.

Investigue o rastro para encontrar maneiras de fazer menos trabalho com JavaScript:

1. Clique na seção Tempos para abrir.

   

   Há várias medidas de tempo do usuário no React. Parece que o app de Tony está usando o modo de desenvolvimento do React. A mudança para o modo de produção do React provavelmente vai gerar algumas vantagens de desempenho fáceis.

2. Clique em Tempos novamente para fechar essa seção.

3. Navegue pela seção Principal. Esta seção mostra um registro cronológico da atividade da linha de execução principal, da esquerda para a direita. O eixo y (de cima para baixo) mostra por que os eventos ocorreram.

   

   Neste exemplo, o evento Evaluate Script fez com que a função (anonymous) fosse executada, o que fez com que __webpack__require__ fosse executado, o que fez com que ./src/index.jsx fosse executado e assim por diante.

4. Role para baixo até a parte de baixo da seção Principal. Quando você usa um framework, a maior parte da atividade superior é causada por ele, que geralmente está fora do seu controle. A atividade causada pelo app geralmente fica na parte de baixo.

   

   Nesse app, parece que uma função chamada App está causando muitas chamadas para uma função mineBitcoin. Parece que Tony está usando os dispositivos dos fãs para minerar criptomoedas...

   Observação:embora as chamadas feitas pelo framework geralmente estejam fora do seu controle, às vezes você pode estruturar o app de uma maneira que faça com que o framework seja executado de maneira ineficiente. Reestruturar seu app para usar o framework de maneira eficiente pode ser uma forma de reduzir o trabalho da linha de execução principal. Isso requer um entendimento profundo de como o framework funciona e que tipo de mudanças você pode fazer no seu próprio código para usar o framework de maneira mais eficiente.

5. Abra a guia Bottom-Up na parte de baixo. Essa guia detalha quais atividades consumiram mais tempo. Se você não encontrar nada na seção Bottom-Up, clique no rótulo da seção Main.

   

   A seção Bottom-Up mostra apenas informações sobre qualquer atividade ou grupo de atividades que você tenha selecionado. Por exemplo, se você clicar em uma das atividades mineBitcoin, a seção Bottom-Up vai mostrar apenas as informações dessa atividade.

   A coluna Tempo próprio mostra quanto tempo foi gasto diretamente em cada atividade. Nesse caso, cerca de 82% do tempo da linha de execução principal foi gasto na função mineBitcoin.

É hora de verificar se o uso do modo de produção e a redução da atividade do JavaScript aceleram o carregamento da página. Comece com o modo de produção:

1. Na guia do editor, abra webpack.config.js.
2. Altere "mode":"development" para "mode":"production".
3. Aguarde a implantação do novo build.

4. Faça uma auditoria na página novamente.

   

Reduza a atividade do JavaScript removendo a chamada para mineBitcoin:

1. Na guia do editor, abra src/App.jsx.
2. Comente a chamada para this.mineBitcoin(1500) no constructor.
3. Aguarde a implantação do novo build.
4. Faça uma auditoria na página novamente.

Como sempre, ainda há coisas a fazer, por exemplo, reduzir as métricas Largest Contentful Paint e Cumulative Layout Shift.

Sucesso:mas parece que a última mudança causou um grande salto na performance.

Fazer menos trabalho na linha de execução principal no mundo real

Em geral, o painel Performance é a maneira mais comum de entender a atividade do seu site durante o carregamento e encontrar maneiras de remover atividades desnecessárias.

Se você preferir uma abordagem mais parecida com console.log(), a API User Timing permite marcar arbitrariamente determinadas fases do ciclo de vida do app para acompanhar o tempo que cada uma delas leva.

Resumo

• Sempre comece com uma auditoria quando for otimizar a performance de carregamento de um site. A auditoria estabelece uma referência e dá dicas sobre como melhorar.
• Faça uma mudança de cada vez e audite a página após cada mudança para ver como essa mudança isolada afeta o desempenho.

Próximas etapas

Faça auditorias no seu próprio site. Se você precisar de ajuda para interpretar o relatório ou encontrar maneiras de melhorar a performance de carregamento, confira todas as maneiras de receber ajuda da comunidade do DevTools:

• Informe bugs sobre este documento no repositório developer.chrome.com.
• Envie relatórios de bugs no DevTools em Bugs do Chromium.
• Discuta os recursos e as mudanças na lista de e-mails. Não use a lista de e-mails para perguntas de suporte. Use o Stack Overflow.
• Receba ajuda geral sobre como usar o DevTools no Stack Overflow. Para registrar solicitações de bugs, sempre use o Chromium Bugs.
• Envie um tweet para @ChromeDevTools.