Core Web Vitals 改善チェックリスト

チェックリスト： Core Web Vitals 改善。タイムボックス： スコープと診断の確認に営業日 1 日。原因がアセット、共有テンプレート、サードパーティスクリプト、オリジン、または CDN のいずれにあるかに応じて、標準的な修正とリリースに 1〜10 営業日。フィールド検証は 28 日間のローリングデータウィンドウに従い、別途スケジュールされます。所有者： パフォーマンスエンジニアまたはシニアフロントエンドエンジニアが責任を負います。テクニカル SEO リードがフィールド受け入れ基準を所有し、プラットフォーム、デザイン、アナリティクス、プロダクトのオーナーがそれぞれのシステムでの変更を承認します。

このチェックリストは、診断されたパフォーマンスの結果を、リリースされフィールド検証された修正に変えます。Core Web Vitals は、読み込み、応答性、視覚的安定性に関する Google の実ユーザー指標です：Largest Contentful Paint（LCP）、Interaction to Next Paint（INP）、Cumulative Layout Shift（CLS）。Time to First Byte（TTFB）と First Contentful Paint（FCP）は補助的な診断指標です。これらが含まれているのは、遅いレスポンスや空白画面が、良好な LCP を達成するための時間を消費するためです。

このチェックリストの目的と位置づけ

このチェックリストは、パフォーマンスと Core Web Vitals 監査 からの改善登録簿を消費します。その前のフェーズでは、不合格となっている指標、影響を受ける URL とテンプレート、実ユーザーのベースライン、再現可能なラボ条件、疑われる原因、優先順位、所有者を特定します。改善は、これらのフィールドが存在した後にのみ開始されます。そうでなければ、開発者は「サイトを高速化する」よう求められ、それがフィールドの不合格の原因であるかどうかに関わらず、ツールが最初にハイライトするものを自然に変更することになります。

診断は行動前に 3 つのレベルに絞り込む必要があります：どの指標、どのテンプレート、どの要素またはタスク。オリジン全体の TTFB 障害にはプラットフォームの修正が必要です。記事ページのみで LCP が不合格になる場合は、ヒーローコンポーネントが原因かもしれません。製品フィルターを開いた後の INP は、1 つのイベントハンドラーが原因かもしれません。プロモーションページでの CLS は、予約されていないバナーが原因かもしれません。これらを 1 つの問題として扱うと、広範な変更と不明確な所有権が生じます。

修正内でも順序が重要です。TTFB は上流にあります。最初のレスポンスバイトが到着するまで、ブラウザは通常の HTML リソースを発見したり、ページコンテンツをペイントしたりできません。TTFB が不良の場合は、LCP 画像を圧縮する前に、レスポンス生成、キャッシュ、リダイレクト、エッジ配信を修正します。レスポンス時間が予算内に収まったら、リソースディスカバリー、リソースダウンロード、レンダリング、インタラクション、レイアウト安定性の順に進めます。

このチェックリストをスキップすると、監査は単なるレポートに終わります。診断前に実行すると、症状の追跡に陥ります。後半のディスカバリーが支配的なときに画像を圧縮したり、オリジンが遅いときにスクリプトを遅延させたりすることになります。

入力と出力

出力により、将来の所有者が障害を再現し、何がリリースされたかを特定し、ラボ受け入れとフィールド確認を区別できるようになります。

チェックリスト

アイテム 1〜4 は本番環境を変更する前に完了します。アイテム 5〜8 は依存関係順に修正を実装します。アイテム 9〜11 は即時のリリース受け入れとフィールド検証を分離します。

1. 不合格の指標、テンプレート、要素を特定する

内容： 結果を 1 つの指標、影響を受けるテンプレートセット、名前付き要素、リクエスト、タスク、またはサーバースパンに絞り込みます。理由： サイト全体のスコアはデプロイ可能な作業を特定できず、2 つの URL が異なる理由で不合格になる可能性があります。方法： p75 の障害をトレースに結合し、影響を受けるテンプレートと影響を受けないテンプレートを比較します。LCP 要素と遅延、INP インタラクションとタスク、CLS 要素とトリガー、または TTFB リクエストパスとキャッシュ状態を特定します。ツール： CrUX エビデンス、ブラウザトレース、ウォーターフォール、サーバータイミング、テンプレートインベントリ、課題トラッカー。完了条件： 「条件 C において、指標 X がテンプレート Y で不合格となるのは、Z が遅延や移動を引き起こすためである」というエビデンスが存在すること。

