各指標が何を伝えているかを把握する
Largest Contentful Paint（LCP）は、初期ビューポート内の最大の画像やテキストブロックがいつ描画されたかを測る。Interaction to Next Paint（INP）は、訪問中の最も遅い適格な操作を通じて応答性を評価する。Cumulative Layout Shift（CLS）は、訪問中に発生する予期しない視覚的移動を測る。
Google が公表している体験ターゲットは、LCP が 2.5 秒以下、INP が 200 ミリ秒以下、CLS が 0.1 以下である。これらは、ページ読み込みの 75 パーセンタイルで評価し、モバイルとデスクトップを分けて見る。ターゲットは作業に集中するための目安であり、ランキングの保証や遅い訪問者を無視する理由にしてはならない。
主要コンテンツの表示が遅い。サーバー、リソース検出、ダウンロード、レンダリング経路を調査する。
クリック、タップ、キー押下の視覚応答が長く待たされる。埋め込みフレームなどが原因になり得る。
コンテンツが予期せず移動する。コントロール、フォーム、読書位置付近のシフトに特に注意する。
優先順位はフィールドデータに任せ、ラボで説明する
フィールドデータは実際の訪問から来る情報で、実デバイス、ネットワーク、場所、キャッシュ状態、ユーザー行動を含む。Chrome User Experience Report（CrUX） のデータは、十分なデータがあれば PageSpeed Insights や Search Console に表示される。自前の実ユーザーモニタリングはページビューの文脈を追加できる；必要なテレメトリのみを収集し、顧客が入力したコンテンツは避ける。
ラボデータは選択した条件下で再現可能なテストである。リリース変更を切り分けてトレースを読むのに有用だが、すべての訪問者を代表するものにはならない。Lighthouse は実際の操作なしでは真の INP を測定できないため、Total Blocking Time は診断用の代替指標となる。結果が異なるときは、優先付けにフィールドデータを使い、原因調査にラボデータを使う。
データが URL 単位かオリジン（サイト）単位か、モバイルかデスクトップかを記録する。
ベースラインに日付、ページグループ、デバイス、分布、テスト設定、最近のリリース情報を保存する。
到達度・業務への影響・証拠・可逆性でトリアージする
ダッシュボードの最も低い数値から手を付けない。候補を、影響を受ける訪問数、訪問者タスクの重要性、テンプレートにまたがる繰り返し性、変更を分離してロールバックできるかで順位付けする。これにより core web vitals 最適化はスコア追いかけではなく運用上の修復作業になる。
共有テンプレート上の画像寸法欠如は、投機的なフロントエンド書き換えよりも優先すべき場合がある。完了を妨げる、よりまれなチェックアウト操作は優先度が上がる。メトリクスの証拠をサポートのフィードバック、ファネル観察、アクセシビリティレビューと組み合わせる。
重要なテンプレートでフィールド観測され繰り返す問題、かつ明確で低リスクな対処法があるもの。
測定されたユーザー問題やロールバック手段がないアーキテクチャ提案。仮説として保管する。
LCP は主要コンテンツへの経路を短くして直す
影響を受けるページとデバイス群で LCP 要素を特定する。初期 HTML レスポンス、ブラウザが要素を発見するタイミング、リソースのダウンロード時間、レンダリングを妨げるものを点検する。サーバー応答時間（TTFB）が高いと、ヒーローアセットを最適化しても LCP ターゲットが現実的でなくなることがある。
デザインに合う場合は、主要コンテンツを早期に発見できるように保つ。LCP 要素となる画像は遅延読み込み（lazy-load）してはならない。画像主体のページでは、適切なサイズとエンコードを用い、明示的な寸法を指定する。プリロードや配信ルールをテストする：早期リクエストは、より重要な作業と競合しない場合にのみ有用である。
リダイレクト、サーバー処理、キャッシュ挙動、配信の近接性をチェックする；これはアプリケーションやホスティングの所有範囲になることがある。
クライアント側レンダリング、スクリプト、CSS がメインのテキストや画像の検出を遅らせていないか確認する。
操作を応答性高く、レイアウトを予測可能にする
INP のためには、ブラウザのトレースで遅いフローを再現する。入力遅延、イベント処理、描画遅延を切り分ける。長時間のメインスレッドタスク、重いハンドラ、高コストのレンダリング、レイアウトの thrashing（連続再計算）は次のペイントを遅らせる。次フレームの視覚的作業を優先し、製品要件が許す場合は重要でない保存、解析、二次更新を後回しにする。
CLS のためには、合計値から推測せずに動いている要素を特定する。画像、動画、広告、埋め込み、フレームには寸法または CSS のアスペクト比で空間を確保する。フォント読み込みや注入コンテンツを確認する。スコア向上のために必要な同意、エラーメッセージ、アクセシビリティメッセージを隠してはならない；安定した位置を与えること。
作業を遅延させるとアプリケーションのタイミングが変わる。状態、検証、キーボード挙動を回帰テストする。
lazy-load や埋め込み箇所をスクロールして確認する；読み込み時のみのテストは後続のシフトを見逃す可能性がある。
改善は安全にリリースし、効果を確認する
パフォーマンス変更はスクリプト、キャッシュ、レンダリング、埋め込み、配信設定に影響する可能性がある。変更を段階的に行い、定義したテストパスをベースラインと比較し、ロールバック手順を文書化する。決済、アカウント、規制対象のフローでは、埋め込み、検証、データ処理を変更する前に適切なセキュリティ、コンプライアンス、アクセシビリティのレビュワーを巻き込む。これは教育的な指針であり、コンプライアンス評価ではない。
リリース後は同じラボパスを比較し、通常の報告ウィンドウを通して同等のフィールドセグメントを監視する。非意図の影響（隠れたエラーや読めないインターフェースなど）を確認する。Status Is UP は、定期チェック、明確な修復所有権、インシデント間のロールバック準備を通じてプロアクティブな稼働率最適化を支援する。
各変更をページグループ、メトリクス、所有者、テスト証拠、トレードオフ、ロールバック手順に紐づける。
合成テスト1回の通過で成功宣言をしない；該当する実ユーザーパターンで確認する。