Lighthouse: otimize a velocidade do site

Objetivo do tutorial

Este tutorial ensina como usar o Chrome DevTools para encontrar maneiras de carregar seus sites mais rapidamente.

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

Pré-requisitos

É necessário ter experiência básica em desenvolvimento da Web, semelhante ao que é ensinado nesta aula de introdução ao desenvolvimento da Web.

Você não precisa saber nada sobre o desempenho de carga.

Introdução

Este é o Tony. Tony é muito famoso na sociedade de gatos. Ele criou um site para que os fãs saibam quais são as comidas favoritas dele. Os fãs adoram o site, mas Tony continua ouvindo reclamações de que o site carrega lentamente. Tony pediu sua ajuda para acelerar o site.

Etapa 1: auditar o site

Sempre que você quiser melhorar o desempenho de carregamento de um site, comece com uma auditoria. A auditoria tem duas funções importantes:

• Ele cria uma base de referência para medir as próximas mudanças.
• Ele dá dicas úteis sobre quais mudanças terão mais impacto.

Configurar

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

1. Remixar o projeto do site no Glitch. Seu novo projeto será aberto em uma guia. Ela será chamada de guia do editor.

   

   O nome do projeto muda de tony para um nome gerado aleatoriamente. Agora você tem uma cópia editável do código. Mais tarde, você fará alterações 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. Ela será chamada de guia "Demonstração". Pode levar algum tempo para o site carregar.

   

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

   

Definir um valor de referência

A referência é um registro do desempenho do site antes das melhorias.

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

   

2. Use as mesmas configurações do relatório do Lighthouse que as mostradas na captura de tela. Aqui está uma explicação das diferentes opções:

   • check_box Limpar armazenamento. Marcar esta caixa de seleção limpa todo o armazenamento associado à página antes de cada auditoria. Mantenha essa configuração ativada se você quiser auditar a experiência dos visitantes novos no seu site. Desative essa configuração quando quiser usar a experiência de visitas repetidas.
   • check_box Ativar amostragem de JS. Essa opção fica desativada por padrão. Quando ativada, ela adiciona pilhas de chamadas JavaScript detalhadas ao rastreamento de desempenho, mas pode atrasar a geração de relatórios. O trace fica disponível no more_vert menu Ferramentas > Ver rastros não limitados depois que o relatório do Lighthouse é gerado.
   • Limitação simulada (padrão) arrow_drop_down. 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 durante o processo de auditoria. Em vez disso, ela apenas extrapola o tempo que a página levaria para carregar em dispositivos móveis. A configuração Limitação do DevTools (avançado), por outro lado, limita a CPU e a rede, mas exige um processo de auditoria mais longo.
   • Modo > radio_button_checked Navegação (padrão). Esse modo analisa um único carregamento de página, e é disso que precisamos neste tutorial. Para mais informações, consulte Os três modos.
   • Dispositivo > radio_button_checked Dispositivo móvel. A opção para dispositivos móveis altera a string do user agent e simula uma janela de visualização para dispositivos móveis. A opção para desktop apenas desativa as mudanças para dispositivos móveis.
   • Categorias > check_box Desempenho. Uma única categoria ativada faz com que o Lighthouse gere um relatório somente com o conjunto correspondente de auditorias. Você pode deixar as outras categorias ativadas se quiser ver os tipos de recomendação que elas oferecem. Desativar categorias irrelevantes acelera um pouco o processo de auditoria.

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

   

Tratamento de 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 especial, podem interferir no processo de auditoria.

Entenda seu relatório

O número na parte superior do relatório representa a pontuação de desempenho geral do site. Mais tarde, à medida que você faz alterações no código, esse número deve aumentar. Uma pontuação mais alta significa um desempenho melhor.

Métricas

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

Esta seção fornece medições quantitativas do desempenho do site. Cada métrica fornece informações sobre um aspecto diferente da performance. Por exemplo, a 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 o Tempo para interação da página marca o ponto em que a página aparece pronta o suficiente para lidar com as interações do usuário.

