ブログ運営 / 実測と改善の記録
画像を軽くする前に、
「表示までの待ち」を調べました。
WordPressの表示が遅いとき、どこから直せばよいのでしょうか。当ブログのトップページをPageSpeed Insightsで調べると、先頭画像の読み込みを改善した後も、モバイルのLCPは10.4秒でした。そこで、画面の描画を待たせるCSSと画像の読み込み方式を見直しました。
2026年10月5日 11:02
2026年10月5日 13:44
これは同日に各1回実施したモバイルの実験室計測です。すべての訪問者の表示時間や、個々の変更の効果を証明する数値ではありません。
実測結果：LCPは10.4秒から3.9秒へ
対象は当ブログのトップページです。計測条件はどちらもMoto G Powerのエミュレーション、低速4G、最初のページ読み込み、Lighthouse 13.5.0でした。主な結果を並べると、今回の計測では表示が始まるまでの時間と主要な内容が表示されるまでの時間が短くなっています。
| 指標 | 11:02の計測 | 13:44の計測 |
|---|---|---|
| LCP：主要な内容の表示 | 10.4秒 | 3.9秒 |
| FCP：最初の内容の表示 | 6.0秒 | 3.0秒 |
| TBT：長い処理によるブロック時間 | 200ミリ秒 | 120ミリ秒 |
| CLS：レイアウトのずれ | 0 | 0 |
| パフォーマンス評価 | 55 | 79 |
| SEOの基本点検 | 85 | 100 |
実際のレポートは追加改善前の計測と追加改善後の計測で確認できます。ネットワークや広告配信などの影響で値は変わるため、この2回だけで長期的な効果や収益増加を判断していません。
「良好」になった、とまでは言えません。
GoogleのLCPの良好基準は2.5秒以下で、実際の訪問を評価するときは75パーセンタイルを使います。今回の3.9秒には改善の余地があり、PageSpeed Insightsには実際のユーザーの集計データもありませんでした。詳しい基準はGoogleのLCP改善ガイドをご覧ください。
TBTは実験室の指標です。操作への反応を評価する実際のユーザーのINPとは別なので、120ミリ秒になったことだけで操作性の問題がすべて解消したとは判断できません。定義はTBTの公式解説で確認できます。
分かったこと：画像の容量だけでは説明できない
LCPは、その画面で大きな画像やテキストなどの主要な内容が表示されるまでの時間です。今回、レポートが示した対象はトップのロゴ画像でした。最初に並ぶ記事のサムネイルだと思い込んでいたら、優先して読み込む画像を間違えるところです。
追加改善前の時点で、ロゴ画像には先読みと高優先度の指定があり、遅延読み込みも外れていました。それでもLCPは10.4秒です。レポートを詳しく見ると、テーマのCSSやJavaScriptなど、最初の描画を待たせるリクエストが検出されました。
ここから得た改善の方針は、「どの画像か」と「その画像を表示するまでに何を待つか」を一緒に確認することです。画像をダウンロードできても、必要なCSSの読み込みや描画の準備が終わらなければ表示は進みません。圧縮だけを続ける前に、レポートの「LCPの内訳」と「レンダリングをブロックしているリクエスト」を見ると、次の作業を絞りやすくなります。
今回変更したことと、確認したこと
1. テーマのCSSを待つリクエストを減らす
SWELL標準のCSSインライン設定を有効にしました。小さい補助CSSもページ内へ出力するよう修正し、その外部ファイルを待つ読み込みを1件減らしています。保存した設定だけでなく、公開HTMLから外部CSSが減り、補助CSSが実際に出力されていることを確認しました。
CSSのインライン化はHTMLの量を増やします。別のテーマや構成でも同じ設定が最適とは限りません。テーマが提供する設定から試し、表示と測定結果を確認するのが取り組みやすい方法です。SWELLの機能は公式の機能紹介に掲載されています。
2. 最初の画像と、その下の画像を読み分ける
LCP対象のロゴは先読みと高優先度を維持しました。ほかの画像は、JavaScriptに依存する遅延読み込みからブラウザー標準の方式へ切り替えています。先頭だけでなく、記事カードとRSS画像が表示されることも点検しました。
自分のブログで試すときも、すべての画像を高優先度にせず、まずLCP対象の画像を特定してください。先頭画像まで遅延読み込みにすると、読者が最初に見たい内容を待たせる原因になります。
3. 公開ページを更新してから測り直す
設定変更後にページキャッシュを更新し、公開HTML、表示、PageSpeed Insightsの順に確認しました。管理画面で「保存できた」だけでは、読者が見るキャッシュや実際の出力まで変わったとは限りません。
途中の点検では、補助CSSの登録が不足し、CSSが出力されていない問題も見つかりました。登録処理を直した後、実際の出力とレイアウトを確認しています。速さと一緒に、見た目が維持されているかを確認する必要があります。
速度以外では、説明文とRSSリンクに不足がありました
トップページには、内容を要約するmeta descriptionがありませんでした。記事一覧が中心のページなので、どんな情報を扱うブログなのか分かる説明文をSEO設定へ追加しました。固定ページ側の設定だけでは出力されず、フロントページ専用の設定も必要だった点が、今回の確認で分かりました。
追加した説明文がそのまま検索結果に採用されるとは限りません。Googleは検索語に応じて本文などからも説明を作ります。設定方法と使われ方はGoogleの検索結果の説明文に関するガイドを参照してください。SEO点検の100は基本項目の結果であり、検索順位やアクセス増加の保証ではありません。
もう1つは、RSSフィードへのリンク画像に代替テキストが欠けていたことです。リンクの用途が分かる「RSSフィード」を補い、以後も同じ条件の欠落だけを自動で修復する処理を追加しました。既存の説明文や、装飾画像に設定した空の代替テキストはそのまま保ちます。
改善後にも、フォントや外部処理、広告によって変わる記事一覧のリスト構造などの点検項目は残っています。広告配信や同意管理のコードをまとめて遅らせると、その機能が変わる可能性があるため、挿入位置と依存関係を確認してから次の改善を進めます。
自分のブログで試すなら、この順番で点検する
- 変更前のレポートを残す。対象URL、モバイルかPCか、測定時刻と条件を控えます。条件の分からない古い画像とは、厳密な改善率を比較しません。
- LCPの対象要素を確認する。ロゴ、記事画像、見出しのどれかを確かめ、先頭画像の遅延読み込みを点検します。
- 描画待ちの候補を調べる。CSS、フォント、外部スクリプトのうち、どれが検出されているかを見ます。変更前の設定も記録します。
- キャッシュと公開画面を確認する。PCとスマートフォンで見出し、画像、メニュー、リンク、広告表示を確かめます。崩れた場合は元の設定へ戻します。
- 同じ条件で測り直す。単発のスコアを結論にせず、日を変えた計測と実際のユーザーのデータも見ていきます。
改善を自動化するときも、変更、保存、公開表示、効果の確認を分けて記録することが大切です。処理が終了したことだけで記事の品質や公開成功を判定せず、欠測を「正常」に置き換えない仕組みにすると、次に何を調べるべきか分かりやすくなります。
今回の分析で得た実務上の手掛かりは、画像の先読みを入れても遅いなら、画像以外の表示待ちを調べることでした。まずは1ページで原因を絞り、公開画面まで確かめてからほかのページへ広げていきます。
