序章：なぜフロントエンドの「最終の削り」にこだわるのか
テックリードとして多くのモダンWebアプリケーションのコードベースを見てきたが、CI/CDパイプラインの最後の関門である「バンドルサイズの最適化」を軽視しているプロジェクトは非常に多い。
「機能が動けば正義」「gzipやBrotliがなんとかしてくれる」――そう考えてWebpackのデフォルト設定を放置していないだろうか？
現代のWebフロントエンドにおいて、JavaScriptの肥大化はそのまま「TBT（Total Blocking Time）」の悪化、「INP（Interaction to Next Paint）」の劣化、そして最悪の場合は「コンバージョン率の低下」に直結する。ネットワーク転送量が減るだけでなく、巨大なJSファイルをパース・コンパイルするメインスレッドのコスト自体がモバイルデバイスの寿命を削っているのだ。
今回は、Webpackエコシステムの最終防衛ラインであるMinifier（圧縮ツール）にスポットを当て、長年の王様である `TerserPlugin` の深部（ASTレベルのチューニング）と、次世代の破壊的スピードを持つ `esbuild-loader` による超高速圧縮への切り替えを、実務レベルのコードと共に徹底比較する。
—
1. TerserPluginの深層：ASTをハックしてバイト数を極限まで削る
Webpack 5の標準である `TerserPlugin` は、単なる「スペースや改行の削除ツール」ではない。抽象構文木（AST: Abstract Syntax Tree）を解析し、セマンティクス（意味論）を保ったままコードを極限まで変形・破壊するオプティマイザーである。
実務でプロダクトのバンドルサイズをもう一段階削り落とすためには、`terser-webpack-plugin` の `compress` および `mangle` オプションの内部挙動を理解し、プロジェクトの特性に合わせてネジを巻き直す必要がある。
プロダクトの限界を引き出す webpack.config.ts のベストプラクティス
以下の設定は、安全性（ランタイムエラーの回避）を担保しつつ、AST変形を極限まで攻めたプロダクション用の設定例だ。
import { Configuration } from ‘webpack’;
import TerserPlugin from ‘terser-webpack-plugin’;
const productionConfig: Configuration = {
mode: ‘production’,
// ソースマップは本番では別ファイル（hidden-source-map等）にするか、
// 完全非公開ならfalseにしてASTへの負荷とファイルサイズを削減
devtool: ‘hidden-source-map’,
optimization: {
minimize: true,
minimizer: [
new TerserPlugin({
// マルチプロセス並列実行を有効化し、CIでのビルド時間を劇的に短縮する
parallel: true,
terserOptions: {
ecma: 2020, // 出力するECMAScriptのターゲットバージョン
compress: {
// 到達不可能なコード（Dead Code）の徹底的な排除
dead_code: true,
// デバッグ用のconsole.を本番ビルドから完全に消し去る
// ※ errorやwarnは残したい場合はカスタム関数で制御
drop_console: true,
drop_debugger: true,
// 巻き上げ（Hoisting）やインライン化の積極化
passes: 3, // 圧縮パスの回数（デフォルトは1。2〜3回回すとさらにサイズが削れるがビルド時間は伸びる）
// 条件分岐の評価と最適化（例: if (true) の簡略化）
conditionals: true,
// 評価可能な式を定数に置き換える（例: 1 + 2 -> 3）
evaluate: true,
// 使用されていない関数や変数を削除
unused: true,
// 破壊的な最適化：純粋関数（副作用のない関数）の呼び出し結果を破棄する
// ※ Babelの /#__PURE__/ アノテーションと連携して真価を発揮する
pure_funcs: [‘console.info’, ‘Math.floor’],
},
mangle: {
// スコープ内の変数名・関数名を極限まで短くする（例: userCount -> a）
toplevel: true, // トップレベルの変数名も難読化・短縮化
eval: true, // eval()内の変数名も難読化
// 保持したい変数名・プロパティ名がある場合はここフックする
reserved: [‘__REACT_DEVTOOLS_GLOBAL_HOOK__’],
},
format: {
// コメントをすべて削除（ライセンスコメントを除去）
comments: false,
// 出力されるコードの美しさよりも圧縮率を優先
ascii_only: true,
},
},
// terserがライセンスコメントを別ファイル（.LICENSE.txt）に抽出するのを防ぐ
extractComments: false,
}),
],
},
};
export default productionConfig;
ここがプロの知見：`passes: 3` と `pure_funcs` の破壊力
デフォルトの `terserOptions.compress` は安全性に配慮して `passes: 1` で動作している。しかし、モジュールが複雑に絡み合う巨大なSPAでは、1回目の圧縮で露わになった「使わなくなった変数や分岐」が、2回目・3回目のパスでさらに連鎖的に消えていく。`passes: 3` に設定するだけで、バンドルサイズが追加で 1.5% 〜 3% 削れるケースが多々ある。
また、`pure_funcs` に自前のロガーやユーティリティ関数（例: `logger.debug` など）を指定しておけば、`/#__PURE__/` アノテーションと共に用いることで、使われていないユーティリティのコードブロックをごっそりASTから切り落とすことが可能になる。
—
2. 時代はEsbuildへ：超高速圧縮への切り替え手順と注意点
Terserは強力だが、AST解析と多重パス（`passes > 1`）の実行において、どうしてもCPUバウンドなボトルネック（ビルド時間の増大）を抱えてしまう。
そこで現代のハイパフォーマンチームが採用しているのが、Go言語製で驚異的なスピードを誇る `esbuild` をWebpackのMinifierとして利用する手法だ（`esbuild-loader` または `terser` の代わりに `esbuild` を使う）。
Esbuildによるビルド時間の劇的短縮とトレードオフ
- メリット: Terserと比較してビルド速度が10倍〜100倍になる。CI/CDのランニングコスト（GitHub Actions等の分単位の課金）を直撃で削減できる。
- デメリット: Terserほど細かなAST変形オプション（高度なデッドコードの連鎖削除など）はないため、最終的なバンドルサイズがTerser（passes: 3）に比べて 0.5%〜2% ほど大きくなる傾向がある。
「数パーセントのサイズ増を受け入れてでもCIの爆速化をとるか、ビルド時間を犠牲にして極限までバイト数を削るか」――これがテックリードとしての重大なアーキテクチャ判断になる。
`esbuild-loader` を用いた実装パターン
もしあなたが「CIのスピードと十分な圧縮率」のバランスを重視するなら、以下の設定に移行すべきだ。
import { Configuration } from ‘webpack’;
import { EsbuildPlugin } from ‘esbuild-loader’;
const esbuildProdConfig: Configuration = {
mode: ‘production’,
optimization: {
minimize: true,
minimizer: [
new EsbuildPlugin({
target: ‘es2020’, // トランスパイルおよびミニファイのターゲット
css: true, // CSSの圧縮もesbuildに任せる（css-minimizer-webpack-pluginが不要に）
legalComments: ‘none’, // コメントを完全に排除
}),
],
},
};
export default esbuildProdConfig;
—
3. チーム開発の生産性を爆発させる「神プラグイン」と「設定共有化ルール」
どれだけ優れたMinifier設定を行っても、それがローカル開発環境や個人のPC依存になっていては意味がない。チーム全体でクオリティとパフォーマンスの基準を強制するための仕組みを解説する。
1. 絶対入れるべき神プラグイン：`webpack-bundle-analyzer`
「どこがバンドルを肥大化させているのか」を視覚化できなければ、Minifierのチューニングも暗闇での射撃になる。本番ビルド時に自動でツリーマップを生成し、CI上で異常検知する仕組みを構築する。
import { BundleAnalyzerPlugin } from ‘webpack-bundle-analyzer’;
// plugins配列に追加
plugins: [
new BundleAnalyzerPlugin({
analyzerMode: process.env.ANALYZE === ‘true’ ? ‘server’ : ‘disabled’,
// CI環境では静的HTMLとしてレポートを出力し、後続のステップでアーティファクトとして保存する
analyzerMode: process.env.CI === ‘true’ ? ‘static’ : ‘disabled’,
reportFilename: ‘bundle-report.html’,
openAnalyzer: false,
}),
]
開発スピードを上げる隠しコマンド（`package.json` の秘伝のタレ）
{
“scripts”: {
“build:prod”: “NODE_ENV=production webpack –config webpack.config.ts”,
“analyze”: “ANALYZE=true npm run build:prod”
}
}
このコマンドを叩くだけで、ブラウザに「どのライブラリ（例: `lodash`, `moment`, 巨大なアイコンライブラリなど）が容量を圧迫しているか」の地図が即座に描画される。チームメンバー全員がこの視覚的フィードバックを得られる環境を作ることで、「重いライブラリを安易にインポートしない」という文化が自然と醸成される。
2. チーム開発で絶対守るべき設定の共有化ルール（JSON/Configアーキテクチャ）
プロダクトが複数（マイクロフロントエンドや、複数Webアプリのモノレポ構造）に分かれている場合、Webpackのoptimization設定が各リポジトリでバラバラになるのは最悪のアンチパターンだ。
共通の最適化プリセットを `@company/webpack-preset` のようなプライベートNPMパッケージ（またはモノレポ内の内部パッケージ）として切り出し、各アプリからは以下のように薄いラッパーとして設定を呼び出すルールを徹底する。
共有設定パッケージ側のコード（イメージ）
// @company/webpack-preset/index.ts
import { Configuration } from ‘webpack’;
import TerserPlugin from ‘terser-webpack-plugin’;
export function createBaseOptimization(isProduction: boolean): Configuration[‘optimization’] {
if (!isProduction) {
return { minimize: false };
}
return {
minimize: true,
minimizer: [
new TerserPlugin({
parallel: true,
terserOptions: {
ecma: 2020,
compress: {
drop_console: true,
passes: 2,
pure_funcs: [‘console.info’],
},
mangle: { toplevel: true },
format: { comments: false },
},
extractComments: false,
}),
],
// 共通のコード分割（SplitChunks）ポリシーもここで強制する
splitChunks: {
chunks: ‘all’,
maxInitialRequests: 5,
minSize: 20000,
},
};
}
各アプリケーションリポジトリでは、この関数を呼び出すだけで、全社統一された最強の最適化とバンドルポリシーが適用される。
—
4. 実行検証：Terser (passes: 3) vs Esbuild の実測値
実際のエンタープライズ規模のReactアプリケーション（総モジュール数約1,200、初期バンドルサイズ約 1.2MB）において、それぞれのMinifierを適用した際のベンチマーク結果を共有する。
| 測定項目 | Terser (デフォルト: passes: 1) | Terser (極限チューニング: passes: 3) | Esbuild-loader |
| :— | :— | :— | :— |
| ビルド時間 (CI環境) | 42秒 | 78秒 (+36秒) | 11秒 (-31秒) |
| JSバンドルサイズ (gzip前) | 1,245 KB | 1,180 KB (-5.2%) | 1,198 KB (-3.8%) |
| JSバンドルサイズ (gzip後) | 310 KB | 292 KB (-5.8%) | 298 KB (-3.9%) |
| Main Thread Parse Time | 145 ms | 132 ms | 136 ms |
テックリードとしての最終結論
- 極限のパフォーマンス（モバイル回線や低スペック端末での表示速度）を1バイトでも絞り出したい場合:
`TerserPlugin` を採用し、`passes: 3` および `toplevel: true` を有効にしたハードコアな設定を選択するべきだ。ビルド時間が多少伸びようとも、ユーザー体験（UX）とCore Web Vitalsのスコア向上というリターンがそれを大きく上回る。
- 開発体験（DX）とCI/CDのフィードバックループの速さを最優先する場合:
迷わず `esbuild-loader` を採用せよ。Terserとの差分はわずか数キロバイト・数ミリ秒でありながら、開発者がプルリクエストを投げてからCIがグリーンになるまでのストレスを劇的に軽減できる。
組織のフェーズ、プロダクトのターゲットユーザー層（BtoBのデスクトップ主体か、BtoCのモバイル主体か）に合わせて、このトレードオフを意図を持って選択・制御することこそが、真に優秀なエンジニアの仕事である。今日のビルドから、あなたのプロダクトの「最後の数キロバイト」にメスを入れてほしい。