エンジニア諸君、ようこそ。開発環境の深淵へ。
「なぜ、たかだか数行の機能追加で、バンドルサイズが数MBも膨れ上がるのか？」
この問いに直面したとき、多くのエンジニアが「Webpackは重い」という結論に逃げてしまいます。しかし、それは誤りです。Webpackが重いのではなく、君たちが書いたコード（あるいは依存しているライブラリ）が、Webpackに「これは絶対に消してはいけないコードだ」と誤ったメッセージを送り続けているだけなのです。
今日は、魔法のような自動最適化機能「Tree Shaking」を正しく駆動させ、肥大化したバンドルを外科手術のように削ぎ落とす、現場のプロが実践する「可視化と制御」の極意を伝授します。
—
1. Tree Shakingの本質を知る：なぜコードは消えないのか？
Tree Shakingは、ES Modules (ESM) の「静的構造」を利用して、使われていないコードをビルド時に削除する機能です。しかし、Webpackは非常に慎重です。もし、あるモジュールが「副作用（Side Effects）」を持っている可能性がある場合、Webpackは安全のためにそのコードを削除しません。
「副作用」とは何か？
例えば、モジュールを読み込んだ瞬間にグローバルオブジェクトを汚染したり、DOMを操作したりするコードです。Webpackはコードを実行して検証するわけではないため、「このファイルは副作用があるかもしれない」と判断すれば、中身が未使用でもバンドルに含めざるを得ません。
これが、Tree Shakingが効かない最大の原因です。
—
2. 敵の正体を暴く：Webpack Bundle Analyzerの導入
まずは、何がバンドルサイズを占拠しているのかを可視化しましょう。闇雲にコードを削るのではなく、まずは地形を把握するのです。
開発環境の依存関係としてプラグインをインストール
npm install –save-dev webpack-bundle-analyzer
`webpack.config.js` に以下の設定を追加します。
const BundleAnalyzerPlugin = require(‘webpack-bundle-analyzer’).BundleAnalyzerPlugin;
module.exports = {
// …既存の設定
plugins: [
new BundleAnalyzerPlugin({
analyzerMode: ‘static’, // ファイルとして出力する設定
openAnalyzer: true, // ビルド後にブラウザで自動表示
})
]
};
これでビルドを実行すると、ブラウザに「どのライブラリが、どの程度の面積を占めているか」という地図が表示されます。ここで異様に巨大な箱を見つけたら、それが今回のお手入れ対象です。
—
3. Side Effectsを宣言し、Webpackを解放する
可視化の結果、明らかに「使っていないのに消えていないライブラリ」が見つかった場合、そのライブラリの `package.json` を疑ってください。
多くのライブラリは、Tree Shakingを最適化するために `sideEffects` プロパティを定義しています。これをルートの `package.json` に明示することで、Webpackに「このライブラリは安全だ、思い切って削っていいぞ」と許可を出せます。
プロジェクトの `package.json` に以下を追記：
{
“name”: “my-awesome-project”,
“sideEffects”: [
“.css”, // CSSなどの副作用が必須なファイルは除外
“.scss” // ここに記述したファイル以外はTree Shaking対象となる
]
}
なぜこれが必要なのか？
この設定がないと、Webpackは「もしかしたらCSSファイルをインポートするだけで何かすごい副作用が起きるかもしれない」と疑心暗鬼になり、連鎖的に全モジュールを保持します。この一行が、バンドルサイズを数十パーセント削減する鍵となります。
—
4. 精度高い「HelloWorld」的動作確認
ここまでの知識が正しく機能しているか、簡単なテストコードで確認しましょう。
`math.js` (副作用のない純粋関数モジュール)
export const add = (a, b) => a + b; // これは未使用なら消えるはず
export const heavyTask = () => { console.log(‘I am big!’); }; // これも同様
`index.js`
import { add } from ‘./math’;
console.log(add(1, 2));
この状態で `npm run build` を実行し、生成されたファイルを検索してください。`heavyTask` という文字列が見つからなければ、君のTree Shakingは見事に成功しています。もし見つかるなら、`sideEffects` の設定や、ライブラリのインポート方法（`import { x } from ‘lib’` と書いているか）を再確認してください。
—
最後に：なぜこの作業が重要なのか
エンジニアが「なんとなく」でビルドツールを触る時代は終わりました。バンドルサイズが大きくなれば、ユーザーのロード時間は増え、SEO評価は下がり、結果としてビジネス機会を損失します。
この「可視化→分析→設定による最適化」というサイクルを回せるようになることは、単にファイルを軽くする技術ではありません。「コードがどのように評価され、どうリンクされているか」という、フロントエンドの心臓部を理解する力を得るということです。
これをマスターした君は、明日から「なぜか重い」というチームの課題を、一瞬で解決するヒーローになれるはずです。さあ、まずはBundle Analyzerを立ち上げ、君のプロジェクトの「真の姿」を覗いてみてください。驚くような発見が待っていますよ。