WordPressサイトを開いたとき、ヘッダーや文字はすぐ出るのに、ファーストビューの画像だけがなかなか表示されないことがあります。
こんなとき、画像を圧縮すれば直ると思われがちです。でも実際には、画像が軽くても改善しないケースがあります。サーバーの応答、画像を見つけるタイミング、画像の読み込み、画面へ描画する処理。それぞれ原因が違うからです。
この記事では、PageSpeed Insightsを使って「最初の表示が遅い」原因を4つに分けて確認する方法を解説します。
先に結論
ファーストビューが遅いときは、次の4つを順番に見ます。
- サーバーがHTMLを返すまでの時間
- メイン画像の読み込みが始まるまでの時間
- 画像ファイルを取得する時間
- 画像を取得したあと、画面に出るまでの時間
ここを見ずにキャッシュや画像圧縮だけを追加すると、変化がないまま設定だけが増えることがあります。
LCPって何？
PageSpeed Insightsでは、最初に表示される大きな画像や見出しが出るまでの時間をLCPとして確認できます。
LCPは「Largest Contentful Paint」の略です。難しく見えるけど、考え方は単純です。
画面を開いた人が、ページのメインになる大きな要素を見られるまでに何秒かかったか
WordPressサイトでは、次のような要素がLCPになることが多いです。
- ファーストビューのメイン画像
- 背景画像を使ったヒーローエリア
- スライダーの最初の画像
- 大きな見出しテキスト
Googleは良好なLCPの目安を2.5秒以下としています。ただし、数字を下げることだけが目的ではありません。最初に、何がLCP要素になっているかを確認するのが大切です。
参考: Optimize Largest Contentful Paint – web.dev
PageSpeed Insightsで最初に見る場所
PageSpeed Insightsで対象ページを測定したら、「Largest Contentful Paint element」または「LCPの内訳」を開きます。
最初に確認したいのは、改善案の数ではなく、どの画像や要素がLCPとして検出されているかです。
たとえば、ヒーロー画像がLCPなら、その画像がいつ見つかり、いつ読み込まれ、いつ画面に出たのかを見ます。本文の画像を軽くしても、そのヒーロー画像に関係していなければLCPは動きません。
LCPは4つに分けて見られる
LCPの内訳は、次の4項目です。
| 確認項目 | 何を表すか | 長いときに疑うこと |
|---|---|---|
| Time to First Byte（TTFB） | HTMLが返り始めるまで | サーバー、キャッシュ、リダイレクト、WordPress処理 |
| リソース読み込みの遅延 | メイン画像の読み込み開始まで | 背景画像、JavaScript、lazy-load、優先度 |
| リソースの読み込み時間 | 画像を取得する時間 | 画像容量、形式、配信元、通信環境 |
| 要素のレンダリング遅延 | 画像取得後に画面へ出るまで | CSS、JavaScript、アニメーション |
4つを足した時間がLCPです。ひとつだけを改善しても、別の場所で待ち時間が残れば、最初の表示はあまり速くなりません。
1. サーバーがHTMLを返すまでに時間がかかる
TTFBが長い場合は、画像より前の段階で待ち時間が発生しています。
WordPressでは、まずページキャッシュが使えているかを確認します。
- キャッシュプラグインやサーバーキャッシュが有効か
- ログイン状態だけで測定していないか
- 不要なリダイレクトが増えていないか
- PHP処理やデータベース問い合わせが重くなっていないか
- 外部サービスへの通信を初期表示で待っていないか
TTFBが長いと、その後の画像取得や描画もすべて後ろへずれます。まずHTMLを早く返せる状態を作るのが先です。
2. メイン画像の読み込み開始が遅い
「リソース読み込みの遅延」が長い場合、メイン画像の存在にブラウザが気づくのが遅れています。
よくあるのは、ファーストビュー画像をCSSの背景画像にしているケースです。画像URLがHTMLに直接書かれていないため、CSSの取得と解析が終わるまでブラウザが画像を見つけられないことがあります。
ほかにも、次のような状態で遅れやすくなります。
- メイン画像に
loading="lazy"が付いている - JavaScriptで画像をあとから追加している
- スライダー初期化後に最初の画像を表示している
- 背景画像を外部CSSで指定している
背景画像がLCPになる場合は、<link rel="preload" as="image">で先読みを指定する方法があります。
ただし、preloadを追加すれば必ず改善するわけではありません。原因が「画像を見つけるまでの遅れ」ではなく、「描画の遅れ」にある場合、数値がほとんど変わらないこともあります。
3. 画像ファイルの取得に時間がかかる
「リソースの読み込み時間」が長い場合は、画像自体の取得に時間がかかっています。
まず確認するのは、画像の表示サイズに対してファイルが大きすぎないかです。
- 大きすぎる元画像をそのまま使っていないか
- WebPやAVIFなど、用途に合う形式になっているか
- モバイルでもPC向けの大きな画像を配信していないか
- CDNやキャッシュで配信距離を短くできるか
- 同時に大量の画像や動画を読み込んでいないか
ただし、画像容量を下げても、レンダリング遅延が長ければ最初の表示は改善しないことがあります。画像の軽量化だけで終わらせないのが大事です。
4. 画像を取得したのに、画面へ出るのが遅い
画像は取得できているのに、画面に出るまでが遅い。こういうときは「要素のレンダリング遅延」を確認します。
主な原因は、CSSやJavaScriptによる待ち時間です。
- 大きなCSSファイルが初期描画を止めている
- 同期JavaScriptがページ表示を止めている
- GSAPなどのアニメーション初期化後に要素を表示している
- スライダーやフェード演出で画像を隠している
- JavaScriptの処理が重く、ブラウザのメインスレッドが空かない
この場合は、画像の圧縮やキャッシュだけでは解決しません。初期表示に不要なCSSやJavaScriptを後回しにする、メイン画像をJavaScript待ちにしない、アニメーションで最初から非表示にしない、といった見直しが必要です。
キャッシュだけでは直らないケースもある
筆者のWordPressテストページでも、ページキャッシュを有効にしたことでTTFBの改善は確認できました。
一方で、LCP要素のレンダリング遅延は約1.76秒残り、Performanceは大きく変わりませんでした。
つまり、サーバー応答を改善しても、ヒーロー画像が描画されるまで待たされていれば、最初の表示の課題は残ります。
詳しい測定結果は、WordPress高速化プラグインを実測比較した記事にまとめています。
最初の表示を改善するときに、先にやらない方がいいこと
原因を確認せずに、次のような対応だけを先にするのはおすすめしません。
- メイン画像をlazy-loadする
fetchpriority="high"を多くの画像へ付ける- 最適化プラグインを複数入れる
- CSSやJavaScriptを強く遅延させて、表示崩れを確認しない
- 1回のPageSpeed Insights測定だけで判断する
改善策によっては、LCPが良くなってもCLSが悪化したり、スライダーやフォームが動かなくなったりします。変更後は数値だけでなく、スマホとPCの実表示を確認しておくべきです。
まとめ
WordPressの最初の表示が遅いときは、画像を軽くする前に、どこで時間がかかっているかを切り分けます。
- TTFBが長いなら、キャッシュやサーバー側を確認する
- 読み込み開始が遅いなら、メイン画像の発見方法と優先度を確認する
- 画像取得が遅いなら、容量・形式・配信を確認する
- 描画が遅いなら、CSS・JavaScript・アニメーションを確認する
LCPの内訳を見ると、「とりあえず画像圧縮」や「とりあえずキャッシュ」ではなく、直すべき場所を絞り込めます。
※本記事はGoogleの公式ドキュメントと筆者のテスト環境での測定をもとに作成しています。PageSpeed Insightsのラボデータは測定条件で変動するため、実際の訪問者データも確認できる場合はあわせて判断してください。