2. 代表的なページでスコープを確認する

内容： 関連するすべてのテンプレートについて、典型的な URL と最悪ケースの URL、および影響を受けない対照 URL の 1 つで結果をテストします。理由： 1 ページだけの修正では共有された欠陥が隠れる可能性があり、一方、1 つのコンテンツバリアントが問題を引き起こしている場合にはグローバルな変更が不要な場合があります。方法： デバイス、ネットワーク、場所、同意、ログイン、キャッシュ条件を一定に保ち、コンポーネントの使用、アセットの重さ、レスポンスタイミング、サードパーティアクティビティ、コンテンツ長を比較します。ツール： アナリティクス、テンプレートインベントリ、ブラウザパフォーマンスツール、リクエストモニター、テストマトリックス。完了条件： スコープ内のすべてのテンプレートが影響ありまたは対照としてマークされ、それぞれに再現可能なエビデンスがあり、リリーススコープが変更が必要なコンポーネント、ルート、アセットファミリー、またはプラットフォームレイヤーを示していること。

3. 目標値の設定と必要な動作の保護

内容： 数値目標、回帰防止策、保持すべき機能を定義します。理由： 「高速化」には受け入れ境界がなく、同意管理ツール、アナリティクスタグ、アクセシブルなフォーカス動作、または製品機能を削除すると、誤った合格を作り出す可能性があります。方法： 以下の判定テーブルから目標を設定し、反復テストが変動する場合はより厳格な内部バッファを追加し、再テストすべきクリティカルジャーニーと非目標指標をリストします。ツール： 結果登録簿、製品要件、アナリティクス計画、アクセシビリティチェック、パフォーマンスバジェット。完了条件： チケットに目標指標と値、ラボ受け入れ方法、フィールド受け入れ方法、保護される動作、許容されるトレードオフ、ロールバック条件、指名された承認者が記載されていること。

4. フロントエンド作業の前に TTFB を確認する

内容： オーディエンスがいる場所から、コールドおよびウォームキャッシュ条件下で TTFB を測定します。理由： TTFB は後続のすべてのペイント時間に含まれます。フロントエンドの作業では、HTML の待機にすでに費やされた時間を回復できません。方法： リクエストを DNS、接続、リダイレクト、CDN 待機、オリジン計算、データベースまたは上流 API 時間、およびストリーミング動作に分割します（計装が許す場合）。キャッシュヒットとミスのレスポンスを比較し、パーソナライゼーションや Cookie が予期せずキャッシュを無効にしないことを確認します。ツール： リクエストウォーターフォール、サーバータイミング、CDN およびオリジンログ、アプリケーションプロファイリング、合成リクエストモニタリング。完了条件： TTFB が合意された予算内にあるか、または別のブロッキングプラットフォームの結果が所有されスケジュールされていること。不良な TTFB が説明されていないまま、LCP の調整を開始しないでください。

5. まずサーバーと配信の遅延を除去する

内容： 遅いオリジンレスポンス、キャッシュミス、リダイレクト、または遠方からの配信を修正します。理由： これらの原因はすべての要素を遅らせ、多くの場合複数のテンプレートに影響します。方法： 回避可能なリダイレクトを除去し、安全な HTML とデータをキャッシュし、遅いデータベースや API の処理を削減し、クリティカルパスから作業を移動し、CDN ルーティングとキャッシュキーを調整します。承認された設計なしにプライベートレスポンスをキャッシュしないでください。ツール： アプリケーションプロファイラー、クエリトレース、CDN 設定、レスポンスヘッダー、モニタリング、負荷テスト。完了条件： 繰り返しのコールドおよびウォームテストが予算を満たし、キャッシュバリアントが正しく、エラーが後退せず、優先 URL が余分なホップなしに意図したレスポンスを返すこと。

6. LCP のディスカバリー、転送、レンダリング遅延を修正する

