パフォーマンスとCore Web Vitals監査

フェーズP3・ステージA — 理解
時間枠： 代表的な監査には4〜8時間。テンプレート全体の調査とエンジニアリングトレースには2〜5営業日。28日間のフィールド検証は修正後に行われ、初期監査の時間枠を延長しません。
担当者： 技術SEOリードが範囲と承認を担当します。パフォーマンスエンジニアまたはシニアフロントエンドエンジニアが診断を担当し、プラットフォーム、CDN、分析、デザイン、プロダクトの各責任者は、自身のシステムが遅延や不安定性を生み出している場合に協力します。

このフェーズでは、実際のユーザーのフィールドエビデンスと再現可能なラボテストを、URL、テンプレート、指標、担当者、完了条件に関連付けられた改善登録簿に変換します。単なる一般的な速度スコアではありません。

このフェーズの目的と実施タイミング

パフォーマンスはステージAに属します。なぜなら、タイムアウトするページは、ユーザー体験の問題である前にクロールの問題だからです。クローラーや検索エージェントには有限のリクエスト予算があります。オリジンが応答を停止したり、リダイレクトを繰り返したり、不完全なレスポンスを返したりすると、クライアントはコンテンツを評価する前にページを放棄する可能性があります。より高速な見出し、優れたコピー、強力なスキーマは、確実に取得されないコンテンツを助けることはできません。

P3は、技術ベースライン監査 からのカノニカルホスト、対象インデックス可能テンプレート、優先ジャーニー、ステータスコードのエビデンス、未解決のインフラストラクチャ調査結果を入力として受け取ります。この順序により、誤った診断を防ぎます。例えば、リダイレクトループによる5秒の「ページ読み込み」は画像最適化タスクではなく、キャッシュされたエラーページの高速テストは合格ではありません。P2は正しいURLがリクエストされ選択可能であることを確立し、P3はそれが許容可能な時間と安定性の範囲内で配信され使用可能であることを確立します。

このフェーズを遅く実行すると手戻りが発生します。コンテンツチームが、ヒーロー画像が常に最も遅い要素であるテンプレートに公開したり、すべてのプロダクトカードを移動させるプロモーション枠を承認したりするかもしれません。その欠陥は新しいページ全体に増殖します。

入力と出力

入力はサンプルを代表的なものにします。出力は次のフェーズとの契約を形成します。つまり、どのページが確実に利用可能か、どの条件が依然として弱いか、どのパフォーマンス制限が後続の測定に影響を与えるかを明確にします。

フィールドデータとラボデータは異なるエビデンス

フィールドデータは、対象となるChromeユーザーが実際に体験した内容を記述します。Chrome User Experience Report（通常CrUXと略される）は、実際の訪問からの測定値を集約し、75パーセンタイル（記録された体験の75%が該当する値以下）を報告します。これには、実際のデバイス、ネットワーク、場所、キャッシュ、同意ツール、セッション、インタラクションの複雑さが含まれます。これを使用して、ユーザーが公開されたしきい値を通過しているかどうか、およびリリースされた変更が最終的にユーザー集団を改善したかどうかを判断します。

ラボデータは、宣言された条件下での1回の制御されたページ読み込みまたはインタラクションを記述します。Lighthouseは、デバイスとネットワークのシミュレーションを適用し、トレースをキャプチャし、考えられる原因を説明するラボテストです。これを使用して、問題を再現し、同じ設定で2つのビルドを比較し、リクエストチェーンを検査し、作業を特定します。ラボスコアは有用なエビデンスですが、実際のユーザーが合格することを証明するものではありません。

2つの情報源は、どちらも間違っていなくても一致しないことがあります。高速なラボ実行は、近くの場所、ウォームCDN、意味のあるインタラクションなしで行われる一方、フィールド訪問者には古い電話や遠方のネットワークが含まれる場合があります。不一致を記録し、その条件を調査してください。値を平均したり、より健全に見える方を選択したりしないでください。

チェックリスト

これらのチェックは順番に完了してください。各項目には、アクション、理由、方法、ツール、および受理条件が記載されているため、割り当てと再テストが可能です。

1. 代表的なURLと条件マトリックスを確定する

