Webパフォーマンス完全ガイド：サイト高速化は何から手をつけるか

「サイトが遅い」には、主な内容が出るまで待つ、ボタンを押しても反応しない、表示途中で配置が動く、といった別々の問題があります。画像を圧縮するだけで解決する場合もあれば、JavaScriptやサーバー、外部サービスを調べる必要がある場合もあります。

最初に行うのは、重要なページと操作を一つ選び、どこで待たされるかを記録することです。この記事では、測定結果から原因の仮説を作り、修正と公開後の確認につなげる順序を整理します。

30秒で要点

• LCPは主な内容の表示、INPは操作への反応、CLSは配置の安定性。 一つの点数だけで原因を決めません。
• 実利用者のデータとラボ測定を併用する。 利用状況を知る測定と、原因を再現する測定には役割の違いがあります。
• 期間・端末・URL範囲を記録する。 データがない状態や、サイト全体の集計を、そのページの合格と取り違えないでください。
• 一つの修正を同じ条件で確かめる。 速くなっても、フォームや表示が壊れた変更は採用しません。

1. 現在のCore Web Vitalsを確認する

2026年10月7日に確認した公式資料では、Core Web VitalsはLCP・INP・CLSです。判定はモバイルとデスクトップを分け、各指標の75パーセンタイルを基準にします。web.devのWeb Vitals解説

表が収まらない場合は、横にスクロールできます

3指標が良好でも、すべての利用者が快適であることや、すべての機能が使えることは保証されません。75パーセンタイルより遅い側の利用も残ります。主要な業務操作と、少数でも困っている利用者の状況を合わせて見ます。

INPはページを開くだけでは分からない

INPは訪問中のクリック、タップ、キー操作を観測し、入力から次の描画までの反応を評価します。入力待ち、イベント処理、描画待ちを含み、訪問内で特に遅かった操作を基に、操作数に応じて外れ値を除く規則があります。通信や非同期処理の最終完了時間をそのまま測る指標ではありません。INPの定義と測定範囲

たとえば送信ボタンの直後に「送信中」と出ても、受理完了まで長く待つことがあります。INPと併せて、業務上の完了までの待ち時間も確認してください。逆に操作がない訪問では、INPが出ない場合があります。空欄を0ミリ秒とは扱いません。

FIDの数値を現在の判定へ流用しない

INPは2024年3月12日にFIDを置き換えました。FIDは最初の操作の入力遅延だけを測り、現在のINPとは範囲が異なります。FIDのサポート終了は2024年9月9日です。置換の公式告知、FIDの終了説明

古い計測コードや社内資料は確認対象ですが、旧FIDの時系列にINPをそのまま継ぎ足して「悪化した」と判定しないでください。

2. 実利用とラボの数字が違う理由

表が収まらない場合は、横にスクロールできます

PageSpeed Insights（PSI）の実利用データはCrUXに基づく直近28日の集計です。URL単位のデータが不足すると、同じオリジン全体の集計に切り替わることがあります。オリジンでも不足すれば、実利用の数値は表示できません。PSIのデータ範囲

したがって、リリース直後のラボ測定と、変更前も含む28日間の値が一致しなくても不自然ではありません。URLかオリジンか、モバイルかデスクトップか、対象期間が何かを記録します。オリジンの良好値だけでは、特定の問い合わせページまで確認したことにはなりません。

PSIには、INPだけがデータ不足の場合にLCPとCLSで合格を判定する条件もあります。表示上の合格を「INPも測って良好だった」と読み替えないでください。LCPまたはCLSのデータが足りない場合は判定できません。PSIの判定条件

通常のLighthouseの読み込み検査は、操作がないためINPを測れません。TBTは関連する診断材料ですが、INPの代わりの実測値ではありません。操作を含むラボ検証とフィールドデータを合わせます。ラボツールとフィールドツール

3. 75パーセンタイルを小さなデータで確かめる

75パーセンタイル（p75）は、値を小さい順に並べたときの75%地点に対応する値です。平均とは違い、遅い側の体験を意識して確認できます。集計方法は複数あるので、自社集計では方式を明記します。

次の教材用の架空LCPデータ8件を使います。実サイトやCrUXの観測値ではありません。

1.2, 1.4, 1.6, 1.8, 2.0, 2.4, 3.8, 4.0 秒

ここでは説明用にnearest-rank法を使い、切り上げ(0.75 × 件数)番目をp75と定義します。8件なら6番目の2.4秒です。平均は2.275秒、2.5秒以下は6件なので75%です。p75が良好でも残る2件は3.8秒と4.0秒です。

以下をp75-example.mjsとして保存し、Node.jsがある環境でnode p75-example.mjsを実行すると、掲載値を再計算できます。外部通信や追加パッケージはありません。

const lcpSeconds = [1.2, 1.4, 1.6, 1.8, 2.0, 2.4, 3.8, 4.0];
const sorted = [...lcpSeconds].sort((a, b) => a - b);
const rank = Math.ceil(0.75 * sorted.length);
const p75 = sorted[rank - 1];
const mean = sorted.reduce((sum, value) => sum + value, 0) / sorted.length;
const goodCount = sorted.filter(value => value <= 2.5).length;
console.log({ p75, mean: Number(mean.toFixed(3)), goodPercent: goodCount / sorted.length * 100 });
// { p75: 2.4, mean: 2.275, goodPercent: 75 }

