Webパフォーマンス最適化入門：高速で快適なユーザー体験を実現するための方法

「速度診断の点数が低い」と言われても、画像を圧縮するのか、サーバーを変えるのか、判断に迷うことがあります。最初に見分けたいのは、見えるまでが遅いのか、操作への反応が遅いのか、読んでいる場所が動くのかです。

30秒で要点

• 現行のCore Web VitalsはLCP・INP・CLS。利用者が困る場面を3種類に分けて見る。
• 実際の利用データで問題のあるページを選び、条件を固定した測定で原因を調べる。
• 全画像の遅延読み込みや、診断の点数だけを目標にした変更は、目的と逆の結果になることがある。
• 一つのページ・一つの変更から始め、表示と機能の両方を確かめる。

まず「速さ」を3つの体験に分ける

Core Web Vitalsは、Googleが定めるWebページの主要な体験指標です。2026年10月7日に確認した公式資料では、次の3つを使います。旧資料に出てくるFIDは、2024年3月12日にINPへ置き換わりました。Web Vitalsの定義、INPへの移行告知

Web Vitals、PageSpeed Insights、LCP・INP・CLSの最適化、Google Searchのページ体験に関する公式資料8件を2026年10月7日に再読しました。3指標の定義・閾値、フィールド/ラボの区別、検索順位を保証しない留保に変更はありません。

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

msはミリ秒で、1,000msが1秒です。CLSには秒の単位がありません。区分はPageSpeed Insightsの公式表に合わせています。

75パーセンタイルは、計測値を小さい順に並べたときの75%の位置です。平均値でも、手元で一度開いたときの値でもありません。モバイルとデスクトップを分けて見ることで、PCでは快適でもスマートフォンでは重い、といった違いを残せます。

3指標だけで利用体験のすべてを説明できるわけでもありません。たとえば、検索ボタンがすぐ「処理中」に変わっても、結果を待つ時間が長ければ困ります。指標と併せて、読者や顧客が完了させたい操作を確かめます。

実利用データで問題を選び、ラボ測定で原因を探す

PageSpeed Insightsの画面には、性質の違う結果が並びます。点数が大きく表示されるため一つの試験に見えますが、分けて読む必要があります。

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

実利用データの集まりをCrUXと呼びます。対象URLの情報が足りないと、同じオリジン（同じプロトコル・ホスト・ポートのサイト）の集計に切り替わる場合があります。「このページ」と「サイト全体」のどちらかを記録してください。数字が出ない場合は、問題がない証拠にはなりません。PageSpeed Insightsの測定仕様

Lighthouseの通常のページ読み込み試験には利用者の操作がないため、INPそのものは出ません。代わりに、ブラウザの主要な処理を長くふさいだ時間を表すTBTが手がかりになります。操作の問題は、ブラウザの開発者ツールで実際にメニューを開く、検索する、といった操作も再現します。ラボの点数が上がったことと、実利用のINPが改善したことは別に記録します。Web Vitalsの測定ツール

最初の記録は5項目でよい

改善に着手する前に、URL、測定日時、端末区分、データの粒度、困る操作を1行ずつ残します。開発者に依頼する場合も、「スマホのサービスページで、メニューを開くと一拍待つ」と説明できれば調査を絞れます。

確認するページは、トップページだけに限定しません。問い合わせや購入に進むページ、閲覧の多い記事、共通テンプレートを使う代表ページから選びます。アクセス数が少ないページを無視するという意味ではなく、影響範囲を見積もるためです。

LCPが遅いときは、画像容量の前後も見る

LCPは、表示領域で最も大きな画像やテキストが描画されるまでの時間です。画像が対象なら、「サーバーから最初の応答を受ける」「画像を見つける」「転送する」「描画する」という区間で考えられます。LCPの分解方法

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

たとえば、先頭画像に一律でloading="lazy"を付けると、肝心の画像を後回しにすることがあります。「画像は全部遅延読み込みにする」というチェックリストが、逆効果を生む場面です。画面を開いたときに必要な画像と、下まで読んだときに必要な画像を分けます。

CDNは、利用者に近い拠点などからコンテンツを配信する仕組みです。配信やキャッシュの見直しが効く状況はありますが、画像の発見がJavaScript待ちなら、配信拠点を変えるだけではその待ち時間は消えません。容量削減も同様です。先に長い区間を見つけ、その区間に効く修正を選ぶのが出発点です。