何をするか： テストするURL、テンプレート、デバイスプロファイル、地域、同意状態、キャッシュ状態を定義します。理由： ホームページのみの監査が合格しても、プロダクト、記事、またはチェックアウトテンプレートが不合格になる可能性があります。方法： P2のインベントリとトラフィックおよびビジネス優先度データを結合し、典型的な例、重い例、コンバージョンに重要な例を選択します。ツール： 分析、クロールインベントリ、リリース登録簿、共有テストシート。完了条件： すべての優先テンプレートに担当者承認済みの本番サンプルがあり、すべてのテストがデバイス、ネットワーク、場所、ログイン、同意、キャッシュの前提条件を記録していること。

2. CrUXフィールドベースラインを取得する

何をするか： URLレベルと、別途オリジンレベルで利用可能なp75フィールド指標を記録します。理由： オリジンは弱いテンプレートを隠す可能性があり、個別の低トラフィックURLには公開可能なデータがない場合があります。方法： 同じ観測日と28日間ウィンドウを使用し、URLとオリジンを明示的にラベル付けし、空白の値は「データ不足」として記録します。ツール： AmICited Web VitalsおよびCrUX。完了条件： サンプリングされたすべてのURLにLCP、INP、CLS、FCP、TTFBの値または文書化された不明状態があり、ソースレベルとウィンドウが明確であること。

3. ピクセルをスコアリングする前にレスポンスの信頼性を確認する

何をするか： リクエストを繰り返し、ステータス、リダイレクト、Time to First Byte（TTFB）、タイムアウト、一貫性のないレスポンスを記録します。TTFBは、リクエスト開始から最初のレスポンスバイトが到着するまでの間隔です。理由： HTMLの到着が始まる前にページは描画できず、断続的な障害は表面的な速度低下よりも深刻です。方法： 該当地域からのコールドおよびウォームキャッシュ動作をテストし、サーバータイミングを検査し、異常をCDNおよびオリジンログと関連付けます。ツール： リクエストモニター、ブラウザネットワークパネル、CDN/オリジン観測ツール、Lighthouseウォーターフォール。完了条件： 優先URLが意図した200レスポンスを予期しないホップやタイムアウトなしで返し、すべての低速または失敗したレスポンスに担当者付きのログ記録された調査結果があること。

4. Largest Contentful Paintを診断する

何をするか： Largest Contentful Paint （LCP）要素を特定し、その時間をサーバー遅延、リソース発見、リソースダウンロード、レンダリング遅延に分解します。LCPは最大の可視画像またはテキストブロックがレンダリングを完了するタイミングを測定します。理由： ブラウザがリソースを遅く発見する場合、画像を圧縮しても効果はほとんどなく、フロントエンドの変更では遅いオリジンの待機時間を消せません。方法： トレースとウォーターフォールを検査し、キャッシュありとなしの実行を比較し、プリロードの優先順位、レスポンシブ画像サイズ設定、レンダリングブロッキングリソース、フォント動作、クライアントサイドレンダリングを確認します。ツール： Lighthouse、ブラウザパフォーマンスツール、リクエストウォーターフォール、画像検査。完了条件： 不合格の各テンプレートについて、実際のLCP要素と支配的なサブパートが特定され、再現可能なbefore測定と具体的な修正仮説が存在すること。

5. Interaction to Next Paintを診断する

何をするか： Interaction to Next Paint （INP）の経路を、メニュー開閉、フィルタリング、カート追加、フォーム入力、同意バー却下などの実際のアクションでテストします。INPは、ユーザーのインタラクションからブラウザが次の視覚的更新を表示するまでの遅延を測定し、訪問中の高レイテンシインタラクションを使用します。理由： ページは完全に見えても、JavaScriptがメインスレッドを占有している間はユーザーを無視し続けることがあります。方法： 重要なアクションを再現し、長時間タスクとイベントハンドラを検査し、サードパーティスクリプトをテストし、入力遅延、処理時間、表示遅延を分離します。ツール： CrUX、ブラウザパフォーマンストレース、インタラクションプロファイリング、現実的なデバイス。完了条件： すべての重要なインタラクションが実行され、不合格テンプレートについて遅いインタラクションと原因タスクが特定され、修正に再現可能なインタラクションテストがあること。

