Como definir orçamentos de desempenho com o webpack

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 vê-lo em ação, este é 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. 😉)

Um app que conta os dias restantes até o Ano-Novo

Medir

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

  1. Clique em Remixar para editar 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 ver uma lista de recursos e tamanhos codificado por cores, digite webpack no console.
webpack

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

Saída do Webpack mostrando o tamanho do pacote de 323 KiB
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.

Aviso do Webpack de que o recurso excede o limite de tamanho recomendado
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
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 compactados/minimizados de caminho crítico.

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 do 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): 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.
Erro de desempenho do Webpack em fonte vermelha
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ê estiver 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, 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 um framework ou biblioteca se eles tiverem um impacto significativo na performance.

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

A saída do tamanho do pacote do Webpack após a otimização é de 97,7 KiB

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 da vista, fora da mente" é verdadeiro, mas o Webpack pode garantir que você esteja ciente das implicações de desempenho o tempo todo.