シンセティック・モニタリングとRUM指標（A-Zリスト）

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

DOM Completeの理解
DOM内のすべてのスクリプト（async属性を持つものを含む）が実行されました。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はコアウェブバイタルの一部です。Googleは2021年からコアウェブバイタルを検索ランキングシグナルとして使用しています。

累積レイアウトシフト (CLS) の理解
累積レイアウトシフトは、ページのライフサイクル全体（ユーザーがページと対話を開始した後も含む）で発生するすべての個々のレイアウトシフトの合計を測定し、関係するエリアのサイズとシフトの距離を考慮します。

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

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

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

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

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

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

ファーストコンテンツフルペイント (FCP) は、コンテンツがページに表示され始めるまでの時間を測定します。

ファーストコンテンツフルペイント (FCP) の理解
FCPの定義は、スタートレンダリングの定義に非常に近いです。ただし、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 の後に最も長いタスクを見つけることによって計算されます（ユーザーがコンテンツが表示される前にページとインタラクションしようとはしないと仮定できます）。

収集元: ウェブブラウザ (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)

Largest Contentful Paint (LCP) は、読み込みパフォーマンスを測定し、Core Web Vitals の一部です。Google は 2021 年から Core Web Vitals を検索ランキングシグナルとして使用しています。

Largest Contentful Paint (LCP) の理解

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

LCP は、最大の（背景画像を除外し、ビューポートの外に表示されるコンテンツを除外します。例: スクロールせずに見える範囲）かつ一貫したコンテンツの提供速度に焦点を当てています（ローダーやスプラッシュスクリーンなどの一時的なコンテンツは無視されます）。

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

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

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

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

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

完全読み込みの理解

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

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

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

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

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

収集元: ビデオ分析

スピードインデックスは、ページコンポーネントの平均表示速度を反映するインデックスです。

スピードインデックスの理解
スピードインデックスは、テストされたウェブページの可視部分（フォールド地点より上）のピクセルの平均表示速度を記録します。その結果、この指標はページを構成するさまざまな要素の表示の進行状況を考慮します（速度が低いほど良い）。

Googleは、スピードインデックスが1000秒未満であることを推奨しています。

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

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

収集元: ビデオ分析

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

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

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

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

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

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

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

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

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

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

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

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

注:開始時間（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とインラインで読み込むようにします。例: 黒が支配的な画像のために黒い背景を設定して、読み込み時間中にスペースを確保します。