6. Cumulative Layout Shiftを診断する

何をするか： Cumulative Layout Shift （CLS）に寄与する予期しない動きを特定します。CLSは、ページのライフサイクル中に発生する予期しない視覚的動きを表す単位なしのスコアです。理由： 遅れて表示されるバナー、サイズ未指定の画像、スワップされるフォント、広告、またはハイドレーションされたコンポーネントが、ユーザーがクリックしようとしているリンクを移動させ、自動抽出がコンテンツを発見する場所を変える可能性があります。方法： レイアウトシフト領域とフィルムストリップを使用し、遅延アセットと同意状態をテストし、予約寸法のない要素を検査します。ツール： CrUX、Lighthouseトレース、ブラウザレンダリング診断、視覚的リグレッションキャプチャ。完了条件： 各重要なシフトに原因要素、トリガー、およびスペース予約またはレンダリング修正があり、ユーザーアクションによって即座に発生する予期された動きは別途文書化されていること。

7. FCPを使用して空白画面の遅延を分離する

何をするか： First Contentful Paint（FCP）、つまりブラウザが最初のテキスト、画像、キャンバス、またはSVGコンテンツをレンダリングするまでの時間を測定します。理由： FCPは、主要コンテンツの準備ができていることを証明するものではありませんが、ページが空白のままである状態からの初期の進展の兆候を区別します。方法： FCPをTTFBおよびLCPと比較し、ブロッキングCSS、フォント、スクリプト、サーバーレンダリングマークアップ、ストリーミング動作を検査します。ツール： CrUX、Lighthouse、ネットワーク/パフォーマンストレース。完了条件： すべての遅いFCPが、単に「ページが遅く感じる」と説明されるのではなく、サーバー遅延、レンダリングブロッキング、クライアント専用レンダリング、またはその他の立証された原因に割り当てられていること。

8. 調査結果を重大度、影響範囲、依存関係でランク付けする

何をするか： バックログを不合格バンド、影響を受けるトラフィックとテンプレート、ビジネス重大度、上流の依存関係で順序付けます。理由： 5つのイエロースコアを修正してもスプリントを消費する一方、1つのレッドTTFB障害がオリジン上のすべてのページを遅延させる可能性があります。方法： 信頼性の失敗を最初に配置し、次に改善必要指標よりも不良指標を優先します。同じ重大度内では、共有プラットフォーム原因とTTFBを下流のLCP作業より先に修正します。ツール： 調査結果登録簿、分析、テンプレートインベントリ、エンジニアリング見積もり。完了条件： すべての調査結果に重大度、影響を受けるURL数またはテンプレート範囲、エビデンス、担当者、工数、依存関係、明示的な優先順位があること。

9. ラボで実装を検証する

何をするか： 変更されたビルドを記録されたベースラインと同一条件下で比較します。理由： フィールドデータは即時のリリースフィードバックを提供できず、再現不可能な「after」実行ではコード変更が差異を引き起こしたことを確認できません。方法： 複数の制御されたサンプルを実行し、単一の最良実行ではなく中央値を比較し、トレースでリグレッションを検査し、重要なインタラクションとレイアウトをテストします。ツール： Lighthouse、ブラウザパフォーマンスツール、ステージングまたは制御された本番リリース、リクエストモニタリング。完了条件： 意図した原因が除去され、対象指標が複数回の実行で合意されたラボ予算を通過し、他の重要な指標が後退せず、エビデンスが調査結果に添付されていること。

10. リリースを注釈し、フィールドでの確認を待つ

何をするか： デプロイメント時間、範囲、期待される指標、検証日を記録します。理由： CrUXは28日間のローリングウィンドウであるため、修正が出荷された後もリリース前の訪問が報告されたパーセンタイルに残ります。方法： エラーを即座に監視し、新しいデータが到着するにつれて方向性のあるフィールドの動きを確認し、リリース後の日数がウィンドウを十分に代表するようになってから最終比較を行います。ツール： デプロイメントログ、AmICited Web Vitals、CrUX、モニタリング。完了条件： 即時の技術チェックが合格し、リリース注釈が表示され、フィールド確認のための指名された担当者と日付が存在すること。調査結果はラボエビデンスのみから「検証済み」とマークされないこと。

