Como definir orçamentos de desempenho com o webpack

Milica Mihajlija

Para continuar este codelab, abra este Glitch em uma segunda guia.

O Webpack combina todos os arquivos importados e os empacota em um ou mais arquivos de saída conhecidos como pacotes. O agrupamento é ótimo, mas, à medida que o app cresce, os pacotes também aumentam. Você precisa monitorar os tamanhos dos pacotes para garantir que eles não fiquem muito grandes e afetem o tempo de carregamento do aplicativo. Com ele, é possível definir orçamentos de performance com base no tamanho do recurso e monitorar o tamanho dos pacotes para você.

Para vê-lo em ação, aqui está um app que conta os dias até o Ano Novo. Ele foi criado com o React e o moment.js. Assim como apps reais que dependem cada vez mais de frameworks e bibliotecas. 😉)

Medida

Este codelab já contém o app incluído no webpack.

1. Clique em Remixar para editar para tornar o projeto editável.
2. Clique em Terminal. Observação: se o botão "Terminal" não for exibido, talvez seja necessário usar a opção "Tela cheia".
3. Para conferir uma lista de recursos codificado por cores e os tamanhos deles, digite webpack no console.

webpack

O pacote principal está destacado em amarelo por ser maior que 244 KiB (250 KB).

Observação : o Webpack usa a unidade "KiB", que talvez você não tenha visto antes. O tamanho de 1 "KiB" e 1 "KB" é bem próximo: 1 KiB equivale a 1.024 bytes, enquanto 1 KB equivale a 1.000 bytes.

Aviso do Webpack sobre o pacote JS volumoso ⚠️

Esses avisos são ativados por padrão no modo de produção, e o limite padrão é 244 KiB descompactado para recursos e pontos de entrada (a combinação de todos os recursos usados durante o carregamento inicial de uma página).

Aviso do Webpack sobre pacotes JS volumosos ⚠️

Além de alertar você, o Webpack também fornece recomendações sobre como reduzir o tamanho dos pacotes. Saiba mais sobre as técnicas recomendadas nos Fundamentos da Web.

Recomendação de otimização de performance do Webpack 💁

Definir um orçamento de performance personalizado

Um orçamento de desempenho apropriado dependerá da natureza do seu projeto. É sempre melhor fazer sua própria pesquisa. Uma boa regra é fornecer menos de 170 KB de recursos de caminho crítico compactados/minificados.

Observação : os recursos de caminho crítico são o conjunto mínimo de recursos necessários para que o navegador mostre o conteúdo da primeira tela.

Para esta demonstração simples, tente ser ainda mais conservador e defina o orçamento como 100 KB (97,7 KiB). Em webpack.config.js, inclua o seguinte:

module.exports = {
  //...
  performance: {
    maxAssetSize: 100000,
    maxEntrypointSize: 100000,
    hints: "warning"
  }
};

O novo orçamento de performance é definido em bytes:

• 100.000 bytes para recursos individuais (maxAssetSize)
• 100.000 bytes do ponto de entrada (maxEntrypointSize)

Nesse caso, há apenas um pacote que também atua como ponto de entrada.

Os valores possíveis para hints são:

1. warning (padrão): mostra uma mensagem de aviso em amarelo, mas o build é aprovado. É melhor usar isso em ambientes de desenvolvimento.
2. error: mostra uma mensagem de erro vermelha, mas o build ainda é aprovado. Essa configuração é recomendada para builds de produção.
3. false: nenhum aviso ou erro é exibido.

Dica de desempenho do Webpack "erro" 🚨

Otimizar

O objetivo de um orçamento de performance é alertar você sobre problemas de desempenho antes que eles se tornem muito difíceis de corrigir. Sempre há mais de uma maneira de criar um app, e algumas técnicas aumentam o tempo de carregamento. Muitos deles estão documentados aqui em Como otimizar o JavaScript. 🤓)

Frameworks e bibliotecas facilitam a vida dos desenvolvedores, mas os usuários finais não se importam realmente com a forma como os apps são criados, apenas pelo fato de serem funcionais e rápidos. Se você ficar ultrapassando o orçamento de performance, é hora de pensar em possíveis otimizações.

No mundo real, grandes frameworks do lado do cliente geralmente são difíceis de trocar, por isso é importante usá-los com sabedoria. Com um pouco de pesquisa, muitas vezes é possível encontrar alternativas menores para bibliotecas conhecidas que funcionam bem (date-fns é uma boa alternativa para moment.js). Às vezes, faz mais sentido não usar um framework ou uma biblioteca se isso tiver um impacto significativo no desempenho.

Remover o código não utilizado é uma boa maneira de otimizar apps que incluem grandes bibliotecas de terceiros. O guia "Remover código não utilizado" explica esse processo em detalhes e apresenta uma maneira rápida de reescrever o código de contagem regressiva sem usar o moment.js.

Em app/components/Countdown.jsx, remova:

const today = moment();
const yearEnd = moment().endOf('year');
const daysLeft = yearEnd.diff(today, 'days');

E exclua esta linha:

const moment = require('moment');

É preciso um pouco de matemática, mas você pode implementar a mesma contagem regressiva com o JavaScript baunilha:

const today = new Date();
const year = today.getFullYear();
const yearEnd = new Date(year,11,31); //months are zero indexed in JS
const timeDiff = Math.abs(yearEnd.getTime() - today.getTime());
const daysLeft = Math.ceil(timeDiff / (1000 * 3600 * 24));

Agora, remova moment.js de package.json e execute o webpack no console novamente para criar o pacote otimizado.

Pronto! Você reduziu 223 KiB (230 KB) e o app está dentro do orçamento.🎉

Monitoramento

Configurar um orçamento de desempenho no webpack requer apenas algumas linhas de código e ele vai avisar se você adicionar uma grande dependência por engano. Isso está "fora da vista, fora da mente", mas o webpack pode garantir que você esteja ciente das implicações de desempenho o tempo todo.