Speed Analysis Lab と RUM メトリクス (A-Z リスト)

DOM Completeは、DOMが完全に構築されるまでの時間を測定します。

DOM Completeの理解
async属性を持つスクリプトを含むすべてのスクリプトがDOM内で実行されました。DOMで定義されたページのすべてのサブリソース（画像、iframeなど）が読み込まれています。

Load Event Startは、DOM Completeの直後に発生します。ほとんどの場合、これら2つのメトリックは等しいです。Load Event Startの前に追加の遅延が発生する可能性があるのは、onReadyStateChangeによって処理される場合のみです。

収集元: ウェブブラウザ (API)

DOMContentLoaded (DCL)は、ウェブブラウザによって発火されるイベントです。リスナーがイベントにアタッチされ、イベントが発火したときにJavaScriptの実行をトリガーするための開始と終了があります（これは基本的にjQuery.readyが行っていることです）。

DOMContentLoadedイベントは、初期のHTMLドキュメントが完全に読み込まれ、解析されたときに発火します（画像やiframeの読み込みが完了するのを待たずに）。

ブロッキングJavaScriptはイベントを遅延させます。DOMContentLoadedを最適化するために、JavaScriptを非同期にしてください。

注意: DOMContentLoaded EndがDOMContentLoaded Startよりも大幅に高い場合、ページにはこのイベントにアタッチされたリスナーがあり、重要なコードの実行やネットワークに依存していることを意味します。

DOMContentLoaded Startは、DOM Interactiveの直後に発生します。DOMInteractiveとDCL Startの間での唯一の処理は、モジュールタイプのasyncスクリプトに関連しています。

収集元: ウェブブラウザ (API)

DOMInteractiveイベントは、DOMが読み込まれ、ウェブページのブロッキングスクリプトが実行されたときにトリガーされます。 この段階では、defer属性を持つスクリプトはまだ実行されていません。一部のスタイルシートはまだ読み込まれており、ページのレンダリングをブロックする可能性があります。

収集元: ウェブブラウザ API

累積レイアウトシフト (CLS) は、ページの安定性を測定し、ページの全体的な寿命の間にユーザーを混乱させたり誤解させたりする可能性のある要素の重要な動きを監視します。

CLSはCore Web Vitalsの一部です。Googleは2021年から検索ランキングシグナルとしてCore Web Vitalsを使用しています。

累積レイアウトシフト (CLS) の理解
累積レイアウトシフトは、ページの全体的な寿命の間に発生するすべての個別のレイアウトシフトの合計を測定し（ユーザーがページと対話を開始した後も含む）、関係する領域のサイズとシフトの距離を考慮します。

CLSアルゴリズムは、現在のコンテキスト内のすべてのレイアウトシフトを監視し、iframeの内容は除外します。

アクティブなユーザーインタラクション（クリック、キーストローク、ウィンドウのリサイズなど）の後500ミリ秒以内に発生するレイアウトシフトは、CLSに影響を与えません。ホバー、スクロール、および更新フリングはアクティブなインタラクションとは見なされません。

他のレイアウトシフトは、影響を受けた領域の合計と移動した要素の距離に基づいてスコアが付けられます。累積レイアウトシフトは、考慮されたすべてのレイアウトシフトスコアの合計です。

Googleのガイドラインによれば、あなたのウェブページは、ユーザーの少なくとも75%（デスクトップとモバイルトラフィックの両方を含む）に対してCLSが0.1未満であるべきです。

最適化の例
累積レイアウトシフトを改善するために、ブラウザが画像やiframe（広告を含む）のための適切なスペースを、読み込みを開始する前に確保できるように、幅と高さ、またはアスペクト比を定義してください。

収集元: ウェブブラウザ (API)

First Contentful Paint (FCP) は、コンテンツがページに表示され始めるまでの時間を測定します。

First Contentful Paint (FCP) の理解
FCPの定義は、Start Renderの定義に非常に近いです。しかし、FCPはビデオ分析を通じて計算されるのではなく、ウェブブラウザ（Paint Timing APIを介して）から直接提供されます。

定義にもかかわらず、FCPは何も表示されていないときでもトリガーされることがあります。たとえば、テキストがページ上に存在するが、カスタムフォント（ウェブフォント）がまだ読み込まれていないために見えない場合です。

収集元: ウェブブラウザ API 