内容： 最大の表示画像またはテキストブロックがレンダリングされる Largest Contentful Paint を短縮します。理由： 特大のヒーロー画像は一般的ですが、後半のディスカバリー、低優先度、ブロッキング CSS、JavaScript、またはフォントが支配的な場合があります。方法： 適切なサイズのレスポンシブ画像を提供し、スクロールせずに見える範囲の LCP アセットを遅延ロードせず、初期 HTML で公開し、エビデンスがある場合のみ優先ロードまたはプリロードし、レンダリングブロッキングを除去し、適切なフォールバックを持つサブセット化されたキャッシュ可能なフォントを使用します。ツール： LCP 内訳、ウォーターフォール、画像検査、カバレッジレポート、トレース、視覚比較。完了条件： 意図した LCP 要素が一貫しており、その支配的な遅延が減少し、代表的なページが予算を満たし、帯域幅、テキストの可視性、レンダリングが後退しないこと。

7. 該当するインタラクションで INP を修正する

内容： 応答性の指標である Interaction to Next Paint の原因となっているインタラクションの遅延を削減します。理由： 任意の JavaScript を削除しても、遅いイベントに触れない可能性があります。方法： 入力、処理、表示の遅延を分離し、ロングタスクを分割し、同期作業を除去し、非緊急のサードパーティを遅延させ、繰り返しのレイアウトを避け、再レンダリングを削減し、ペイントのために譲歩します。本番のサードパーティを使用して現実的なハードウェアでテストします。ツール： インタラクショントレース、メインスレッドプロファイル、ロングタスクエントリ、フレームワークプロファイラー、現実的なデバイス。完了条件： クリティカルなインタラクションが機能し、該当するタスクが反復テストの予算を満たし、フィールドプロキシが文書化され、アナリティクス、同意、キーボード、スクリーンリーダーの動作が後退しないこと。

8. 最終レイアウトを予約して CLS を修正する

内容： Cumulative Layout Shift に寄与する視覚的安定性スコアの移動を防ぎます。理由： 画像、フォント、広告、バナー、埋め込み、非同期コンポーネントはすべてインターフェースをシフトさせる可能性があります。方法： 固有の寸法または aspect-ratio を設定し、動的モジュール用のスロットを予約し、互換性のあるフォントフォールバックを使用し、transform でアニメーション化します。ツール： レイアウトシフト領域、トレース、フィルムストリップ、視覚回帰テスト、スロットル適用済みブラウザ。完了条件： すべての重要なシフトクラスターに名前付きのソースがあり、ページが読み込みとクリティカルインタラクションを通じて CLS 予算を満たし、予約されたスペースがコントロールを隠さないこと。

9. 指標セット全体と保護されたジャーニーを再テストする

内容： リリース候補を凍結されたベースラインと同一条件下で比較し、その後本番環境でテストします。理由： 1 つの指標を改善すると別の指標を損なう可能性があります。JavaScript を遅延させると LCP は改善するが最初のインタラクションが悪化する可能性があり、フォントを積極的に変更するとペイントタイミングは改善するがレイアウトシフトが発生する可能性があります。方法： 複数の制御されたサンプルを実行し、最良の実行ではなく宣言された統計量を比較し、トレースを検査し、保護されたジャーニーを実行し、レスポンスの正確さを検証し、影響を受けるテンプレートと対照テンプレートをテストします。ツール： Lighthouse または同等のラボランナー、ブラウザパフォーマンスツール、リクエストモニター、ビジュアルおよび機能テスト、リリースチェックリスト。完了条件： 目標指標が宣言された反復実行方法でラボ予算を満たし、TTFB/FCP/LCP/INP/CLS に深刻な後退がなく、保護された動作が合格し、本番環境が意図した変更を提供し、ロールバックがトリガーされていないこと。

10. リリースに注釈を付け、フィールドレビューをスケジュールする

内容： デプロイメントタイムスタンプ、変更スコープ、目標指標、期待される方向性、フィールドレビュー日付を記録します。理由： CrUX は 28 日間のローリングウィンドウを使用するため、デプロイ後もリリース前のエクスペリエンスが報告された p75 に残ります。注釈がなければ、チームは良好な修正を時期尚早に効果がないと判断したり、後の変動を誤ったリリースに帰属させたりする可能性があります。方法： 本番バージョンを結果に添付し、エラーを即座に確認し、初期のフィールド測定値を最終結果として扱わずに記録し、十分にリフレッシュされたウィンドウをレビューするための所有者をスケジュールします。ツール： デプロイメントログ、課題トラッカー、CrUX、AmICited Web Vitals、モニタリング。完了条件： チケットが ラボ受け入れ とマークされ、リリース注釈と即時エビデンスが添付され、フィールド検証のための指名された所有者とカレンダー日付が存在すること。

