Como definir orçamentos de desempenho com o webpack

Milica Mihajlija

Atenção: uma ou mais demonstrações nesta página não funcionam mais, porque o Glitch encerrou a hospedagem.

Para acompanhar 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, conforme seu app cresce, os pacotes também crescem. É preciso monitorar os tamanhos dos pacotes para garantir que eles não fiquem muito grandes e afetem o tempo de carregamento do aplicativo. O Webpack permite definir montantes de desempenho com base no tamanho do recurso e pode monitorar os tamanhos de pacote para você.

Para ver isso em ação, confira um app que conta os dias que faltam para o Ano Novo. Ele foi criado com React e moment.js. Assim como os apps do mundo real, que dependem cada vez mais de frameworks e bibliotecas. 😉)

Medida

Este codelab já contém o app empacotado com o webpack.

1. Clique em Remix to Edit para tornar o projeto editável.
2. Clique em Terminal. Observação: se o botão "Terminal" não aparecer, talvez seja necessário usar a opção "Tela cheia".
3. Para ver uma lista de recursos e tamanhos com códigos de cores, digite webpack no console.

webpack

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

Observação: o Webpack usa a unidade "KiB", que talvez você ainda não conheça. 1 "KiB" e 1 "KB" têm tamanhos bem próximos: 1 KiB equivale a 1.024 bytes, enquanto 1 KB equivale a 1.000 bytes.

O Webpack avisa sobre um pacote JS volumoso ⚠️

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

O Webpack avisa sobre um pacote JS volumoso ⚠️

O Webpack não apenas avisa você, mas também dá uma recomendação sobre como reduzir o tamanho dos pacotes. Saiba mais sobre as técnicas recomendadas em Fundamentos da Web.

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

Definir um montante de desempenho personalizado

Um montante de desempenho adequado depende da natureza do seu projeto. É sempre melhor fazer sua própria pesquisa. Uma boa regra geral é 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 montante de desempenho é definido em bytes:

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

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

Os valores possíveis para hints são:

1. warning (padrão): mostra uma mensagem de aviso amarela, mas o build é aprovado. É melhor usar isso em ambientes de desenvolvimento.
2. error: exibe 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 é mostrado.

"Erro" de dica de desempenho do Webpack 🚨

Otimizar

O objetivo de um montante de desempenho é avisar 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 aceleram o carregamento. Muitos deles estão documentados em Como otimizar seu JavaScript. 🤓)

Os frameworks e as bibliotecas facilitam a vida dos desenvolvedores, mas os usuários finais não se importam com a forma como os apps são criados, apenas com a funcionalidade e a velocidade deles. Se você ultrapassar o montante de desempenho, é hora de pensar em possíveis otimizações.

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

Remover códigos não utilizados é uma boa maneira de otimizar apps que incluem grandes bibliotecas de terceiros. O guia para remover código não utilizado explica esse processo em detalhes. Veja 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 fazer algumas contas, mas você pode implementar a mesma contagem regressiva com JavaScript puro:

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.

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

Monitoramento

A configuração de um montante de desempenho no webpack requer apenas algumas linhas de código e avisa se você adicionar (acidentalmente) uma grande dependência. O ditado diz "longe dos olhos, longe do coração", mas o webpack pode garantir que você esteja ciente das implicações de desempenho o tempo todo.