First Input Delay (FID) は、ユーザーの最初のインタラクションと、そのインタラクションが処理されるまでの時間を測定します（インタラクションはリンクやボタンをクリックまたはタップすることができます）。

Max Potential First Input Delay (Max Potential FID) は、First Input Delayが持つ可能性のある最悪の値です。First Input Delay (FID) は、ユーザーがページと初めてインタラクションする際に経験する遅延です（例: 要素をクリックしたときにページからフィードバックを得るまでの遅延）。

FIDはページのビジー状態（応答性を妨げるタスク）とユーザーのインタラクションのタイミングに依存します。

FIDは実際のユーザーの特定のインタラクションから収集されますが、Max Potential FIDはユーザーなしで計算でき、値はページが最も応答性が低いときにユーザーがページとインタラクションする際に直面する遅延です（最悪のシナリオ）。

Googleのガイドラインによれば、あなたのウェブページは、少なくとも75%のユーザー（モバイルとデスクトップのトラフィックの両方を含む）に対してFIDが100ms未満であるべきです。

計算方法
Max Potential First Input Delayは、First Contentful Paintの後に最も長いタスクを見つけることによって計算されます（ユーザーはコンテンツが表示される前にページとインタラクションしようとはしないと仮定できます）。

収集元: Webブラウザ (API)

次のペイントまでのインタラクション (INP) は、ウェブページの応答性を評価する指標です。これは、ユーザーのインタラクション（クリックやキー押下など）と、ユーザーがページ上で視覚的な更新を次に見るまでの時間を測定します。（視覚的な更新はインタラクションとは無関係である可能性があることに注意してください）。

Googleは、FIDが2024年3月にINPに置き換えられると発表しました。FIDはウェブサイトのランキングにはもはや使用されませんが、INPは（LCPおよびCLSと共に）使用されます。

INPとFIDの違い

• FIDはページの最初のインタラクションのみを測定しますが、INPはすべてのページインタラクションを測定します。
  
  
• FIDはユーザーのインタラクションとブラウザが実際に処理を開始できるまでの遅延を測定します。
  
  
• INPはユーザーのインタラクションとその後のUIの変更との間の詳細を測定します。

INPは、ページとインタラクションする際のユーザー体験の潜在的な視覚的遅延をより代表しています。FIDはページビューの開始時の技術的な遅延（最初のインタラクションのみ）に焦点を当てています。

 

INPはどのように機能しますか？

INPは、ユーザーがインタラクションを開始してから次のフレームのレンダリングが行われるまでの期間をキャプチャすることを目的としており、可能な限りすべてのユーザーインタラクションに対してこれを達成しようとしています。

INPの値は、観測された最悪の遅延です（50回以上のインタラクションを持つページビューの場合、外れ値は除外され、INPは98パーセンタイル値になります）

INPで観測されるインタラクションは次のとおりです：

• マウスでのクリック
• タッチスクリーンデバイスでのタップ
• 物理キーボードまたは画面上のキーボードでのキー押下

注意: マウスのホバーやスクロールはINPには含まれません。

Googleのガイドラインによると、あなたのウェブページは、少なくとも75%のユーザー（モバイルとデスクトップのトラフィックの両方を含む）に対して、INPが200ms未満であるべきです。

収集元: ウェブブラウザ (API)

最大コンテンツ描画 (LCP) は、読み込みパフォーマンスを測定し、Core Web Vitals の一部です。Google は 2021 年以来、検索ランキングシグナルとして Core Web Vitals を使用しています。

最大コンテンツ描画 (LCP) の理解

最大コンテンツ描画 (LCP) は、ビューポート内で表示される最大のコンテンツ要素のレンダリング時間を測定します（ユーザーがスクロールする前の時間）。

LCP は、最大のコンテンツ（背景画像を除外し、ビューポートの外に表示されるコンテンツ、例えば折り返しの下にあるものを除外）と一貫したコンテンツの配信速度に焦点を当てています（ローダーやスプラッシュスクリーンなどの一時的なコンテンツは無視されます）。

Google のガイドラインによれば、あなたのウェブページは、少なくとも 75% のユーザー（デスクトップおよびモバイルトラフィックの両方を含む）に対して LCP が 2.5 秒未満であるべきです。

遅い LCP の一般的な原因には、画像、動画、サードパーティのスクリプトなどの大きなデザイン要素が含まれます。

最適化の例
リソースを最適化し、レイジーロードを使用し、JS を必要最低限に削減します。