11. フィールドデータと照合して検証し、クローズまたは再開する

内容： ローリングウィンドウが十分にリフレッシュされた後、同等の p75 フィールドデータを比較します。理由： 実ユーザーのデバイス、ネットワーク、地理的位置、キャッシュ動作、同意状態、インタラクションを 1 回のラボ実行で代表することはできません。方法： 同じ CrUX レベル（URL またはオリジン）、同じ指標、同等のオーディエンススコープを使用し、部分的なロールアウトや他のリリースを考慮し、オリジンの集計のみに頼らずテンプレート代表を検査します。結果が届かない場合は、現在のトレースを元の原因ステートメントと比較し、無関係な調整を積み重ねるのではなく、診断を再開します。ツール： AmICited Web Vitals、CrUX 履歴、リリース注釈、アナリティクスセグメント、エビデンスパック。完了条件： 目標が合意された p75 しきい値とスコープを制限事項とともに満たした場合、ステータスは フィールド検証済み になります。または、新しいエビデンス、所有者、次の仮説とともにチケットが明示的に再開されます。

AmICited のツール

AmICited Web Vitals を開いて、自社ドメインと追跡中の競合他社の CrUX から LCP、INP、CLS、FCP、TTFB を表示します。診断時にフィールドベースラインを取得するため、デプロイ後は経過するフィールド結果を検証するために使用します。空白の値は、適格なフィールドデータが不十分であることを意味し、ゼロや合格を意味しません。製品ビューが判定をサポートしますが、トレース、サーバータイミング、ブラウザプロファイルは依然として原因を特定します。

パフォーマンスインパクト を使用して、ページレベルのパフォーマンスエビデンスを引用位置に結び付け、価値のある遅いページを特定します。この関連付けは改善の優先順位付けに役立ちますが、パフォーマンス単独で引用結果を引き起こしたことを証明するものではありません。変動を解釈する際には、関連性、コンテンツ、権威性、リリースコンテキストを保持してください。

製品ワークフローについては、AmICited で Core Web Vitals を確認する方法 に従ってください。このチュートリアルでは指標の表示場所と競合他社比較の仕組みを説明します。このチェックリストは診断、実装、受け入れを統制します。

判定ルール：不良の基準

フィールド判定には 75 パーセンタイル（p75 と略記）を使用します。記録された適格エクスペリエンスの 75% がその値以下です。境界値はより良い帯域に属します。LCP、INP、CLS が Core Web Vitals のステータスを決定し、TTFB と FCP は作業の順序付けと診断に使用される補助的な指標です。

これらのルールを順に適用します：

1. タイムアウト、サーバーエラー、不正なレスポンス、または壊れたクリティカルジャーニーは、指標スコアに関係なくリリースをブロックします。
2. 不良な TTFB は LCP の上流にあり、最初に改善されます。サーバーがすでにペイント予算の大部分を消費している場合に、画像のみの解決策を主張しないでください。
3. 不良なフィールド指標は「改善が必要」な指標よりも優先されます。同じ帯域内では、共有テンプレートの原因、トラフィック、ビジネスクリティカルなジャーニーを優先します。
4. 空白の URL レベルのフィールド値は 不明 です。ラボエビデンスと文書化されたプロキシを使用しますが、不明を良好と再ラベル付けしないでください。
5. 1 回の合格ラボ実行は不十分です。テスト前にデバイス/ネットワークプロファイルと反復実行方法を宣言してください。
6. 修正は、デプロイされた動作と管理されたテストが合格した場合に ラボ受け入れ となります。比較可能なローリングフィールドデータが合意されたしきい値を満たした場合にのみ フィールド検証済み となります。
7. オリジンデータが合格しても、トラフィックの多いテンプレートが不合格の場合、そのテンプレートの結果がそのスコープで優先されます。集計によって集中したユーザーの問題を消してはいけません。

成果物：改善と検証パケット

根本原因ごとに 1 つのチケットまたは登録簿エントリを引き渡し、1 つの原因が複数のテンプレートに影響する場合は子スコープを設けます。スプレッドシート、課題トラッカー、エンジニアリング文書を使用しますが、以下のフィールドを保持してください：

