複雑コンテキストのWebアプリが遅い3つの主要因とは？「ツールでは根本原因の追究が困難」：計測用JavaScript APIをMicrosoftが提案

Microsoftは、Webパフォーマンス向上を支援する狙いで「Delayed Message Timing API」を提案した。

[＠IT]

　Microsoftは2025年12月9日（米国時間）、複雑なWebアプリにおけるコンテキスト間メッセージの遅延要因を特定するための「Delayed Message Timing API」を提案した。

　Microsoftは「Webではスピードが全て。ブラウザの応答性、Webアプリの表示時間、アプリがユーザーインタラクションを処理する速度は、全てユーザー体験に直接影響する」との認識の下、Webパフォーマンス向上に取り組んでおり、ブラウザやブラウザエンジンを改善してきた。向上の一環として、高速なWebアプリを構築できるように開発者を支援する狙いがある。

　複雑なWebアプリでは、複数のWindowやiframe（インラインフレーム）、ワーカースレッドといったコンテキスト間で大量のメッセージ交換が並列で発生する。この際、メッセージがキューに滞留して処理が遅れると、アプリの反応が鈍くなるなどの問題が生じる。既存のツールでは遅延の事実は確認できても、その根本原因を突き止めることは困難だったという。

コンテキスト間メッセージ通信の3つの遅延原因と計測ポイント

　Microsoftは、postMessage()を使ってコンテキスト間でメッセージを交換するときに起こり得る遅延の主な原因を3つに分類し、今回提案したDelayed Message Timing APIが根本原因の診断にどう役立つかを解説している。

1：受信コンテキストが混雑している

　1つ目の原因は、受信側のコンテキストが長い同期タスクを実行中でスレッドがブロックされているケースだ。この場合、メッセージは処理開始までキューに入れられて待機を強いられる。

受信コンテキストが混雑している状態（提供：Microsoft）

　メッセージの受信者が他のタスクで忙しいかどうかを把握するには、メッセージがブロックされていた時間を知る必要がある。Delayed Message Timing APIでは、メッセージがキュー内で待機した時間を示す「blockedDuration」プロパティを提供する。

2：タスクキューが混雑している

　2つ目は、タスクキューが多数の短いタスクで混雑しているケースだ。メインスレッドでのユーザー操作やネットワーク処理、ナビゲーション、読み込み、レンダリングといったシステム内部のオーバーヘッドタスクのような高優先度タスクでキューが飽和状態になった場合、ワーカーへのメッセージが集中した場合にこの現象が発生する。

　どちらの場合も、タスクやメッセージが処理可能な速度よりも速く到着し、バックログが発生して、時間的に制約のあるメッセージを含む後続のメッセージが遅延する。個々のタスクは短くても蓄積されると、混雑を引き起こして実質的に1つの長いタスクのように動作する。

タスクキュー混雑による遅延（提供：Microsoft）

　これを診断するためにDelayed Message Timing APIは、メッセージをブロックしていたタスクの数を示す「taskCount」「scriptTaskCount」を導入する。

3：シリアル化とデシリアル化のオーバーヘッド

　3つ目は、コンテキスト境界を越える際にメッセージをシリアライズ（直列化）／デシリアライズ（復元）する必要がある。これらは送受信スレッド上で同期的に行われるので、postMessage()で大量のデータを送る場合などに顕著なオーバーヘッドを引き起こす可能性がある。

シリアライズ／デシリアライズによる遅延（提供：Microsoft）

　Delayed Message Timing APIでは、シリアライズ／デシリアライズの所要時間を計測する「serialization」「deserialization」プロパティを提供する。

Delayed Message Timing APIの使い方

　Delayed Message Timing APIは、「Window.postMessage」「Worker.postMessage()」「MessageChannel()」「BroadcastChannel」をカバーする。

　ラウンドトリップタイミング分析を行うには、送信側と受信側の両方のコンテキストから収集したパフォーマンスエントリを相関させる必要がある。詳細については、ドキュメントを参照のこと。