Como definir orçamentos de desempenho com o webpack

Milica Mihajlija

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 o app cresce, seus pacotes também crescem. É necessário monitorar os tamanhos de pacote para garantir que eles não cresçam demais e afetem o tempo de carregamento do aplicativo. O Webpack oferece suporte à definição de montantes de performance com base no tamanho do recurso e pode monitorar os tamanhos de pacotes para você.

Para conferir em ação, confira um app que conta os dias restantes até o Ano Novo. Ele foi criado com React e moment.js. Assim como apps reais que dependem cada vez mais de frameworks e bibliotecas. 😉)

Medir

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

1. Clique em Remix to Edit para tornar o projeto editável.
2. Clique em Terminal. Se o botão "Terminal" não aparecer, talvez seja necessário usar a opção "Tela cheia".
3. Para acessar uma lista codificada por cores de recursos e seus tamanhos, digite webpack no console.

webpack

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

Observação : o Webpack usa a unidade "KiB", que talvez você não tenha visto antes. O tamanho de 1 "KiB" e 1 "KB" é bastante semelhante: 1 KiB é igual a 1024 bytes, enquanto 1 KB é igual a 1000 bytes.

O Webpack está alertando sobre o pacote JS volumoso ⚠️

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

O Webpack está alertando sobre o pacote JS volumoso ⚠️

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

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

Definir um orçamento de performance personalizado

Um orçamento de performance adequado depende da natureza do seu projeto. É sempre melhor fazer sua própria pesquisa. Uma boa regra é enviar menos de 170 KB de recursos de caminho crítico compactados/minimizados.

Observação : os recursos do 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 definir 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:

• 100000 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 dicas são:

1. warning (padrão): exibe uma mensagem de aviso amarela, 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 é mostrado.

Dica de desempenho do Webpack "error" 🚨

Otimizar

O objetivo de um orçamento de performance é avisar sobre problemas de performance 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 tempo de carregamento. Muitas delas estão documentadas aqui em Otimizar seu JavaScript. 🤓)

Frameworks e bibliotecas facilitam a vida dos desenvolvedores, mas os usuários finais não se importam muito com a criação dos apps, apenas se eles são funcionais e rápidos. Se você ultrapassar 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, portanto, é importante usá-los com sabedoria. Com um pouco de pesquisa, é possível encontrar alternativas menores para bibliotecas conhecidas que fazem o trabalho tão bem quanto date-fns é uma boa alternativa para moment.js. Às vezes, faz mais sentido não usar uma estrutura ou biblioteca se ela tiver um impacto significativo no desempenho.

Remover o código não usado é uma boa maneira de otimizar apps que incluem grandes bibliotecas de terceiros. O guia "Remover código não usado" explica esse processo em detalhes. Confira uma maneira rápida de reprogramar o código da 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 básico:

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 orçamento de performance no Webpack leva apenas algumas linhas de código e avisa se você adicionar (acidentalmente) uma grande dependência. O ditado "fora de vista, fora de mente" é verdadeiro, mas o Webpack pode garantir que você esteja ciente das implicações de desempenho o tempo todo.