Capturas de tela

A seguir, temos uma coleção de capturas de tela que mostram a aparência da página conforme ela foi carregada.

Oportunidades

A seguir, a seção Oportunidades, que fornece 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 ver a documentação sobre por que uma oportunidade é importante e recomendações específicas sobre como corrigi-la.

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: faça testes

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

Ativar a compactação de texto

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

A compactação de texto ocorre quando você reduz ou compacta o tamanho de um arquivo de texto antes de enviá-lo pela rede. Por exemplo, para reduzir o tamanho de uma pasta antes de enviá-la por e-mail.

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

Abra o painel Rede e verifique settings Configurações > check_box Usar linhas de solicitação grandes.

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

Você também pode verificar a compactação inspecionando os cabeçalhos HTTP de um recurso:

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

   

2. Procure um cabeçalho content-encoding na seção Cabeçalhos de resposta. Você não o verá, 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 ver uma explicação sobre esses 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 estas duas linhas (destacadas):

   ...
   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')).

   

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

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

1. Volte para a guia "Demonstração" e atualize a página.

   A coluna Size agora deve mostrar dois valores diferentes para recursos de texto como bundle.js. O valor superior de 269 KB para bundle.js é o tamanho do arquivo que foi enviado pela rede, e o valor inferior de 1.4 MB é o tamanho do arquivo descompactado.

   

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

   

Gere o relatório do Lighthouse na página novamente para medir o impacto da compactação de texto no desempenho 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. Mantenha as configurações de antes e clique em Analisar carregamento de página.

   

Uhuuu! Isso parece um progresso. Sua pontuação de desempenho geral deveria ter aumentado, o que significa que o site está ficando mais rápido.

Compactação de texto no mundo real

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

Redimensionar imagens

Seu novo relatório diz que o dimensionamento adequado das imagens é outra grande oportunidade.

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

1. No relatório, clique em Tamanho adequado das imagens para ver quais imagens precisam ser redimensionadas. Parece que as quatro imagens são maiores que o necessário.

   

2. De volta à 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 ver como essa alteração afeta o desempenho de carregamento.

   

Parece que a mudança só tem um pequeno impacto na pontuação de desempenho geral. No entanto, a pontuação não mostra claramente a quantidade de dados de rede que você está economizando para os usuários. O tamanho total das fotos antigas era de cerca de 6,1 MB, mas agora tem apenas 633 KB. É possível verificar isso na barra de status na parte inferior do painel Network.

Como redimensionar imagens no mundo real

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

• Redimensionar imagens durante o processo de build.
• Crie vários tamanhos para cada imagem durante o processo de build e use srcset no código. Durante a execução, o navegador escolhe o tamanho ideal para o dispositivo em que está sendo executado. Consulte Imagens de tamanho relativo.
• Use uma CDN de imagem que permita redimensionar dinamicamente uma imagem quando você a solicitar.
• No mínimo, otimize cada imagem. Muitas vezes, isso pode gerar uma economia enorme. Otimização é quando você executa uma imagem por um programa especial que reduz o tamanho do arquivo de imagem. Consulte Otimização de imagens essenciais para mais dicas.

Elimine os recursos que bloqueiam a renderização

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

Um recurso de bloqueio de renderização é um arquivo JavaScript ou CSS externo que o navegador precisa transferir por download, analisar e executar antes de mostrar a página. O objetivo é executar somente o código CSS e JavaScript principal necessários para exibir a página corretamente.

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

1. Clique em Eliminar os recursos de bloqueio de renderização para ver os recursos que estão bloqueando: lodash.js e jquery.js.

   