AmICitedのツール

https://app.amicited.com/audit/web-vitals を開いて、実際のユーザーのCrUXデータを使用してあなたのドメインを追跡中の競合他社と比較します。この監査はLCP、INP、CLS、FCP、TTFBを1つのテーブルにまとめ、あなたのドメインをマークし、フィールドデータの欠落を誤解を招くゼロとして表示するのではなく可視化します。この比較を使用して2つの質問に答えます：ドメインが公開されたしきい値を通過しているかどうか、および同じオーディエンスにサービスを提供する競合他社が実質的に優れたフィールド結果を示しているかどうか。

パフォーマンスインパクト 機能は、ページレベルのパフォーマンスと引用位置および可能性を結び付けます。この関係を優先順位付けのエビデンスとして扱いますが、速度だけで引用が変化したことの証明としては扱いません。遅い引用ページと速い非引用ページが権威、関連性、またはコンテンツで異なる場合、パフォーマンスは1つの変数にすぎません。有用なシグナルは、影響を受けるページが修正および監視する価値があるほど価値があるということです。

製品の操作については、AmICitedでCore Web Vitalsを確認する方法 に従ってください。このプレイブックは監査範囲、決定、ハンドオフを定義します。チュートリアルはクリックと読み取りをカバーしているため、ここで重複すると2つの手順が乖離する可能性があります。

判定ルール：不良の定義

Core Web Vitals は、フィールドデータの75パーセンタイルで判定します。「良好」とは、p75値が良好境界以下であることを意味します。境界上の値はより良いバンドに属します。例えば、LCPが正確に2.5秒の場合は良好です。補助的なFCPおよびTTFBのしきい値は診断と受け入れのガイドとなりますが、3指標のCore Web Vitals合格評価の一部ではありません。

以下の優先順位ルールを使用します：

1. 失敗したリクエスト、タイムアウト、無効なレスポンスはスコアより優先されます。 信頼性は配信ゲートです。
2. 改善必要バンドよりも不良バンドを先に修正します。 レッドは実証された悪い体験であり、単なる改善の機会ではありません。
3. TTFBが不合格の場合、LCPより先にTTFBを修正します。 レスポンスが開始する前にLCPは発生できないため、バックエンドの遅延はブラウザが何もレンダリングできる前にLCP予算を消費します。
4. 孤立した症状よりも共有原因を優先します。 4つのテンプレートにわたる1つのキャッシュポリシー修復は、影響範囲の小さい4つの個別の画像調整より優先されます。
5. 同じ重大度内では、トラフィックとジャーニーの価値を使用します。 不良なチェックアウトINPまたは高トラフィック記事のLCPは、同じバンドの低トラフィックアーカイブより優先されます。
6. 空白のCrUX値を良好と呼んではいけません。 それは不明です。フィールドボリュームが存在するまで、再現可能なラボエビデンスと比較可能なテンプレートを使用してください。
7. 即座のフィールド変動を約束してはいけません。 今すぐデプロイを検証し、その後、ローリングウィンドウが古い体験を置き換えるのを待ってから、フィールド結果を受け入れるか拒否してください。

成果物：パフォーマンス改善登録簿

1つの登録簿とそのエビデンスフォルダをエンジニアリングチームに引き渡します。スプレッドシート、課題トラッカー、または構造化されたプロジェクトテーブルでも、以下のフィールドを保持し、テンプレート、重大度、担当者、ステータスでフィルタリングできる場合は許容されます：

IDと調査内容：
影響を受けるURLとテンプレート：
優先ジャーニーとトラフィックコンテキスト：
指標とフィールドバンド：
CrUXレベル、p75値、28日間ウィンドウ：
ラボ構成と繰り返しベースライン：
観測された原因とエビデンス参照：
期待される条件と目標：
推奨される変更：
重大度と優先順位の根拠：
担当者、依存関係、工数：
リリース日と注釈：
即時のラボ受理結果：
フィールド確認日と結果：
ステータス：未着手 | 計画済み | ラボ受理済み | フィールド検証済み | 許容リスク