この計算はp75を学ぶための有限データの例です。CrUXの集計処理の再実装や、8件で十分な判断ができるという提案ではありません。日別p75の平均を月間p75とすることもできません。元の観測値や分布を適切にまとめ直します。パーセンタイルを平均できない理由

4. 原因の仮説を指標ごとに作る

LCP：画像の容量だけを見る前に、いつ見つかったかを見る

まず、LCPとして測られた要素が画像か文字かを確認します。サーバー応答が遅いのか、画像の読み込み開始が遅いのか、転送に時間がかかるのか、届いても描画できないのかを分けます。原因が違えば修正も変わります。

特にLCPになる画像を遅延読み込み（lazy loading）にしないことが大切です。初期HTMLから見つけられるようにし、適切なサイズ・形式と読み込み優先度を検討します。画面外の画像に使う遅延読み込みを、主画像へ一律に適用しないでください。LCP画像の発見と優先度

キャッシュやCDNも、どこで時間がかかっているかに合わせて選びます。ログイン状態や個別の内容を誤って共有しない条件を確認し、表示と機能を再検証します。詳しくはTTFB改善と画像最適化へ進めます。

INP：遅い操作と、その時点の処理を結び付ける

メニューを開く、絞り込む、入力する、送信するなど、実際に重要な操作を再現します。遅い操作が分かったら、入力前の長い処理、操作を受けた処理、描画のどこに時間を使ったかを調べます。INPの遅延の内訳

不要なJavaScriptを減らす、長い処理を分割する、重い計算を適切に別処理へ移す、DOMの更新範囲を減らす、といった候補を原因に合わせて試します。処理を後回しにした結果、利用者の最初の操作と競合することもあるため、起動時だけで終えません。JavaScript・CSSの最適化が次の学習先です。

CLS：最初の読み込み後も確認する

CLSはページの生涯に起きた予期しない配置ずれについて、短いまとまりのうち最大の累積スコアを見る指標です。すべてのずれを単純に足した値ではありません。CLSの定義

画像や埋め込み、広告のための領域を確保し、後から出る案内やフォント切り替えで本文が動かないか確認します。読み込み直後の静止画だけでは、遅れて現れる内容や操作後のずれは分かりません。大きな画面だけでなく、小さな画面で折り返した場合も点検します。

5. 主要ページ一つで行う最小の検証

最初から全URLを同じ深さで調べる必要はありません。問い合わせ、商品比較、購入などの重要な用事から選び、次の条件を記録します。

表が収まらない場合は、横にスクロールできます

1. 利用できる実利用データを保存し、対象期間と集計範囲を確認する。なければ「不足」と記す。
2. 条件を固定して読み込みを複数回測り、値のばらつきも残す。
3. メニュー、フォームの入力とエラー表示など、必要な操作を繰り返し、反応と完了を確かめる。
4. 一つの原因仮説に対応する変更を行い、同じ条件と操作で測り直す。
5. 小画面、キーボード、主要フォームなどの機能も確認し、問題があれば戻せる状態にする。

この手順は読者の検証計画です。本記事の改稿では、公式本文の確認と上記の算数・コード検証を行い、実ブラウザでの速度測定や対象サイトの性能判定は実施していません。

6. 公開後の監視と、止める条件を決める

公開後は実利用の変化を追います。PSIの28日間の値には変更前のデータも含まれるため、直後に差が見えないことだけで失敗とは決めません。変更日、対象ページ、利用者構成、外部タグの変更を記録し、必要なら自社RUMでより細かな範囲を調べます。

監視の通知は、LCP・INP・CLSが設定した悪化基準を超えた場合など、指標の向きを正しく定めます。件数不足、収集停止、外部サービス障害も別に検知し、通知を受ける人と確認期限を決めます。パフォーマンス監視

公開を止める、または戻す条件には、主要フォームの失敗、重要な内容の欠落、権限やキャッシュの誤りも含めます。点数改善のために必要な機能を失うと、利用者の用事は達成できません。

7. SEOと事業成果は別に確かめる

GoogleはCore Web Vitalsをランキングに使うと説明していますが、良い値なら上位表示されるとは保証していません。スコアを何点上げれば順位や売上がいくら変わる、という換算はできません。Googleのページ体験に関するFAQ

改善後は、目的の操作の成功、問い合わせの受理、エラーや離脱の変化などを合わせて見ます。広告や季節性、流入構成が変われば、前後差だけで速度改善の効果は確定できません。GA4の基本で計測の定義をそろえ、検索面はテクニカルSEOで確認します。

症状に合わせて読み進める

表が収まらない場合は、横にスクロールできます

技術用語がまだ難しい場合は、プログラミングの基礎とサーバーの基礎から補えます。改善対象の切り分けをご希望の場合は、First byteへのご相談で、困っているページと操作をお知らせください。