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

Você deve ter experiência básica em desenvolvimento da Web, semelhante ao que é ensinado esta aula de introdução ao desenvolvimento na 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 construiu um site para os fãs saberem qual é o conteúdo favorito dele. alimentos. Os fãs adoram o site, mas Tony continua ouvindo reclamações de que o carregamento lento do site. 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 um auditoria. A auditoria tem duas funções importantes:

• Ele cria uma linha de base para você avaliar 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 Site do Tony, para que você possa fazer alterações 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 Visualização > Visualize 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 opções diferentes:

   • 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 está disponível no menu more_vert Ferramentas > Visualizar rastreamento não limitado depois que o relatório 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 "simulação", porque o Lighthouse não faz limitações 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. 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.

   

Como lidar com erros de relatórios

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ê está que executam o Chrome de um estado limpo. As extensões do Google Chrome, em particular, 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, quando você e 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, First Contentful Paint informa quando o conteúdo é pintado pela primeira vez na tela, que é um marco importante na experiência do usuário do carregamento da página, enquanto o Tempo até a interação marca o ponto em que a página parece estar pronto 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 dá dicas específicas sobre como melhorar o carregamento dessa página específica. desempenho.

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 informações específicas e recomendações sobre como corrigi-lo.

Diagnóstico

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

Auditorias aprovadas

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

Etapa 2: experimento

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

Ativar a compactação de texto

Seu relatório afirma que ativar a compactação de texto é uma das principais oportunidades para melhorar a o desempenho 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 em uma rede VPC. 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 o texto os recursos sejam compactados.

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

Cada célula Size mostra dois valores. O valor superior é o tamanho do recurso transferido por download. A o valor inferior é o tamanho do recurso descompactado. Se os dois valores forem iguais, o não está sendo compactado ao ser enviado pela rede. Neste exemplo, os valores superior e inferior 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 verá um, 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 as Diretivas para conferir uma explicação sobre esses e a distribuição dos valores dos dados.

Chega de explicações. É hora de fazer algumas mudanças! Ative a compactação de texto adicionando algumas de 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 carregamento da página desempenho:

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 fazer uma pesquisa sobre como para configurar qualquer servidor usado 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 for visualizar as imagens em uma tela de dispositivo móvel com 500 pixels de largura, não faz sentido em enviando uma imagem de 1.500 pixels de largura. O ideal seria enviar uma imagem de 500 pixels de largura, no máximo.

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, uma coisa que a pontuação não mostre claramente a quantidade de dados de rede que você está economizando para seus usuários. O total das fotos antigas tinha cerca de 6,1 MB, mas agora tem apenas cerca de 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, 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. A otimização ocorre quando Você executa uma imagem em um programa especial que reduz o tamanho do arquivo. Consulte a seção Essentials Otimização de imagens 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 fazer o download. analisar e executar antes de mostrar a página. O objetivo é executar apenas o CSS e o JavaScript principais que é necessário 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 a renderização: 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 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 era executada se tiver uma barra verde ao lado. Uma barra vermelha ao lado de uma linha de código significa que ela não foi executada necessárias no carregamento da página.

   

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

Resumindo, quando você trabalha com seu próprio código, a guia Cobertura pode ajudar a analisar seu 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? Na guia Bloqueio de solicitação, é possível mostram 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 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 o comportamento da sua página quando qualquer 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, você podem acelerar o carregamento da página enviando somente códigos críticos durante o carregamento da página e, em seguida, o carregamento lento todo o resto.

• É improvável que você encontre scripts que possa remover imediatamente, mas, muitas vezes, descobrirá que muitos scripts não precisam ser solicitados durante o carregamento da página e podem, em vez disso, ser solicitados de forma 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 tree shaking, para eliminar código desnecessário que bloqueia 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 a tela até a seção Diagnóstico, parece que o maior gargalo é a linha de execução principal. atividades.

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 execução de HTML, CSS e JavaScript.

O objetivo é usar o painel Performance para analisar o trabalho da linha de execução principal enquanto o carregamentos de página e encontrar formas de adiar ou remover trabalhos desnecessários.

1. Abra Desempenho > Configurações de captura e defina Rede como 3G lento e CPU como lentidão 6x.

   

   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ê experimente o carregamento da página como se estivesse usando um dispositivo menos potente.

2. Clique em Atualizar 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 no dão uma visão geral dos quadros por segundo, da atividade da CPU e 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. Essa 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. Ao usar uma estrutura, 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ê tenha está selecionada no momento. Por exemplo, se você clicou em uma das atividades mineBitcoin, a A seção Bottom-Up mostra informações apenas 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 ver se o modo de produção é usado e se a atividade do JavaScript é reduzida acelera 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 serem feitas, 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 forma mais comum de entender qual atividade seu site realiza enquanto ele carrega 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 certas fases do ciclo de vida do app, para rastrear quanto tempo cada uma delas fases demora.

Resumo

• Sempre que você optar por otimizar o desempenho de carregamento de um site, comece sempre com para uma auditoria. A auditoria estabelece uma linha de base 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 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.