収集元: ネットワークトラフィック分析

ウェブページが完全に読み込まれるのに必要な時間（Speed Analysis がさらなるネットワークアクティビティを検出しないまで）。

完全読み込みの理解

完全読み込み時間は、ページの読み込みに関連するすべてのリクエストに影響され、ダウンロードされたリソースを含みます。リクエストはユーザーエクスペリエンスに直接影響を与えません（リターゲティングなど）。

収集元: ウェブブラウザ API

オンロードイベントは、ドキュメントオブジェクトモデル (DOM) が読み込まれ、ページの依存関係が読み込まれて処理されたときにトリガーされます（画像、CSS、JavaScript など。ただし、iframe は除く）。

開始と終了があり、リスナー（ページイベントを監視してコードを実行する JavaScript の一部）がイベントに添付され、イベントが発生したときに JavaScript の実行をトリガーできます。Load イベントは、初期の HTML ドキュメントが完全に読み込まれ、解析されたときに発生します（画像や iframe の読み込みが完了するのを待たずに）。

"defer" および/または "async" 属性を持つ外部スクリプトもこの段階で実行されます。async 属性を持つスタイルシートも同様です。

収集元: ビデオ分析

Speed Indexは、ページコンポーネントの平均表示速度を反映する指標です。

Speed Indexの理解
Speed Indexは、テストされたウェブページの可視部分（ファーストビュー）のピクセルの平均表示速度を記録します。その結果、この指標はページを構成するさまざまな要素の表示の進行状況を考慮に入れます（速度が低いほど良い）。

Googleは、Speed Indexが1000未満であることを推奨しています。

最適化の例
外部静的リソースへの同期呼び出しを避け、重要なCSSとJSをローカルにホストします。

JSペイロードを削減するか、フッターに移動します。

収集元: ビデオ分析

レンダリング開始は、ユーザーの画面に表示される最初の表示を示します（この前はページは空白のままです）。レンダリング開始は、ウェブページの読み込みに関するビデオ分析から決定されます。

レンダリング開始の理解
ビデオ分析はテストされたウェブページの可視部分（ファーストビュー）のみを対象としているため、最初にレンダリングされる要素が必ずしも重要なものであるとは限らないことに注意してください（背景色やテキストなどの小さな要素である可能性があります）。

最適化の例
追加のAPI呼び出しなしで、ウェブページに重要なコンテンツを提供します。
コンテンツに必要なCSSをページの上部で早めに提供し、理想的にはインライン化します。

収集元: ネットワークトラフィック分析

ファーストバイトまでの時間（TTFB）は、ブラウザがページをリクエストしてから、ユーザーが最初のデータの断片（関連するウェブページのHTMLコード）を受信するまでの時間を示します。

ファーストバイトまでの時間の理解
ファーストバイトまでの時間は、ウェブサーバーの応答時間にネットワーク遅延、DNS解決、TCP接続の確立時間（およびウェブページがHTTPsを使用している場合は安全な接続の確立時間）を加算して計算されます。

リダイレクトの遅延（301および302だけでなく、クライアント側のJavaScriptリダイレクトも含む）はTTFBに含まれます。これは、読み込まれるウェブページに関連する最初の「価値のある」バイトを考慮しているためです。

Googleは、ウェブサイトのTTFBが200ミリ秒（0.2秒）以下であることを推奨しています。遅延は、コンテキスト（高遅延帯域幅）、サーバーの状態、証明書チェーンの長さ、リダイレクトなどの要因による可能性があります。

最適化の例
バックエンドの前でキャッシュの問題を調査します。

収集元: ネットワークトラフィック分析

Last Byteまでの時間は、ブラウザから送信されたリクエストと、関連するレスポンスの最後のバイト（HTMLドキュメントの最後の部分）の受信との遅延を測定します。

Last Byteまでの時間（TTLB）の理解
TTLBは、First Byteまでの時間の直後に続きます。Last Byteまでの時間は、First Byteまでの時間に対して追加の遅延をカウントします: データをダウンロードする時間です。

注意: 開始時間（TTFB）と終了時間（TTLB）の違いは通常は小さいですが、HTMLページのページ重量が高い場合（スピードテストに使用される下流帯域幅に対して）を除きます。

 

収集元: GoogleChromeLabsポリフィル（ネイティブブラウザの実装を待機中）

