Webpackは「遅い」のではない。君の理解がまだ深淵に達していないだけだ。
Webpackを単なる「バンドラー」として使っているうちは、いつまで経ってもビルド時間の増大という負債に追い回されることになる。Webフロントエンドのビルドパイプラインは、もはや単なるファイルの連結ではない。依存関係グラフ（Dependency Graph）の動的解析と、メモリ空間の高度な最適化を要する「コンパイラ・エンジニアリング」そのものだ。
本稿では、マニュアルの表面をなぞるような手法は一切排除する。Webpackの内部挙動を制御し、CI/CDの実行時間を物理的限界まで削り出すための「5つの深淵なるハック」を伝授する。
—
1. 依存関係グラフの「断捨離」：Loaderのスコープを物理的に封鎖せよ
Webpackが遅い最大の原因は、実は「ビルドすべきでないファイルを解析していること」にある。`include/exclude` を適当に設定しているエンジニアが多いが、これは `node_modules` を除外するだけでは不十分だ。
最適化の極意:
`babel-loader` や `ts-loader` を適用する際、正規表現でパスを限定するのではなく、`path.resolve` を用いて絶対パスで厳密に境界を定義せよ。
// webpack.config.js
const path = require(‘path’);
module.exports = {
module: {
rules: [
{
test: /\.(ts|tsx|js|jsx)$/,
// 曖昧な正規表現は避け、コンパイルが必要な自作ソースのみをロックオンする
include: [path.resolve(__dirname, ‘src’)],
// 依存ライブラリの中で特に巨大なものは個別に明示排除（深すぎる階層を走査させない）
exclude: /node_modules\/(?!(specific-heavy-pkg)\/)./,
use: [‘babel-loader’]
}
]
}
};
これにより、Webpackは不要なファイル探索（ファイルシステムへのアクセス）を停止し、I/O待ち時間を劇的に削減する。
—
2. メモリとI/Oのボトルネックを解消：Persistent Cachingの真実
Webpack 5で導入された `filesystem cache` を「とりあえず有効にする」だけでは片手落ちだ。CI環境においては、このキャッシュをどう「永続化・再利用」するかが勝負の分かれ目となる。
CI/CDパイプラインへの統合ハック:
GitHub ActionsやGitLab CIで、`.cache/webpack` ディレクトリを各ランナー間で共有せよ。
// webpack.config.js
module.exports = {
cache: {
type: ‘filesystem’, // メモリではなくディスクに書き出す
buildDependencies: {
config: [__filename], // 設定ファイルが変更されたらキャッシュを無効化
},
// CI環境では圧縮レベルを上げ、I/O負荷を軽減する
compression: ‘gzip’,
},
};
キャッシュのヒット率を上げる鍵は、ビルド環境の固定化だ。Dockerコンテナのレイヤー構造を最適化し、`node_modules` とキャッシュディレクトリが常に同じパスにマウントされるようパイプラインを設計せよ。
—
3. Tree Shakingを「殺さない」ためのコード・シグナリング
WebpackのTree Shakingは、ES Modulesの静的解析に基づいている。だが、君の書いたコードが副作用（Side Effects）を含んでいると、Webpackは安全のためにコードを削除できない。
最適化の極意:
`package.json` に `sideEffects: false` を明示し、さらにスタイルシートなど副作用があるファイルのみを個別に指定せよ。
// package.json
{
“sideEffects”: [
“.css”,
“.scss”,
“src/polyfills.js”
]
}
これにより、Webpackの最適化エンジンは「このファイルはインポートされていないなら完全に抹消して良い」という確信を持ってグラフを整理できる。これでバンドルサイズとビルド時間が同時に縮小する。
—
4. 並列処理の境界線：Thread-loaderの「諸刃の剣」
`thread-loader` を使えばビルドが速くなるというのは幻想だ。プロセス間通信（IPC）のオーバーヘッドがあるため、小規模なプロジェクトで導入すれば逆に遅くなる。
エンジニアの判断基準:
- ファイル数: 1,000ファイルを超える大規模プロジェクトであること。
- 重いLoader: `babel-loader` や `ts-loader` がビルド時間の80%以上を占めていること。
この条件下のみで使用し、ワーカー数はCPUコア数から1を引いた数に固定せよ。
// webpack.config.js
const os = require(‘os’);
module.exports = {
module: {
rules: [
{
test: /\.js$/,
use: [
{
loader: ‘thread-loader’,
options: { workers: os.cpus().length – 1 }
},
‘babel-loader’
]
}
]
}
};
—
5. アーキテクトの最終兵器：ビルドプロファイリングの自動化
感覚でチューニングしてはいけない。Webpackの `SpeedMeasurePlugin` をCIのパイプラインに組み込み、どのプラグインやLoaderが何秒消費したのかを可視化せよ。
自動化スクリプトの提案:
CIのパイプラインでビルドが終了した後、統計情報をJSONで出力し、一定の閾値（例：300秒）を超えた場合にSlackへアラートを飛ばす仕組みを作れ。
ビルド実行ログの抜粋
webpack –profile –json > stats.json
Node.jsスクリプトで解析し、特定のLoaderがボトルネックになっていないか監視
node scripts/analyze-stats.js stats.json
—
魂の結論：ツールを「支配」せよ
Webpackを高速化することは、単なる設定変更ではない。それは、君がプロジェクトの依存関係、I/O性能、メモリ管理を完全に掌握していることの証明だ。
ビルドが遅いと嘆く時間があるなら、`webpack –profile` を叩いて統計を出し、どのファイルがどのプロセスを止めているのか、その「犯人」を特定せよ。Webpackという巨大なエンジンを、君の意のままに操るためのチューニングを今日から開始せよ。
「ツールに使われるな。ツールを支配し、パフォーマンスの限界を突破せよ。」