結果 ID と主要指標：
フィールドソース：URL | オリジン
フィールド p75、帯域、28 日間ウィンドウ：
影響を受けるテンプレートと代表的な URL：
対照テンプレートと URL：
要素、インタラクション、リクエスト、またはサーバースパン：
原因ステートメントとエビデンスリンク：
ラボプロファイルと反復実行ベースライン：
目標、ガードレール、保護されたジャーニー：
選択された改善と却下された代替案：
エンジニアリング所有者、承認者、依存関係：
リリース/バージョン ID とデプロイメントタイムスタンプ：
即時の本番およびラボ結果：
CrUX フィールドレビュー所有者と日付：
比較可能なフィールド結果と制限事項：
モニタリングしきい値と再開ルール：
ステータス：未着手 | 実装中 | ラボ受け入れ | フィールド検証済み | 再開 | リスク承認

トレース、ウォーターフォール、サーバースパン、シフト記録、インタラクションプロファイル、テスト出力、リリース注釈を添付してください。リスク承認には、スコープ、理由、承認者、有効期限、モニタリングトリガーが必要です。これは合格ではありません。

パケットは、別のエンジニアが元の問題を再現し、この変更がなぜそれに対処するのかを特定し、本番環境に何が到達したかを確認し、元の調査者に作業の再構築を求めることなくフィールド比較を繰り返せる場合に受け入れられます。

よくある失敗

原因を特定する前に最適化すること。 汎用的な圧縮とスクリプト削除が診断に取って代わります。まず指標-テンプレート-要素のエビデンスを要求してください。

オリジンが遅いのにヒーロー画像を圧縮すること。 小さな画像でも、HTML が到着するまではレンダリングできません。TTFB が予算外の場合は、まずそれを測定して改善してください。

間違ったシフトを修正すること。 CLS は広告、同意バナー、フォント、埋め込み、またはハイドレートされたコンポーネントから発生する可能性があります。シフトのソースを特定してください。

すべてのスクリプトを遅延させること。 無差別な遅延は、同意の順序、アナリティクス、ナビゲーション、フォーム、または最初のインタラクションを壊す可能性があります。該当する実行パスを変更し、必要な動作を回帰テストしてください。

共有テンプレートのリリース後に 1 つの URL だけを検証すること。 選択された例は合格しても、負荷の高いコンテンツバリアントや別のコンポーネント設定は依然として不合格になる可能性があります。典型的、負荷の高い、対照の各ページをテストしてください。

オリジンレベルのデータをテンプレートの合格として読むこと。 健全な高トラフィックページが、弱いカテゴリ、記事、または製品テンプレートを隠す可能性があります。診断と受け入れを、最も狭い信頼できるスコープに保ってください。

デプロイ当日にクローズすること。 即時テストはラボ受け入れを確立します。それはローリングフィールドデータウィンドウに代わるものではありません。

壊れたリリースを発見するために 28 日間待つこと。 フィールド確認には時間がかかりますが、ステータスコード、エラー、ジャーニー、視覚的安定性、管理された指標は即座にチェックされます。ローリングデータはリリース QA をスキップする言い訳にはなりません。

次のフェーズ：継続的なモニタリングと反復

フィールド検証記録、リリース注釈、影響を受けるテンプレート、制限事項、しきい値を 継続的なリフレッシュと反復 に引き渡します。安定したベースラインが必要であり、後続のコンテンツ、メディア、テンプレート、キャンペーン、サードパーティの変更を、説明のつかない変動として再発見するのではなく比較できるようにします。

次の所有者は、各しきい値を誰が監視するか、エビデンスがどこにあるか、どのくらいの頻度でレビューされるか、何が改善を再開させるかを記録します。新たに不良となった指標、完全にリフレッシュされたウィンドウ全体での「改善が必要」の繰り返し傾向、変更された LCP 要素、新しい遅いインタラクション、または診断されたパスを変更するテンプレートリリースは、チェックリストの項目 1 から再開する必要があります。前回の修正を自動的に繰り返さないでください。同じ指標でも、リデザイン後に異なる要素で不合格になる可能性があります。

フィールドステータスが明示的で、受け入れられたすべての制限事項に所有者とレビュー日付があり、モニタリングが回帰をテンプレートとリリースに結び付けられる場合に、引継ぎは完了です。フィールド検証が保留中の場合は、次の所有者がスケジュールされたレビュー日付を受け取り、チケットはクローズではなく ラボ受け入れ のままとなります。

FAQ

Core Web Vitals 改善 FAQ