インタラクティブになるまでの時間（Googleが提案したもの）は、複雑な指標です; インタラクティブになるまでの時間は、ページがインタラクティブになる時間ではありません。インタラクティブになるまでの時間は、ページが持続的にインタラクティブであるときです。明確にするために、この指標をスピード分析において「一貫してインタラクティブになるまでの時間」と名付けました。

ページが持続的にインタラクティブであるとはどういうことですか？

TTIアルゴリズムは、JavaScriptとネットワーク活動の分析の両方に基づいています。これは、ユーザーがページとインタラクションを行うことができる瞬間を決定します。このとき、反応の流動性に関するリスクはありません（「ジャンク」なし、アクションと関連する反応の間に知覚可能な遅延なし）。

ページは、インタラクションが満足のいく方法で発生するためのすべての条件が少なくとも5秒間満たされているときに、持続的にインタラクティブであると見なされます。この5秒のウィンドウ内に長いタスクが発生した場合、再び5秒間待機を開始します。そうでない場合、「一貫してインタラクティブになるまでの時間」は5秒の「静かな」範囲の開始時に定義されます。

長いタスクの発生に休息がない場合（つまり、ブラウザが繰り返し遅延を引き起こすタスクを実行する場合）、その場合、「一貫してインタラクティブになるまでの時間」は計算できず、それに基づく指標（総ブロッキング時間など）も計算できません。

収集元: ウェブブラウザ (ロングタスクAPI + シンプルアルゴリズム)

総ブロッキング時間 (TBT) は、ページがコンテンツのレンダリングを開始した後に、ユーザー入力（クリック、キーボード入力など）に応答することがブロックされている合計時間を測定します。

計算方法
総ブロッキング時間の計算はロングタスクに基づいています。ロングタスクは、ウェブブラウザをしばらく独占し（>50ミリ秒）、他の重要なタスクの実行をブロックする処理です（例: ユーザー入力に反応する）。

総ブロッキング時間は、ファーストコンテンツフルペイントと（一貫して）インタラクティブになるまでの時間の間のすべてのロングタスクのブロッキング部分を加算することによって計算される合計です。ロングタスクのブロッキング部分は、50ミリ秒を超える期間です。

3つのロングタスクを持つページの読み込みの例:
[ロングタスク 1: 55 ms] FCP [ロングタスク 2: 110 ms] [ロングタスク 3: 200 ms] TTI

• ロングタスク 1 は FCP の前に発生しているため無視されます
• ロングタスク 2 のブロッキング部分は 60 ms (110 - 50) です。
• ロングタスク 3 のブロッキング部分は 150 ms (200 - 50) です。
  
  したがって、総ブロッキング時間は 210 ms (60 + 150) です。

なぜ総ブロッキング時間が計算されないことがあるのか？
総ブロッキング時間はファーストコンテンツフルペイント (FCP) と（一貫して）インタラクティブになるまでの時間の間に計算されるため、TBT が存在するためには両方のメトリックが定義される必要があります。繰り返し発生するロングタスクがある場合、インターフェースが一貫してインタラクティブである時間は実際には存在しないため、TBT を計算すべき時間の範囲に「終了」がありません。

ロングタスクを追跡する必要があるが TBT を計算できない場合は、代わりに「ロングタスクの合計」メトリックを使用できます。

収集元: ビデオ分析

視覚的に完全は、折り返し線の上にあるすべてのコンテンツが表示されるまでの時間を計算します。

視覚的に完全を理解する

視覚的に完全は、折り返し線の上のゾーンが最終的な形でレンダリングされるのに必要な時間を測定します。（このメトリックは、ウェブページの読み込みのビデオ分析から測定されます）。

この最終的なレンダリング状態は、分析の終わりにキャプチャされます。つまり、スピード分析がページの読み込みに関連するトラフィックの終了を検出したときです。ビデオを分析することにより、スピード分析はこの最終的なレンダリング状態が完了した時点を特定します。

この最終状態の検出は、アニメーション（カルーセルなど）によって影響を受ける可能性があります。なぜなら、ウェブページが完全に読み込まれているように見える間に、レンダリングが何度も変わる可能性があるからです。結果を安定させるために、スピード分析はアニメーションを無効にするオプションを提供します。

最適化の例
背景を支配的な色に設定して、CSSとインラインで読み込むようにします。例: 黒が支配的な画像のために黒い背景を設定して、読み込み時間中にスペースを確保します。