画像側に原因がある場合は、画像最適化ガイドの寸法・形式・読み込み順を確認すると、実装まで進められます。

INPが悪いときは、遅い操作を一つ再現する

INPは、操作を受け付けるまでの待ち、操作の処理、次の画面を描くまでを含みます。ページを開いた最初だけでなく、利用中の操作も対象です。INPの定義

たとえば商品を絞り込むたびに、表示していない大量の商品まで並べ替えるとします。この場合、画像を軽くしても操作の計算量は変わりません。開発者ツールのPerformance記録で絞り込み操作を再現し、長く動き続ける処理がどこにあるかを調べます。

改善候補は、不要な処理を取り除く、長い処理を小さく分ける、画面に必要な変化を先に反映する、などです。Web Workerという別の実行場所に計算を移す方法もありますが、やり取りの設計が増えるため、最初から採用する必要はありません。INPの改善ガイド

広告・チャット・計測などの外部スクリプトも、調査対象から外さないでください。削除すればよいという話ではなく、目的、利用している機能、読み込むページを確認します。速度だけを見て計測や問い合わせ機能を壊すと、改善の評価自体ができなくなります。

CLSが悪いときは、後から入るものの場所を確保する

記事を読んでいる途中で画像が入り、押そうとしたリンクがずれる。これが配置の不安定さです。画像、広告、埋め込み、Webフォントなど、後から表示される要素を調べます。CLSのよくある原因

画像には元の縦横比に合うwidthとheightを指定します。画面幅への追従はCSSで行い、読み込み前にも場所を確保できるようにします。

<!-- 本文の途中、最初の表示領域より下に置く画像の例 -->
<img
  src="process-800.webp"
  width="800"
  height="500"
  loading="lazy"
  alt="受付、確認、回答の3段階に分けた問い合わせの流れ"
  style="max-width: 100%; height: auto;"
/>

広告や埋め込みも、後から内容が入る場所を用意します。一方で、余白を大きく取りすぎて本文が遠くなることもあります。スマートフォンでの見え方を確認し、予約した領域と実際の表示サイズを合わせます。

一つの変更を、同じ条件で比較する

最小の検証は「問題のある代表ページで、原因候補を一つだけ変える」ことです。以下は作業の例であり、成果を測定した事例ではありません。

1. 変更前を保存する。 スマートフォン条件でページを複数回測り、値のばらつきと画面を残す。
2. 仮説を書く。 例として「先頭画像の発見が遅いため、lazy指定を外す」と対象を絞る。
3. 変更後を同じ条件で測る。 URL、画面幅、回線・端末設定、キャッシュ条件を合わせる。
4. 目的の操作を試す。 メニュー、フォーム、画像、計測が動くかを確認する。
5. 公開日を記録して実利用を追う。 28日集計には変更前の利用も混ざることを踏まえて読む。

単発の最良値だけを選ぶと、回線の揺れを成果に見せてしまいます。測定回数を増やせば事業効果の因果まで証明できるわけでもありません。問い合わせ完了率を併せて見るなら、分子を「完了したセッション数」、分母を「対象ページを見たセッション数」などと決め、流入元や季節の違いも確認します。

改善を続ける基準を決める

公開のたびに、代表ページと重要な操作を同じ条件で確認すると、後から追加した画像や機能の影響に気づきやすくなります。自動測定を使う場合も、比較対象のURL、環境、許容する変化を先に決めます。「画像は何KB以下」といった予算は自社の制約として使い、すべてのサイトに通じる合格基準にしないことが大切です。

GoogleはCore Web Vitalsをランキングに使用すると説明していますが、良好な数値だけで検索上位になるとはしていません。内容の役立ち方、モバイル表示、操作のしやすさも含めた体験を見ます。Googleのページ体験に関する説明

この記事で扱ったのは、表示・操作・配置の問題を切り分けて改善する入口です。投資額まで判断するときは、Core Web Vitalsと事業インパクトの考え方も踏まえて、誰のどの不便を減らせるのかを確かめてください。最初の一歩は、最も低い点数を探すことより、利用者が困る一つの場面を記録することです。