Como definir orçamentos de desempenho com o webpack

O Webpack combina todos os arquivos importados e os compacta em um ou mais arquivos de saída conhecidos como pacotes. O agrupamento é legal, mas, conforme o app cresce, os pacotes também aumentam. É preciso monitorar os tamanhos dos pacotes para garantir que eles não cresçam demais e afetem o tempo de carregamento do aplicativo. O Webpack permite definir orçamentos de performance com base no tamanho do recurso e monitorar os tamanhos dos pacotes.

Para ver como funciona, confira um app que conta os dias restantes até 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. 😉)

Um app que conta os dias 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. 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 codificada por cores de recursos e tamanhos, digite webpack no console.
webpack

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

Saída do Webpack mostrando o tamanho do pacote de 323 KiB
Aviso do Webpack 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 não compactados, tanto para recursos quanto para 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
Aviso do Webpack sobre um pacote JS volumoso ⚠️

O Webpack não apenas vai avisar você, mas também vai dar uma recomendação sobre como reduzir os pacotes. Saiba mais sobre as técnicas recomendadas em Fundamentos da Web.

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

Definir um orçamento de performance personalizado

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

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 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: 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 "erro" do Webpack 🚨

Otimizar

O objetivo de um orçamento de performance é alertar 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 resultam em tempos de carregamento mais rápidos. Muitos deles estão documentados aqui mesmo em 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 que eles sejam funcionais e rápidos. Se você perceber que está ultrapassando o orçamento de performance, é hora de pensar em possíveis otimizações.

No mundo real, é difícil substituir grandes frameworks do lado do cliente. Por isso, é importante usá-los com sabedoria. Com um pouco de pesquisa, é possível encontrar alternativas menores para bibliotecas conhecidas que funcionam tão bem quanto (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ó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. Aqui está 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 um pouco de matemática, mas é possível 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 de novo para criar o pacote otimizado.

Tchan! 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

Configurar um orçamento de performance no webpack leva apenas algumas linhas de código e avisa se você adicionar (acidentalmente) uma dependência grande. O ditado diz "o que os olhos não veem, o coração não sente", mas o webpack pode garantir que você esteja ciente das implicações de performance em todos os momentos.