XDローダーとパフォーマンス
デフォルト・ローダーとXDローダーとでは、コードがロードされる際の挙動に一つ大きな違いがあります。デフォルト・ローダーは同期モードでロードするため、dojo.require呼び出しから戻ると、コードのロードおよび評価が確実に完了しています。一方、<script>タグを使うXDローダーの場合は、コードのロードは非同期で行われるため、dojo.require呼び出しから戻ってもロードが完了している保証はありません(むしろ、確実に完了していません)。
コードのロードが非同期で行われるということは、次の二つのことも意味します。
- コードのロードはバックグラウンドで行われるため、ロード中にアプリケーションを一時フリーズさせるようなことがない。
- 複数のネットワーク接続を使って、同時並行的により効率良くコードのロードを行うことができる。
バックグラウンドでのロード
前述の1.は特にコードの遅延読み込みを行う際に効果を発揮します。同期モードで遅延読み込みを行うと、ユーザーにアプリケーションの操作中に一時的に画面がフリーズすると感じさせてしまう可能性があります。ブラウザがフリーズしている間は、ユーザーは一切の操作ができませんし、画面の再描画さえ行われません。その点、非同期モードの性質を活用してアプリケーションをうまくデザインすれば、ロードするコード量は同じでも、応答性やユーザーの体感を向上させることができます。アイドル中にバックグラウンドで次の操作で必要になりそうなコードをあらかじめロードするといった実装も可能でしょう。
同時並行ロード
前述の2.は複数のJavaScriptファイルを同時並行的にロードすることにより、一つずつ順にロードするよりも全体として短時間でロードを完了できる可能性があることを意味します。
図1および図2はあるアプリケーションをそれぞれデフォルト・ローダーおよびXDローダーでロードした場合のパフォーマンスの比較です。縦軸の一つひとつはロードされるファイル、横軸は時間、グラフのバーはロード開始から終了までを表します。
図1を見ると、デフォルト・ローダーでは一つのファイルのロードが終わってから次のファイルのロードがはじまり、一つずつ順にロードしていることが分かります(※1)。
一方、図2を見ると、XDローダーはいくつかのJavaScriptファイルを同時並行的にロードしている様子が分かります(※2)。結果的に図1のケースよりも短時間で全体の処理が完了しています。同時に最大何本の接続を利用するかはブラウザやサーバーの種類や設定によっても異なりますが、一般的に一つずつ取得するよりは複数本の接続を利用して並行して取得する方がより短時間で完了することが期待できます。
![デフォルト・ローダーによるコードのロードの例](http://cz-cdn.shoeisha.jp/static/images/article/5695/5695_loader1.gif)
![XDローダーによるコードのロードの例](http://cz-cdn.shoeisha.jp/static/images/article/5695/5695_loader2.gif)
一部同時並行的にロードされているように見えるのはスタイルシート・ファイル(*.css)です。
ロードは同時並行的に処理されるため、ロードの完了の順序は不定で、予測することはできません。しかし、コードの評価はしかるべき順序で行う必要があるため、デフォルト・ローダーの場合のようにロード完了後ただちにコードの評価を行うわけにはいきません。実はロード完了後に評価を一時保留にすることを可能にするために後述のxdomainビルドはソースコードに巧妙な変換を施しています。XDローダーはすべてのモジュールのロードが完了した後に、ロードした全モジュールの依存関係ツリーを解析し、ツリーの末端から順に評価を行います。
XDローダーによるパフォーマンス改善
以上のように、XDローダーはその名前からクロスドメイン対策の側面がクローズアップされることが多いのですが、実はパフォーマンス・チューニングのテクニックとしても注目したい技術です。自ドメインで閉じていて、クロスドメイン対策の必要がないプロジェクトであっても、パフォーマンスの観点でXDローダーの採用を検討してみる価値があると言えます。