Webサイト性能監査：スコアの裏にある遅延を直す

1. ラボと実ユーザー測定を別に読む

Lighthouseは再現しやすいラボ条件でページの診断を助けます。CrUXは十分なデータがある場合、対象となる実ユーザー体験を集約します。利用者、端末、ネットワーク、期間が異なるため、値が一致しない場合があります。PageSpeed Insightsの文書が両方の情報源を説明しています。

各指標の測定元を読みます。ある値は実ユーザーデータ、別の値は代替のラボ値というレポートもあります。実ユーザーの証拠が正確なURLかオリジン全体かも確認します。データ不足はサンプルの欠落であり、Core Web Vitals不合格や訪問者不在の証明ではありません。

2. 3つのCore Web Vitalsを理解する

実ユーザー評価ではデバイス分類を分け、訪問の75パーセンタイルで基準を見ます。Web Vitalsを参照してください。1回のラボ値を実ユーザーの合格として扱ってはいけません。TTFBとFCPは有用な診断値ですが、追加のCore Web Vitalsではありません。

3. 症状と証拠を対応させる

以下は優先順位の例です。診断名より、主要操作への実際の影響が重要です。

改善候補の推定時間は保証ではありません。2つの提案が重複することも、重そうな資源が必要なこともあります。機能の削除や基盤の交換前に、原因を確認しましょう。

4. 遅延を生む部品を直す

主内容が遅い場合：まずLCP要素を特定します。サーバー応答が遅ければバックエンド処理とキャッシュを調べます。ヒーロー画像の発見が遅ければ文書内で早く取得可能にし、最初の目立つ画像を遅延読み込みしないようにします。適切なサイズで配信してください。LCP最適化ガイドは段階ごとに説明しています。

操作が遅い場合：重いハンドラー、同期描画、外部処理を調べます。長いタスクを分け、操作周辺の不要な仕事を減らします。Total Blocking Timeはラボ診断に役立ちますがINPとは別の指標です。INPガイドと実際の操作記録を使います。

配置が動く場合：画像、埋め込み、バナーが届く前に領域を確保します。どの要素が、なぜ動くかで正しい修正は変わります。

5. 条件をそろえて前後比較する

1. 正確なURL、デバイス条件、時間、情報源を記録する。
2. 観測した原因に対応する一貫した変更を一つ行う。
3. 比較可能なラボ試験を複数回繰り返し、最良の1回でなく傾向を見る。
4. 画面を確認し、主要操作を完了する。
5. 共通部品が別テンプレートを悪化させていないか確認する。
6. 実ユーザーデータは後で観察する。集計期間には直近の公開がすぐ反映されない。

スコア画像だけでなく診断の証拠を残します。画像の修正で読み込みが良くなっても配置が動くようになったなら未完了です。狭い画面、Cookie通知、フォント、埋め込み部品など後から現れる内容を再確認します。

6. テストで分からないことを把握する

1回のページ読み込みで複雑なアプリの全状態は試せません。初期表示が速くても、長時間の編集後に反応が悪くなる場合があります。ラボ試験の同意状態、アカウント、内容が顧客と同じとは限りません。

Sitelemetryのホスト型レポートは選択条件と測定元を示します。Local Agentは別の限定的手法でローカル配信を調べるため、公開Lighthouseスコアと数字を比較しないでください。PageSpeedが使えないなら不足測定を解決・再試行し、空欄をゼロと解釈しないでください。何が実行されたかを明示します。

7. 速度を製品開発の流れに組み込む

担当するテンプレートと操作に予算を設けます。画像転送量、外部スクリプト、高負荷のクライアント処理は有用な確認項目です。チャット部品、分析ツール、アニメーションを加える際は、提供元の負荷がないと思い込まず、対象ページで前後比較します。

正しさ、アクセシビリティ、速度を一緒に保ちます。内容を隠して高スコアにするより、安定して進行状況を伝えるフォームの方が有用です。重要なモバイル集客・転換ページを優先し、利用できる性能監査から測定可能な合格条件を持つ修正課題を一つ作ります。同じ部品が関わるならアクセシビリティ確認と連携監査も組み合わせましょう。