合計ブロッキング時間

総ブロッキング時間は、ページ読み込み中にブラウザのメインスレッドが長時間かかるタスクによってブロックされ、ユーザー入力に応答できなくなった累積時間を計測します。これは、各タスクのうち50ミリ秒を超える部分のみを合計し、最初のコンテンツフルペイントからページが確実にインタラクティブになる時点までの間を実験室環境で測定します。

その目的は、実際のユーザー操作なしには測定が難しい応答性の実験室における代替指標として機能することです。Interaction to Next Paintは実際のユーザー入力を必要とするため、誰もクリックしない合成テストでは取得できません。Total Blocking Timeは、ブラウザが応答できなかった読み込み期間の割合を測定することで、同じ根本的な問題を近似的に捉えており、診断に役立つほど十分な相関性があります。

50ミリ秒という閾値は、恣意的な選択ではなく、人間の知覚を反映したものです。この時間以下のタスクであれば、ブラウザは入力に十分迅速に反応し、インターフェースは即座に感じられる一方、より長いタスクでは知覚できる遅延が発生します。閾値を超える部分のみをカウントすると、500ミリ秒のタスク1つが60ミリ秒のタスク10個よりもはるかに大きな影響を与えることになり、これは1つの長いブロックが複数の短いブロックよりも悪いという現実を正しく反映しています。

原因はほぼ全てJavaScriptの実行にある。解析とコンパイルが必要な大きなバンドル、サーバー上でレンダリングされるページのフレームワークの初期化とハイドレーション、読み込み中に実行されるサードパーティ製スクリプト、同期的に実行される高負荷な計算処理などが全てメインスレッドを占有する。ネットワークの改善ではこの問題は解決されない。瞬時にダウンロードされるスクリプトであっても、実行中はスレッドをブロックしてしまう。

改善策は、どのタスクが長時間かかるか、そしてその内容を特定することから始まります。バンドルを分割して初期ビューに必要なコードだけがすぐに読み込まれるようにする、重要度の低いスクリプトの実行を延期する、長時間かかるタスクをブラウザに処理を委譲する小さなタスクに分割する、負荷の高い計算をワーカー スレッドに移行する、コストに見合わないサードパーティ スクリプトを削除する、といった方法が標準的なアプローチです。単一のタグ マネージャー コンテナが測定結果を大きく左右する可能性があるため、サードパーティ スクリプトを個別に監査することが、多くの場合最も効果的な対策となります。

実測データとの関連性については、解釈に注意が必要です。総ブロッキング時間は管理された条件下での実験室測定値であるのに対し、インタラクションから次の描画までの時間は、実際のデバイスを使用する実際のユーザーから収集されたデータです。高速なテストマシンでは許容範囲内のブロッキング時間を記録するページでも、多くのユーザーが実際に使用する中級スマートフォンでは応答性が低い場合があります。実験室での数値が予測値として有効となるのは、実際のデバイス分布に近い制限された条件下でテストを行うためです。

また、この方法は読み込み期間しかカバーしないため、大きな制約となります。ユーザーが大量のリストをフィルタリングしたり、複雑なビューを開いたりする際に発生する応答性の問題などは、読み込み完了後に測定が停止する方式では捉えられません。読み込み後にインタラクティブな要素が豊富なアプリケーションでは、読み込み時間の指標に頼るのではなく、実際の操作を現場で測定する必要があります。

解決策は資産配信ではなくアプリケーションコードとサードパーティの依存関係に関わるため、改善には構成ではなくエンジニアリングが必要です。実際には、診断は以下にあります。 Webパフォーマンス 作業、バンドル、および実行の変更は、 製品開発、そしてどのサードパーティースクリプトがメインスレッドのコストを正当化するかについての決定には、通常、 マーケティングサービスなぜなら、そのようなスクリプトのほとんどは彼らの要望に基づいて作成されているからです。