bundle-splitting

バンドルの分割

最新のウェブアプリケーションを構築する際、Webpack や Rollup などのバンドラーは、アプリケーションのソースコードを1つ以上のバンドルにまとめます。ユーザーがウェブサイトにアクセスすると、画面にデータを表示するためにバンドルがリクエストされ、読み込まれます。

V8 などの JavaScript エンジンは、ユーザーがリクエストしたデータの読み込み中に、そのデータを解析してコンパイルできます。最新のブラウザーは、コードをできるだけ速く効率的に解析・コンパイルできるよう進化していますが、プロセスにおける2つの段階、つまりリクエストされたデータの読み込み時間と実行時間を最適化する役割は、依然として開発者にあります。メインスレッドがブロックされないように、実行時間をできるだけ短く保つことが重要です。

使用するタイミング

• アプリケーションの JavaScript バンドルが大きく、読み込み時間に影響している場合に使用します
• First Contentful Paint（FCP）と Largest Contentful Paint（LCP）を短縮したい場合に役立ちます
• コードの一部が特定のユーザー操作またはルートでのみ必要な場合に使用します

手順

• Webpack や Rollup などのバンドラーを使って、コードを複数の小さなバンドルに分割します
• 初期レンダリングで必要ないコードは、別のバンドルに分離します
• Time To Interactive（TTI）への影響を考慮し、重要なレンダリングコードを優先します

詳細

最新のブラウザーは、バンドルが届くそばからストリーミングできますが、それでもユーザーのデバイスで最初のピクセルが描画されるまでにかなりの時間がかかることがあります。バンドルが大きいほど、エンジンが最初のレンダリング呼び出しが行われた行に到達するまでの時間が長くなります。その間、ユーザーは空白の画面を見つめることになります。

ユーザーにできるだけ早くデータを表示したいと考えています。バンドルが大きいと、読み込み時間、処理時間、実行時間が増加します。処理を速めるために、このバンドルのサイズを小さくできると理想的です。

不要なコードを含む巨大なバンドルをひとつリクエストする代わりに、バンドルを複数の小さなバンドルに分割できます！

アプリケーションのバンドルを分割することで、バンドルの読み込み、処理、実行にかかる時間を短縮できます！読み込み時間と実行時間を短縮すれば、ユーザーの画面に最初のコンテンツが描画されるまでの時間である First Contentful Paint（FCP）と、最大のコンポーネントが画面に描画されるまでの時間である Largest Contentful Paint（LCP）を短縮できます。

画面にデータが表示されるのは素晴らしいことですが、コンテンツをただ_見る_だけでは十分ではありません。完全に機能するアプリケーションにするには、ユーザーがそれを_操作_できるようにする必要もあります！UI が操作可能になるのは、バンドルの読み込みと実行が完了した後です。すべてのコンテンツが画面に描画され、操作可能になるまでの時間は、Time To Interactive（TTI）と呼ばれます。

バンドルが大きいからといって、必ずしも実行時間が長くなるわけではありません。ユーザーがまったく使わない大量のコードを読み込んでいる可能性もあります！バンドルの一部は、特定のユーザー操作があった場合にのみ実行されるものの、ユーザーがその操作をするとは限りません。

ユーザーが画面上で何かを見られるようになる前に、エンジンは初回レンダリングでは使われないコードも読み込み、解析し、コンパイルする必要があります。ブラウザーはこの2つの手順を効率的に処理するため、解析とコンパイルのコストは実質的に無視できますが、必要以上に大きなバンドルを取得すると、アプリケーションのパフォーマンスが低下する可能性があります。低性能なデバイスや低速なネットワークを使うユーザーは、バンドルの取得が完了するまでの読み込み時間が大幅に長くなります。

現在のナビゲーションで優先度が高くないコードを最初にリクエストする代わりに、初回ページのレンダリングに必要なコードと分離できます。

大きなバンドルを main.bundle.js と emoji-picker.bundle.js の2つの小さなバンドルに分割することで、取得するデータ量を減らし、初回の読み込み時間を短縮できます。

ソース

• patterns.dev/vanilla/bundle-splitting