Minificar JavaScript

Renomear, remover e o que nunca pode ser tocado

Acontecem três coisas, em ordem crescente de quanto economizam e de quanto custam para você. Espaços em branco e comentários saem, o que não custa nada. Código morto sai — um ramo que nunca pode ser executado, uma variável atribuída e nunca lida. E os nomes locais são encurtados, então um calculateMonthlyTotal cuidadosamente nomeado vira uma única letra. É nesta última etapa que está a maior parte do ganho, e é também ela que deixa o resultado ilegível — o que serve para publicar e não serve para depurar.

O que não pode ser renomeado é tudo aquilo a que o mundo externo se refere pelo nome, e errar nisso é como minificadores quebram código. Funções exportadas, propriedades de objetos acessadas como strings, tudo o que é alcançado por window e nomes usados em eval precisam sobreviver intactos, porque algo em outro lugar os procura pelo nome que você escreveu. As propriedades, em especial, ficam intactas por padrão: renomear user.emailAddress quebraria tudo no momento em que esse objeto fosse serializado em JSON ou lido por um código minificado separadamente.

Guarde um source map ou o original. Depois que os nomes somem, um stack trace de um usuário real aparece como um erro na função t no caractere 48.213, o que não diz absolutamente nada. Um source map restaura os nomes e os números de linha originais no depurador e nos relatórios de erro, e gerar um não custa nada, porque ele é publicado como um arquivo separado que só carrega quando alguém abre as ferramentas de desenvolvedor.

Os comentários de licença são mantidos por padrão, e isso é uma questão jurídica, não uma preferência. Muito código aberto tem licença permissiva com uma única condição: que o aviso de copyright vá junto com ele — MIT e BSD dizem isso explicitamente. Tirar esses comentários de um bundle com código de terceiros coloca você em violação da licença que permitiu usá-lo. São algumas centenas de bytes.

Quando você precisa de outra coisa

Isso deve ficar no build, não em uma aba do navegador, e os bundlers modernos fazem isso naturalmente. O esbuild --minify e o Rollup ou o Vite minificam no build, geram source maps automaticamente e — o que é muito mais importante — fazem tree shaking, descartando as exportações das suas dependências que você nunca importa. Em uma aplicação real, isso economiza muito mais do que minificar um arquivo pronto jamais conseguiria.

Antes de otimizar, meça. Um analisador de bundle geralmente revela que uma única dependência grande responde pela maior parte do arquivo — uma biblioteca de datas, um conjunto de ícones, um pacote de gráficos importado inteiro por causa de um único gráfico. Substituir essa dependência ou carregá-la sob demanda vale mais do que qualquer minificação, e o code splitting, para que cada página carregue só o que precisa, vale mais do que as duas coisas.