サイト平均ではなくジャーニーから始める
遅延に明確な顧客や運用上のコストがあるジャーニーを3〜5件挙げます：キャンペーンページのランディング、商品検索、リードフォームの送信、サインイン、サポートリクエストの完了など。各ジャーニーについて、開始点、達成と見なす有用な結果、主要なデバイスクラス、および正常に動作すべきページや操作を書き出します。
各ジャーニーに独自の予算行を与えます。ダッシュボードは公開記事より多くのコードを含むかもしれませんが、フィルタ操作には応答性目標が必要です。メディアの多い商品ページは大きな画像を許容できても、主要な可視画像に対する上限は必要です。こうすることで、クリティカルパスの弱点がオリジン全体の平均に埋もれるのを防げます。
訪問者が見たりできたりすること（オファーを読む、結果を見る、フォームの確認を受け取るなど）を名前で定義します。
キャッシュによりアセットコストが大きく変わるため、予算が初回訪問、再訪問、または両方を想定しているかを記録します。
成果と制御可能な入力を両方選ぶ
成果指標（アウトカム）と入力上限の両方を使います。Google は Largest Contentful Paint（LCP）を読み込みの指標、Interaction to Next Paint（INP）をインタラクション応答性の指標、Cumulative Layout Shift（CLS）を視覚的安定性の指標として説明しています。推奨される良好な閾値は、モバイルとデスクトップを別にして75パーセンタイルで LCP ≤ 2.5 秒、INP ≤ 200 ミリ秒、CLS ≤ 0.1 です。
原因を早期に露出する上限を追加します：初期の JavaScript、主要コンテンツ前に必要な画像、ルート全体の転送量、サードパーティのリクエスト、既知の高コストウィジェットなど。圧縮後の転送サイズを一貫して追跡してください。診断指標として Time to First Byte（TTFB）は遅い読み込みを調査するのに役立ちますが、それ自体が顧客の体験結果ではありません。
ジャーニーが主要コンテンツの可視化に依存する場合は LCP を使います。
検索、フィルタ、メニュー、チェックアウトなどにはフィールドの INP を使い、フィールドデータがないときはラボのプロキシを使います。
初期ルートと最大寄与要素に上限を設け、違反時にどこを変えるべきかを明示します。
基準値（ベースライン）から数値を設定する
各ジャーニーのベースラインを取得します。PageSpeed Insights では、Chrome User Experience Report（CrUX）などのフィールドデータ（実際の Chrome ユーザーの体験を集計したもの）と、Lighthouse のようなラボデータ（制御されたテスト）を区別してください。フィールドデータはユーザーに到達する体験を確認し、ラボテストはリリース前に変更を再現可能にします。
少なくともモバイルとデスクトップでセグメントし、可能なら重要なテンプレートや URL ごとに区分します。PageSpeed Insights は URL データがない場合にオリジンデータにフォールバックすることがあり、CrUX データが存在しないページもあります。その場合はそのジャーニーをラボベースラインとしてラベル付けし、重要なジャーニーには実ユーザー計測を追加してください。各ベースラインにはテスト URL、デバイスとネットワークのプロファイル、キャッシュ状態、日付、ツールのバージョンを記録します。
現状より改善する計画的なステップになる目標を選び、代表的な条件でテストします。リリースを通常阻むような予算は簡単に回避され、現状より甘い予算は誰も保護しません。
75パーセンタイルは観測された体験のうち75％がその値以下である点であり、平均値ではありません。
予算をリリースルールにする
予算をコードやリリースチェックリストのそばにバージョン管理されたレビュー可能な場所で保管します。各行にはジャーニー、指標、テストプロファイルまたは対象母集団、警告閾値、エラー閾値、オーナー、測定方法、例外ルートが必要です。MDN は警告レベルとエラーレベルを推奨しています：警告は事前計画を支援し、エラーは顕著な悪影響を伴う上限です。
信頼できるチェックを自動化します。バンドラは過大なアセットや初期エントリポイントを拒否できます。webpack は最大アセットやエントリポイント制限、および本番エラー警告をサポートします。プルリクエストやリリース候補で対象ジャーニーの再現可能なラボテストを実行してください。フィールド指標は不安定なビルドゲートではなく、リリース後の検証と優先順位付けのために保ちます。
上限が失敗したときは、アセットを削減する、不要なコードを延期する、体験を変える、リリースを分割する、または例外を承認します。ビルドを通すために閾値をひっそり引き上げてはいけません。
プロダクトと技術のオーナー、顧客影響、期限、是正タスクをリリース前に記録します。
保護されたジャーニーについて再現可能なエラ―閾値でリリースをブロックし、警告閾値は通知して調査します。
ローンチ後の検証と是正
ページ重量だけでは完全な体験を予測できません。リクエスト順、レンダーブロッキング作業、デバイス能力、ネットワーク条件、キャッシュ、サードパーティも影響します。入力上限は成長を検出するために保ち、アウトカム指標でその経路が使えるかをテストします。W3C Resource Timing インターフェースは、詳細な診断のためにリソースのタイミングや転送、エンコード後・デコード後サイズを公開します。クロスオリジンのタイミング詳細は timing permissions によって制限されることがあるため、不完全なウォーターフォールがサードパーティコストの不存在を証明するわけではありません。
テンプレート、プラットフォーム、マーケティングタグ、トラフィックの大きな変更後にはフィールド結果をレビューします。LCP が悪化したらサーバー応答、LCP リソース、レンダーブロッキング作業を調査します。INP が悪化したら実際のインタラクションを検査します；Lighthouse はユーザー入力がないため INP を計測できませんが、Total Blocking Time はラボの代理指標です。SIU のプロアクティブな最適化ワークフローを使って違反をトリアージし、クリティカルパスを安定化させ、同じ計測コンテキストで修正を検証してください。
期限切れの例外は、一時的なパフォーマンス負債が恒久化したことを素早く明らかにします。