2. Dependendo do seu sistema operacional, pressione a tecla a seguir para abrir o menu de comando:

   • 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. A guia Cobertura oferece uma visão geral de quanto do código em bundle.js, jquery.js e lodash.js é executado enquanto a página é carregada.

   

   Esta captura de tela diz 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 tiver uma barra verde ao lado dela. 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. Percorra o código jQuery um pouco. Algumas das linhas que são "executadas" são, na verdade, apenas comentários. Executar esse código por meio de 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 somente o código necessário para o carregamento da página.

Os arquivos jquery.js e lodash.js são mesmo necessários para carregar a página? A guia Solicitar bloqueio pode mostrar o que acontece quando os recursos não estão disponíveis.

1. Clique na guia Rede e abra o Menu de comando novamente.

2. Comece a digitar blocking e selecione Mostrar bloqueio de solicitações. A guia Solicitar bloqueio é 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 jQuery e Lodash estão vermelhas, o que significa que foram bloqueadas. A página ainda é carregada e interativa. Por isso, 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 o comportamento da página quando algum recurso não está disponível.

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

1. De volta à 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 recriação e implantação do site outra vez.

4. Audite a página novamente no painel Lighthouse. Sua pontuação geral deve ter melhorado novamente.

   

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

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

• É improvável que você encontre scripts para remover, mas muitas vezes você descobrirá que muitos scripts não precisam ser solicitados durante o carregamento da página e, em vez disso, podem ser solicitados de maneira assíncrona. Consulte Usar assíncrono ou deferir.
• Se você estiver usando um framework, verifique se ele tem um modo de produção. Esse modo pode usar um recurso como o tree shaking para eliminar código desnecessário que está bloqueando a renderização crítica.

Fazer menos trabalho da linha de execução principal

Seu relatório mais recente mostra pequenas economias em potencial na seção Oportunidades, mas se você rolar para baixo até a seção Diagnóstico, parece que o maior gargalo é muita atividade da 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.

O objetivo é usar o painel Performance para analisar o trabalho que a linha de execução principal faz durante o carregamento da página e encontrar maneiras de adiar ou remover trabalhos desnecessários.

1. Abra Performance > Capture Settings e defina Network como Slow 3G e CPU como 6x delay.

   

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

2. Clique em Atualizar. O DevTools recarrega a página e produz uma visualização de tudo que foi necessário fazer para carregar a página. Essa visualização será chamada de trace.

   

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

A parede amarela que você vê na seção Visão geral significa que a CPU estava completamente ocupada com atividades de script. Isso indica que você pode acelerar o carregamento da página fazendo menos trabalho de JavaScript.

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

1. Clique na seção Tempos para expandi-la.

   

   Há várias medições de User Timing do React, e parece que o app de Tony está usando o modo de desenvolvimento dele. Mudar para o modo de produção do React provavelmente vai trazer alguns ganhos de desempenho fáceis.

2. Clique em Tempos novamente para recolher a seção.

3. Procure a 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.

   

   Nesse exemplo, o evento Evaluate Script causou a execução da função (anonymous), o que causou a execução de __webpack__require__, o que levou a execução de ./src/index.jsx e assim por diante.

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

   

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

5. Abra a guia De baixo para cima na parte de baixo. Essa guia detalha as atividades que levaram mais tempo. Se você não vir nada na seção Bottom-Up, clique no marcador da seção Main.

   

   A seção Bottom-Up mostra apenas informações para qualquer atividade ou grupo de atividades que você selecionou no momento. Por exemplo, se você clicou em uma das atividades mineBitcoin, a seção Bottom-Up só vai mostrar informações para essa 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 conferir 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 nova auditoria da página.

   

Remova a chamada para mineBitcoin para reduzir a atividade do JavaScript:

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 nova auditoria da página.

Como sempre, ainda há coisas a fazer, por exemplo, reduzir as métricas Maior exibição de conteúdo e Cumulative Layout Shift.

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

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

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

Resumo

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

Próximas etapas

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

• Registre bugs neste documento no repositório developer.chrome.com.
• Registre 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, use sempre os bugs do Chromium.
• Envie um tweet para @ChromeDevTools.