1. 導入：なぜTree Shakingが重要なのか
モダンなフロントエンド開発において、アプリケーションのバンドルサイズはユーザー体験（UX）に直結する重要な指標です。特に外部ライブラリを多用する場合、使っていないコードまで含めてビルドしてしまうと、読み込み時間が長くなり、Core Web Vitalsの悪化を招きます。Tree Shaking（木を揺らして枯れ葉を落とすイメージ）は、この不要なコードを自動的に排除する強力な最適化手法です。本記事では、この技術の仕組みと、実務で効果を最大化するためのポイントを解説します。
2. 基礎知識：Tree Shakingの仕組みと前提条件
Tree Shakingは、ES Modules（ESM）の「静的解析」という特性を利用しています。CommonJS（require/module.exports）と異なり、ESMは実行前にインポート・エクスポートの関係が確定するため、バンドラー（Webpack, Vite, esbuild）が「どのコードが使われていないか」を安全に判定できます。
注意点： 動的なインポートや、副作用（Side Effects）があるコードは、バンドラーが「削除してよいか」を判断できず、Tree Shakingから除外されることがあります。
3. 実装と解決策：package.jsonでの制御
ライブラリ開発者やプロジェクトの構成において、最も重要な設定が「sideEffects」フラグです。これを明示することで、バンドラーに対して「このファイルは副作用がないので、使われていなければ削除してOK」というヒントを与えられます。
設定例（package.json）:
{
“name”: “my-library”,
“sideEffects”: false
}
※特定のCSSファイルなど、副作用が必要なファイルがある場合は配列で指定します。
4. サンプルプログラム：Tree Shakingを意識したコード記述
以下の例では、Tree Shakingが機能しやすい書き方と、逆に阻害してしまう書き方を比較します。
// 良い例：名前付きエクスポートを使用する
// これにより、必要な関数のみが抽出対象となる
export const add = (a, b) => a + b;
export const subtract = (a, b) => a – b;
// 悪い例：デフォルトエクスポートでオブジェクトをまとめてエクスポート
// これだと、addしか使っていなくても、オブジェクト全体が残る可能性がある
export default {
add,
subtract
};
// 呼び出し側（App.js）
import { add } from ‘./mathUtils’; // addのみインポートするため、subtractはTree Shakingされる
console.log(add(1, 2));
5. 応用・注意点：現場で陥りやすい落とし穴
実務でTree Shakingを最大限に活かすためには、以下の点に注意してください。
Babelの設定に注意：
Babelを使用する場合、`@babel/preset-env`の設定でモジュール変換を無効にする必要があります。`modules: false`を指定しないと、ESMがCommonJSに変換され、Tree Shakingが効かなくなります。
副作用の確認：
`sideEffects: false`を指定したものの、ライブラリ内でグローバル変数を書き換えていたり、CSSをインポートしている場合、アプリケーションが正常に動作しなくなる可能性があります。ビルド後に成果物を確認する際は、`webpack-bundle-analyzer`などのツールを使い、意図した通りにコードが削除されているか可視化することをお勧めします。
バンドラーの進化により自動化が進んでいますが、コードの書き方一つで最適化の効率は大きく変わります。常に「静的解析が可能なコード」を意識した実装を心がけましょう。
コメント