JavaScriptの整形と圧縮（minify）の使い分け｜開発と配信で目的が違う

結論

• 整形（format/prettify）= 人間が読むため
• 圧縮（minify）= 機械が転送・解釈するため

目的が違うので、両方やる必要はあるが「同時に使う」ものではありません。

---

整形と圧縮、それぞれの目的

観点	整形（Prettier）	圧縮（Terser）
目的	読みやすさ	転送量削減・初期表示高速化
改行	あり	なし
インデント	あり	なし
変数名	元のまま	a, b, c に短縮
コメント	残る	削除
出力サイズ	元と同等〜大きい	元の30〜70%
デバッグ	容易	困難（要source map）

整形と圧縮は逆方向の処理です。整形は冗長性を増やし、圧縮は冗長性を削ります。

---

使い分けの判断基準

整形が必要な場面

• 他人が書いたコードを読む
• ペアプロ・コードレビュー
• 1行で出力されたミニファイ済みJSを解析する
• Gitのdiffを見やすくしたい
• チーム内でフォーマットを統一したい

開発作業の99%は「整形」側です。

---

圧縮が必要な場面

• 本番Webサイトに配信する
• CDN経由で大量配信する
• メール用に小さくしたい
• バンドラを使わずデプロイする小規模スクリプト

開発中は不要。**「リリース直前にだけ通す」**が基本です。

---

「整形してから圧縮」の順番について

ツール上では入力 → 整形 or 圧縮の二択ですが、実務では:

ソース（人間が書く）
   ↓ 整形（コミット時）
   ↓ 圧縮（ビルド時）
配信ファイル

の流れになります。整形済みのコードをGitに保存し、CI/CDで圧縮版を生成して配信、というのが定石。

JS Formatter では入力に対してどちらか一方を実行するため、整形→圧縮を続けてやりたい場合は「整形 → 出力をコピー → 入力欄に戻す → 圧縮」という流れになります。

---

よくある勘違い

「整形すれば速くなる」

逆。整形するとファイルが大きくなるため、配信は遅くなります。整形は人間のための行為で、ブラウザの実行速度には影響しません。

---

「圧縮すればコードが安全になる」

NO。圧縮は変数名を短縮するだけで、暗号化ではありません。誰でも整形し直せば構造が読めます。秘匿したい情報は圧縮ではなくサーバー側に置きましょう。

---

「圧縮するとバグるかも」

Terserは仕様準拠なので、原則バグりません。ただし以下は注意:

• eval() で関数名や変数名に依存している
• arguments.callee を使っている
• グローバルなクラス名を文字列で参照している（DI / DOMバインディング）

これらは mangle が変数名を変えると壊れる可能性があります。心当たりがある場合は圧縮後に動作確認を。

---

用途別の推奨

用途	整形	圧縮
ローカル開発	◎	×
GitHubコミット	◎	×
ステージング配信	△	◎
本番配信	×	◎
緊急のホットフィックス	◎	△

---

関連記事

• JS Formatterの使い方 — 操作の入門
• Terserの圧縮で何が削られるのか — minify結果の中身

---

整形と圧縮は別物。混同しなければ迷うことはありません。