はじめに
画像を軽くした。
Themeも設定した。
Pluginも必要なものだけ入れた。
では、実際のホームページは速いのでしょうか。
ここで大切なのは、
予想ではなく、実際に測ること
です。
この章では、PageSpeed Insightsなどを使い、
- 何が遅い？
- 利用者はどこで待っている？
- 操作しにくくない？
- 表示中にレイアウトが動かない？
を確認します。
画像のリサイズや圧縮は第27章で扱いました。
ここではサイト全体を見ます。
表示速度はなぜ重要？
ページがなかなか表示されないと、利用者は待つことになります。
さらに、
- ボタンを押しても反応しない
- 読もうとした文字が突然ずれる
- ヒーロー 画像が長く出てこない
などもユーザー体験へ影響します。
表示速度は、
「何秒で全部読み込み終わる？」
だけではありません。
見える・反応する・安定する
という体験全体を考えます。
PageSpeed Insightsで測る
GoogleのPageSpeed Insightsでは、URLを入力してパフォーマンスを確認できます。
結果には、実際の利用者データを利用したフィールドデータが表示される場合と、Lighthouseによるラボデータがあります。
サイトやURLによって十分なフィールドデータがない場合もあります。
一つのスコアだけを見て終わらないようにします。
モバイルを先に確認する
PCでは高速でも、モバイルでは条件が違います。
スマートフォンでは、
- ネットワーク
- 端末性能
- 画面サイズ
などが異なります。
PageSpeed Insightsでもモバイルとデスクトップを分けて確認できます。
小規模店舗サイトでも、実際のアクセス状況を見ながらモバイル Experienceを重視します。
Core Web Vitalsとは
Googleは、実際のユーザー体験を捉える主要指標としてCore Web Vitalsを定義しています。
2026年8月時点のCore Web Vitalsは、
- LCP
- INP
- CLS
の3つです。
それぞれ違う問題を見ています。
LCPとは
LCPは、
Largest Contentful Paint
です。
画面内の主要な大きいコンテンツが表示されるまでの体感速度を表します。
Googleが「Good」とする目安は、
2.5秒以内です。
75th Percentileで評価されます。
LCPでよく関係するもの
LCP Elementがヒーロー 画像なら、
- 画像が大きすぎる
- サーバー応答
- CSS
- フォント
- リソース 読み込み
などが関係する可能性があります。
ここで画像が原因候補なら、第27章の画像最適化へ戻ります。
「LCPが悪い = 画像圧縮だけ」
とは決めません。
INPとは
INPは、
Interaction to Next Paint
です。
クリックやTap、キーボード操作などに対して、ページがどれくらいレスポンシブに反応するかを見る指標です。
Googleが「Good」とする目安は、
200ms以下です。
ボタンを押してもしばらく反応しないサイトでは、利用者は「壊れている？」と感じることがあります。
INPで考えるもの
INPには、
- 負荷の大きいJavaScript
- メイン Threadの長時間処理
- Plugin
- 外部 スクリプト
などが影響することがあります。
初心者がJavaScriptの中身をすぐ修正する必要はありません。
まず、
操作反応の問題がある
と分かるだけでも前進です。
CLSとは
CLSは、
Cumulative レイアウト Shift
です。
表示中にコンテンツが予期せず動くVisual Stabilityを見ます。
Googleが「Good」とする目安は、
0.1以下です。
たとえば、
ボタンを押そうとした瞬間に画像が読み込まれ、ボタンが下へずれる。
こうした体験がCLSに関係します。
Core Web VitalsのGood目安
2026年8月時点では、
| 指標 | GOOD |
| LPC | 2.5秒以下 |
| INP | 200ms以下 |
| CLS | 0.1以下 |
です。
ただし、数字を暗記することより、
- LCP = 見える速さ
- INP = 反応
- CLS = 安定
と意味を理解することを優先します。
スコア 100を取ることが目的ではない
PageSpeed Insightsにはパフォーマンス スコアがあります。
100を見ると気持ちは良いですが、
100点を取ることがビジネス目的ではありません。
たとえば、高品質な施術写真に価値がある美容室で、スコアを上げるために写真を極端に劣化させれば本末転倒です。
考えるのは、
速度
+
コンテンツ
+
デザイン
+
機能のバランスです。
遅い原因を探す`
遅い原因は一つではない
サイトが遅い原因には、
- 画像
- Theme
- Plugin
- JavaScript
- CSS
- Webフォント
- 外部 スクリプト
- キャッシュ
- サーバー応答
- ネットワーク
などがあります。
画像だけを疑わないようにします。
ヒーロー 画像を確認する
トップページの大きなヒーロー 画像はLCP候補になりやすい要素です。
確認したいのは、
- 必要以上に大きくない？
- 形式は適切？
- 遅延読み込みとの関係は？
- 画像が表示されるまで他の処理で待っていない？
などです。
画像ファイルそのものの最適化は第27章で扱います。
Pluginを増やした後に遅くなった？
Pluginを追加した後に速度が落ちた場合、Pluginが追加するCSS、JavaScript、外部通信などが関係する可能性があります。
だからといって、
「Pluginは少ないほど正義」
という単純な話ではありません。
必要な機能か。
負荷に見合う価値があるか。
を見ます。
Webフォントも確認する
Webフォントはデザインの印象を大きく変えますが、読み込みリソースにもなります。
フォント数やWeightを増やしすぎるとデータも増えます。
デザイン上必要なフォントを選びます。
外部 スクリプトを増やしすぎない
アクセス解析。
広告。
Chat。
SNS ウィジェット。
予約ツール。
外部サービスを追加するほど、スクリプトやネットワーク Requestが増えることがあります。
機能が必要なら使います。
ただし、
「入れられるから全部入れる」
ではなく、目的に必要か確認します。
キャッシュとサーバー側の機能を確認する
キャッシュとは
キャッシュは、一度作ったデータやリソースを再利用し、毎回同じ処理を繰り返さないようにする仕組みです。
ブラウザー、Plugin、サーバー、CDNなど複数の層にキャッシュがある場合があります。
キャッシュはパフォーマンス改善に役立ちますが、仕組みが重複すると設定が複雑になる場合があります。
初心者はまず、自分のサーバーやPluginでどのキャッシュが有効なのか把握します。
Xserver側の機能も確認する
ホスティング側にも、表示速度に関係する機能があります。
ただし、WordPress PluginとXserver側で同じような最適化を重ねると、問題の切り分けが難しくなる場合があります。
サーバー側で何が有効なのか確認してからPluginを追加します。
一つずつ改善して記録する
一度に全部最適化しない
パフォーマンス改善でも、
画像変更
キャッシュ変更
Plugin削除
フォント変更
Theme設定変更を一度に行うと、何が効いたか分かりません。
基本は、
測る
↓
原因候補を決める
↓
一つのまとまりを変更
↓
もう一度測るです。
フィールドデータとラボデータが違うこともある
PageSpeed Insightsでは、実利用者を基にしたフィールドデータと、一定環境で計測するラボデータが異なることがあります。
それは必ずしも異常ではありません。
ラボデータはトラブルシューティングに便利。
フィールドデータは実際のユーザー体験を知る材料。
というように役割が違います。
数字が少し変わっただけで慌てない
パフォーマンス測定結果は毎回完全に同じになるとは限りません。
ネットワークやサーバー状態などで変動します。
1回の数字だけではなく、傾向を見ます。
改善前後を記録する
たとえば、
変更前
LCP 3.4秒
変更
ヒーロー 画像を最適化
変更後
LCP 2.6秒のように記録します。
ただし、他の条件も変わるため、「この変更だけが原因」と断定しすぎないようにします。
速度は公開後も見る
サイトは成長します。
画像が増える。
Pluginが増える。
新しいフォントを使う。
外部ツールを追加する。
そのため、一度高速化して終わりではありません。
大きな変更後や定期見直しで確認します。
第46章では、速度を含めたサイト全体の改善循環を扱います。
今回のポイント
- 表示速度は読み込みだけでなく反応性と安定性も見る
- PageSpeed Insightsで実際のURLを測る
- モバイルとデスクトップを分けて確認する
- Core Web VitalsはLCP / INP / CLS
- Good目安はLCP 2.5秒以内、INP 200ms以下、CLS 0.1以下
- 画像が原因なら第27章の画像最適化へ戻る
- 速度の原因はTheme・Plugin・スクリプト・フォント・サーバーなど複数ある
- パフォーマンス スコア 100を目的にしない
- 一度に全部変更せず、測定 → 変更 → 再測定で進める
- 公開後も大きな変更時や定期見直しで確認する
今回の視点
表示速度改善は、
「サイトを軽くするCompetition」
ではありません。
利用者が、
待たされない。
押したら反応する。
読み始めた場所が勝手に動かない。
そのための改善です。
点数ではなく、利用者の待ち時間と操作体験を見る。
これがパフォーマンス改善の中心です。
Part 6｜検索されるホームページを作る