コードMinify：何をして、いつ手間をかけるべきか

JavaScriptファイルが500KBです。Minify後、150KBになります。ファイルの70%はどこに行ったのでしょう？

ほとんどは空白、コメント、長い変数名。人間には必要だがブラウザには不要なもの。

Minifyが削除するもの

空白。 インデント、空白行、余分なスペース。ブラウザには不要。

コメント。 開発者には便利、ブラウザには不可視。消滅。

長い名前。 calculateTotalPrice が a になります。customerData が b に。同じロジック、より少ない文字。

デッドコード。 一部のminifierは実行されないコードを削除します。

実際の削減量

JavaScriptの場合：

• 空白とコメント：30-50%のサイズ削減
• 変数のリネーム：さらに10-30%
• デッドコード削除：大きく変動

CSSの場合：

• ほとんど空白とコメント
• セレクターの短縮は役立つがリスクあり（他の要素にマッチするかも）

HTMLの場合：

• 劇的な効果は少ない
• 通常は空白削除のみ

Minifyすべき時

本番ウェブサイト。 常に。より速い読み込み時間、より良いユーザー体験、より低い帯域幅コスト。

APIレスポンス。 時々。JSONのminifyは帯域幅を節約しますが、デバッグを難しくします。

内部ツール。 多分。開発速度が読み込み時間より重要かもしれません。

Minifyすべきでない時

開発環境。 minifyされたコードのデバッグは苦痛。ソースマップを保持するか、開発中はminifyしない。

可読性要件。 一部のオープンソースプロジェクトは教育目的で読めるコードを保持。

極小ファイル。 1KBファイルのminifyはほとんど節約せず、ビルドの複雑さを追加。

Minifyを超えて

Gzip/Brotli圧縮。 minifyされたコードはさらに圧縮されます。ほとんどのサーバーがこれを自動で処理。

コード分割。 各ページに必要なコードのみ読み込み。1つの巨大なminifyバンドルより良い。

Tree shaking。 バンドラーが未使用のエクスポートを削除。必要なものだけインポート。

これらのテクニックを組み合わせます。Minifyして、圧縮して、インテリジェントに分割。

ソースマップ

minifyされたコードは読めません。a.b(c,d) はデバッグ中に何も教えてくれません。

ソースマップはminifyコードを元のソースに接続します。ブラウザの開発ツールはminifyコードを実行しながら読めるコードを表示します。

開発環境ではソースマップを保持。本番へのデプロイは、ユーザーにソースコードを見せたいかどうかで判断。

よくある問題

壊れた変数名。 minifierは時々維持する必要がある名前（文字列内のAPIキーなど）を壊します。除外を設定しましょう。

順序依存のCSS。 積極的なCSS minifyはルールを並べ替え、スタイルのカスケード方法を変えるかもしれません。

非同期の問題。 積極的なデッドコード削除は動的に読み込むコードを壊すかもしれません。

デプロイ前にminifyビルドをテストしましょう。minify前に動いたものが処理後に壊れることがあります。

---

Minifyは安価なパフォーマンス。ビルドツールが自動で処理。一度設定すれば、永遠に小さなファイルを享受できます。