「ページ速度を改善したいけれど、どの数字を見て、何から手をつければいいのかわからない」と迷っていませんか。結論から言えば、ページ速度の改善は「Search Consoleで実際の利用者のデータを見て『不良』のページを絞り、PageSpeed Insightsで原因を特定し、影響の大きい対策から1つずつ試して前後を比べる」のが基本です。速度が大事な理由、Core Web Vitalsの3つの指標と基準値、測り方、指標別の改善策、進める順番、WordPressでの注意、案件で価値を出す伝え方まで、このページで整理しました。
【結論】ページ速度は何を見て、どう改善すればいい？
ページ速度の改善とは、ページの読み込みの速さ、操作への反応の速さ、表示の安定性を高め、訪問者が待たずに快適に使える状態にすることです。Googleは、これらをCore Web Vitals（LCP、INP、CLS）という3つの指標で測っています。改善は次の3つを押さえて進めます。
- 実際の利用者のデータで絞るSearch Consoleの「ウェブに関する主な指標」で、「不良」や「改善が必要」と判定されたページのグループを確認する
- 原因を特定して対策するPageSpeed Insightsで遅い原因を調べ、画像、サーバー、JavaScript、レイアウトのずれなど、指標に合った対策をとる
- 1つずつ試して前後を比べるまとめて変えず、1つの対策ごとに効果を確かめ、最後は実際の利用者のデータで判断する
ただし、速度は検索順位を決める多くの要素の1つで、内容の質に代わるものではありません。
ページ速度を改善できるスキルは、Web制作やフロントエンド、SEOの案件で役立ちます。このスキルを活かせる案件を探すなら、エージェントで比べる方法もあります。
ページ速度はなぜ大事？SEO・読者・成果への影響
ページ速度は、読者が待たずに使えるかという体験に関わり、GoogleもCore Web Vitalsをランキングシステムで使っていると明言しています。一方で、指標がよいだけで上位に表示されるわけではありません。
| ランキングへの使われ方 | Googleは「Google のランキング システムでは Core Web Vitals が使用されます」としている |
|---|---|
| 上位表示の保証ではない | レポートでよい結果が出ても、検索結果で上位に表示されることが保証されるわけではないとしている |
| 関連性が優先される | ページエクスペリエンスが平均を下回るコンテンツも含め、常に最も関連性の高いコンテンツが表示されるように設計されているとしている |
| 単一のシグナルではない | 全般的なページエクスペリエンスを示す、さまざまなシグナルが評価されるとしている |
SEOのためだけでなく、表示が遅い、ボタンを押しても反応しない、読んでいる途中で表示がずれるといった体験は、読者の離脱や問い合わせの減少にもつながりやすくなります。速度の改善は、内容の質を高めたうえで取り組む、体験の土台づくりと考えましょう。
Core Web Vitalsの3つの指標と基準値は？
Core Web Vitalsは、読み込みの速さを表すLCP、操作への反応を表すINP、表示の安定性を表すCLSの3つで、ページへの訪問の75パーセンタイルの値で「良好」「改善が必要」「不良」を判定します。
| 指標 | 測るもの | 良好 | 改善が必要 | 不良 |
|---|---|---|---|---|
| LCP（Largest Contentful Paint） | 画面の中でいちばん大きな画像や文章のかたまりが表示されるまでの時間 | 2.5秒以下 | 2.5秒より長く4.0秒以下 | 4.0秒より長い |
| INP（Interaction to Next Paint） | クリックやタップなどの操作から、画面が次に描き変わるまでの時間 | 200ミリ秒以下 | 200ミリ秒より長く500ミリ秒以下 | 500ミリ秒より長い |
| CLS（Cumulative Layout Shift） | 読み込み中などに、表示が予期せずずれる量 | 0.1以下 | 0.1より大きく0.25以下 | 0.25より大きい |
- 操作への反応の指標は、以前のFIDから2024年3月にINPへ置き換わった。古い記事でFIDと書かれていても、今はINPで判断する
- 判定は、スマートフォンとパソコンで分けて行われる
- サーバーの応答時間（TTFB）はCore Web Vitalsではないが、LCPの前提になるため、web.devは0.8秒未満をおおまかな目安としている
ページ速度はどう測る？ツールとデータの違い
ページ速度は、実際の利用者から集めた「フィールドデータ」と、決まった条件で試しに測る「ラボデータ」の2種類で確認し、評価の判断はフィールドデータ、原因の調査と改善の確認はラボデータで行います。
| ツール | わかること | 使う場面 |
|---|---|---|
| Search Console（ウェブに関する主な指標） | サイト全体のURLを、似たページのグループごとに「良好」「改善が必要」「不良」で表示する | どのページから直すかを決めるとき |
| PageSpeed Insights | 1つのURLのフィールドデータとラボデータ、改善の提案を表示する | 遅い原因を調べるとき |
| Lighthouse、Chromeのデベロッパーツール | 手元の環境でラボデータを測り、読み込みの流れを細かく調べる | 開発中に改善の効果を確かめるとき |
| 比べる点 | フィールドデータ | ラボデータ |
|---|---|---|
| データのもと | 実際の利用者の体験（Chromeの利用状況のデータなど） | 決まった端末と回線の条件で試しに測った結果 |
| 向いている用途 | 評価の判断、改善後の最終的な確認 | 原因の調査、改善の効果をすぐに試すこと |
| 注意点 | アクセスが少ないページは表示されない。改善の反映に時間がかかる | 実際の利用者の体験と一致するとは限らない |
PageSpeed Insightsの0〜100の点数はラボデータにもとづく目安で、Core Web Vitalsの判定そのものではありません。点数だけを追わず、フィールドデータの3つの指標を見て判断しましょう。
何をすれば速くなる？指標別の改善策
改善策は、LCPなら画像とサーバーの応答、INPならJavaScriptの処理、CLSなら画像や広告の表示領域の確保と、悪い指標に合わせて選びます。
| 指標 | よくある原因 | 主な対策 |
|---|---|---|
| LCP | 大きな画像、サーバーの応答の遅さ、表示を止めるCSSやJavaScript | 画像をWebPやAVIFにして適切な大きさで配信する、いちばん大きな画像は遅延読み込みにせず優先して読み込む（fetchpriority）、キャッシュやCDNでサーバーの応答を速くする |
| INP | 重いJavaScript、外部のタグの多さ、一度に大量の処理 | 使っていないスクリプトやタグを減らす、長い処理を分ける、操作の直後に必要な処理だけを先に行う |
| CLS | 大きさの指定がない画像、あとから差し込まれる広告や埋め込み、Webフォントの切り替え | 画像や動画に幅と高さを指定する、広告や埋め込みの表示領域をあらかじめ確保する、フォントの表示の仕方を調整する |
LCPは、「サーバーの応答（TTFB）」「読み込みが始まるまでの遅れ」「読み込みにかかる時間」「表示されるまでの遅れ」の4つの区間に分けて考えると、どこが遅いのかを特定しやすくなります。web.devは、LCPの画像を遅延読み込みにすると、読み込みが不要に遅れてLCPが悪化するとしています。
あわせて読みたい（計測とサイト改善）
どの順番で進める？改善の5ステップ
改善は「現状を測る、直すページを決める、原因を調べる、1つずつ直して試す、実際の利用者のデータで確かめる」の5ステップで進め、アクセスが多く「不良」のページから手をつけます。
現状を測る
Search Consoleで、スマートフォンとパソコンそれぞれの「不良」「改善が必要」のURLのグループと、どの指標が原因かを確認します。
直すページを決める
アクセスが多いページや、問い合わせや購入につながるページのうち、「不良」の判定が出ているものを優先します。
原因を調べる
PageSpeed Insightsやデベロッパーツールで、LCPの対象になっている要素や、重いスクリプト、表示のずれの原因を特定します。
1つずつ直して試す
まとめて変えず、1つの対策ごとにラボデータで効果を確かめます。本番の前に検証用の環境で試し、変更前のバックアップを取っておきます。
実際の利用者のデータで確かめる
Search Consoleのフィールドデータは過去28日間の集計のため、反映には4週間ほどかかります。修正後に「修正を検証」を始めると、28日間のモニタリングで判定の変化が確かめられます。
すでに「良好」の指標の数値をさらに少し縮める作業は、手間の割に効果が小さくなりがちです。「不良」を「良好」に近づける改善を優先すると、限られた予算の中で成果を出しやすくなります。
WordPressのサイトでは何に気をつける？
WordPressでは、画像の最適化やキャッシュのプラグインで手軽に改善できる一方、プラグインの入れすぎや組み合わせの相性で、かえって遅くなることがあります。
- 画像はアップロードの前に適切な大きさにし、WebPなど軽い形式で配信している
- キャッシュの仕組みを、サーバーの機能かプラグインのどちらか1つにまとめている
- 使っていないプラグインや、同じ機能のプラグインの重複を減らしている
- テーマの機能で読み込まれるスクリプトやWebフォントを見直している
- 広告や埋め込み、計測のタグが増えすぎていないかを確かめている
- 設定を変える前にバックアップを取り、変更の前後で計測している
案件でどう価値を出す？提案と報告の仕方
速度改善の案件では、技術の言葉ではなくクライアントの成果に結び付けて提案し、改善の前後をフィールドデータとビジネスの数字の両方で報告すると、価値が伝わりやすくなります。
| 技術の言葉だけの説明 | クライアントに伝わる説明 |
|---|---|
| LCPが4.2秒で「不良」です | スマートフォンで商品ページの主な画像が出るまでに4秒以上かかっており、表示を待たずに離れる人が出ている可能性があります |
| CLSを0.3から0.05に改善しました | 読み込み中に申し込みボタンの位置がずれて押し間違える状態を解消しました |
| PageSpeed Insightsの点数が40点から90点になりました | 実際の利用者のデータで3つの指標が「良好」になり、あわせて問い合わせページへの到達の変化を確認しています |
- 見積もりでは、調査、改善の実装、効果の確認の範囲を分けて示す
- サーバーの変更や広告のタグなど、自分の権限で変えられない部分は、担当者と役割を決めておく
- 速度の改善で成果の数字が必ず上がるとは約束しない。前後の変化を測って報告する
あわせて読みたい（成果につなげる）
よくある質問（FAQ）
ページ速度はCore Web Vitals（LCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下）で測り、訪問の75パーセンタイルで判定される。Googleはランキングに使うとしつつ、上位表示の保証ではなく関連性が優先されるとしている
評価の判断はフィールドデータ、原因の調査はラボデータで行う。LCPは画像とサーバー、INPはJavaScript、CLSは表示領域の確保と、悪い指標に合った対策を選ぶ
アクセスが多く「不良」のページから1つずつ直して前後を比べる。案件では技術の数字をクライアントの成果の言葉に置き換えて提案し、報告する
ページ速度を改善できるスキルは、Web制作やSEOと組み合わせることで強みになります。この強みを活かせる案件に出会いたい方は、Web・フロントエンドの案件を扱うエージェントを複数比べて、自分に合う案件を探してみてください。