URLマトリックス、CrUXエクスポート、ラボトレース、ウォーターフォール、フィルムストリップ、インタラクション録画、レイアウトシフトのエビデンス、リリース注釈を添付してください。原因ごとに重複排除します。同じキャッシュなしオリジンクエリが3つのテンプレートにわたって不良なTTFBを生み出している場合は、3つの競合する診断ではなく、3つの影響範囲を持つ1つの親調査結果を作成します。

「許容リスク」には、指名された承認者、理由、影響範囲、有効期限またはレビュー日、監視条件が必要です。これは担当者の代わりにはなりません。エンジニアが障害を再現でき、次フェーズの担当者がどの結果がパフォーマンスによって制限されているかを特定できるときに、ハンドオフは完了します。

よくある失敗

Lighthouseを最終判定として扱うこと。 1回のラボ実行でのスコア100は、不良なp75フィールドデータを上書きしません。Lighthouseは診断エビデンスとして、CrUXは集団エビデンスとして位置づけてください。

ホームページのみをテストすること。 すべての高価値テンプレートと重い例をサンプリングしなければ、テンプレートの欠陥が監査をすり抜けます。

TTFBを確認する前にLCP画像を最適化すること。 アセットは小さくても、オリジンがHTML生成に2秒費やしている可能性があります。LCPをその構成要素に分解し、上流の時間を先に修正してください。

単一の最速実行を使用すること。 キャッシュの温かさ、バックグラウンドアクティビティ、ネットワークの変動が、見栄えの良い外れ値を生み出すことがあります。構成を固定し、複数実行の中央値を比較してください。

リリース翌日に勝利を宣言すること。 ラボはコードと配信が即座に変更されたことを証明できますが、28日間のフィールドウィンドウはそうではありません。リリースを注釈し、フィールド受理をスケジュールしてください。

欠落したCrUXデータをゼロとしてマークすること。 データがないことは、対象基準またはトラフィックしきい値が満たされなかったことを意味します。パフォーマンスの品質については何も語っていません。

失敗している体験ではなく複合スコアを追いかけること。 要約スコアが改善しても、チェックアウトのインタラクションが依然として停止したり、ヒーローが移動したりする可能性があります。名前付き指標とジャーニーを受け入れ、表面的なスコアの動きは無視してください。

テストに合格するために有用な機能を削除すること。 同意、パーソナライゼーション、分析、アクセシビリティ動作をラボバリアントから削除すると、ユーザーが決して受け取らない結果が生まれます。本番要件を最適化するか、明示的なプロダクト判断を行ってください。

対象指標以外のリグレッションを無視すること。 スクリプトを遅延させるとLCPは改善しても、最初のインタラクションで不良なINPを生み出す可能性があります。間違った寸法を予約すると、読み込み遅延がCLSに置き換わる可能性があります。5つの指標すべてと重要なジャーニーを再テストしてください。

次のフェーズ：AIアクセシビリティとエージェント readiness

AIアクセシビリティとエージェント readiness フェーズは、代表的なURLマトリックス、レスポンス信頼性のエビデンス、TTFB分布、未解決のパフォーマンス調査結果、および初期レスポンスにどのコンテンツが存在するかのステートメントを受け取ります。その担当者は、そのエビデンスを使用して、アクセスポリシーの失敗と配信の失敗を区別し、エージェントがページを取得する実際の条件を再現します。

次のフェーズは、重要なURLが確実に応答し、未解決のパフォーマンス欠陥が検索エビデンスを解釈不可能にしていない場合に進行できます。改善必要指標がユーザーに影響を与えるが、安定したアクセスを妨げない場合は、文書化された制限付きで進行できます。リクエストがタイムアウトする、断続的なエラーを返す、またはメインレスポンスが合意された重要なしきい値を定期的に超える場合は、影響を受けるテンプレートについて一時停止する必要があります。

次の担当者が、各テンプレートを表すURL、テスト条件、残存する配信障害、およびP3のエビデンスがすでに遅いエージェント取得を説明しているかどうかを把握した時点で、ハンドオフは完了です。

FAQ

よくある質問