Lighthouse: otimize a velocidade do site

Kayce Basques
Kayce Basques
Sofia Emelianova
Sofia Emelianova

Visão geral

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

  • Desempenho
  • Acessibilidade
  • Práticas recomendadas
  • SEO

… e muitas outras métricas.

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

Para saber mais sobre como o Lighthouse pode melhorar a qualidade do site, consulte a documentação do Lighthouse.

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

Aqui é 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.

Tony, o gato.

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 base de referência para medir as próximas mudanças.
  • 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 Site do 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. Ela será chamada de guia do editor.

    A fonte original e a guia do editor depois de clicar em "Remix".

    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ê 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. Essa guia será chamada de guia de demonstração. Pode levar um tempo até que o site seja carregado.

    A guia "Demonstração".

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

    DevTools e 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 Mais painéis.

    O painel do Lighthouse.

  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:

    • 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.
    • Ativar 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 trace está disponível no menu Ferramentas > Visualizar rastreamento não limitado depois que o relatório Lighthouse é gerado. Trace de desempenho sem (esquerda) e com amostragem de JS (direita).
    • 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 "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, 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 é disso que precisamos neste tutorial. Para mais informações, consulte Os três modos.
    • Dispositivo > 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 > 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. Após 10 a 30 segundos, o painel do Lighthouse mostra um relatório sobre a performance do site.

    Um relatório do Lighthouse sobre o 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 particular, podem interferir no processo de auditoria.

Um relatório com um erro.

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.

A pontuação geral de desempenho.

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

Na seção "Métricas".

Esta seção fornece medições quantitativas da performance 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.

Capturas de tela da aparência da página durante o carregamento.

Oportunidades

A seguir, a seção Oportunidades, que dá dicas específicas sobre como melhorar o carregamento dessa página específica. desempenho.

A seção "Oportunidades".

Clique em uma oportunidade para saber mais sobre ela.

Mais informações sobre a oportunidade de compactação de texto.

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.

Seção "Diagnóstico".

Auditorias aprovadas

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

A seção "Auditorias aprovadas".

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, confira algumas maneiras de verificar manualmente se os recursos de texto estão compactados.

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

A coluna "Tamanho" no painel "Rede" mostrando linhas grandes de solicitação.

Cada célula Size mostra dois valores. O valor superior é o tamanho do recurso transferido por download. O 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.

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.

    A guia "Cabeçalhos".

  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 valores.

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

    Editando o server.js.

  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 Tamanho agora mostra dois valores diferentes para recursos de texto, como bundle.js. O valor máximo de 269 KB para bundle.js é o tamanho do arquivo enviado pela rede, e o valor mínimo de 1.4 MB é o tamanho do arquivo não compactado.

    A coluna "Tamanho" agora mostra dois valores diferentes para recursos de texto.

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

    A seção "Response Headers" agora contém um cabeçalho de codificação de conteúdo.

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 Adicione a solução Realizar uma auditoria... na barra de ações na parte de cima.

    O botão "Executar uma auditoria".

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

    Um relatório do Lighthouse após ativar a compactação de texto.

Uhuuu! Parece que está progredindo. 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 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 do que o necessário.

    Detalhes sobre "as imagens com o tamanho adequado" oportunidade

  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.

    Um relatório do Lighthouse depois de redimensionar as imagens.

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 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 de baixo do painel Rede.

Quantidade de dados transferidos antes e depois de redimensionar imagens.

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 um CDN de imagem que permita redimensionar dinamicamente uma imagem quando você a solicitar.
  • Pelo menos, 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 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 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 precisa 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.

    Mais informações sobre "reduzir recursos de bloqueio de renderização" oportunidade.

  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.

    Como abrir o Command Menu no painel do Lighthouse.

    A guia Cobertura é aberta na Gaveta.

    A guia Cobertura.

  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.

    O relatório de cobertura.

    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.

    Visualização do arquivo jQuery no painel Origens.

  6. Percorra o código jQuery um pouco. 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.

Resumindo, quando você trabalha com seu próprio código, a guia Cobertura pode ajudar a analisar seu código, linha por linha e só enviar 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 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 Menu de comando novamente.
  2. Comece a digitar blocking e selecione Mostrar bloqueio de solicitações. A guia Solicitar bloqueio é aberta.

    A guia "Bloqueio de solicitações".

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

    Adicionando um padrão para bloquear qualquer solicitação ao elemento "libs" diretório.

  4. Recarregue a página. As solicitações jQuery e Lodash estão vermelhas, 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.

    O painel Network mostra que as solicitações foram bloqueadas.

  5. Clique em Remover. 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.

    Um relatório do Lighthouse após a remoção dos recursos bloqueadores de renderização.

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 apenas 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 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 assíncrono ou deferir.
  • Se você estiver usando uma framework, verifique se ela tem um modo de produção. Esse modo pode usar um recurso como como 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 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 execução de HTML, CSS e JavaScript.

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

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

    Configurações de limitação da CPU e da rede no painel &quot;Performance&quot;

    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. 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 rastreamento do carregamento de página do painel &quot;Desempenho&quot;.

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 seção Visão geral do trace.

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

    A seção &quot;Tempos&quot;.

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

    A seção principal.

    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.

    A atividade mineBitcoin.

    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.

    Guia Bottom-Up.

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

    Um relatório do Lighthouse após configurar o webpack para usar o modo de produção.

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.

Um relatório do Lighthouse após a remoção de trabalhos desnecessários do JavaScript.

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 Performance é a maneira mais comum de entender a atividade do seu site enquanto ele é carregado 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 comece com uma auditoria quando for otimizar a performance de carregamento de um site. A auditoria estabelece uma linha de base 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 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.