最初の表示が遅い
記事の大きな画像や見出しがなかなか出ない。LCPと、HTML・画像の待ち時間から調べます。
計測と区間の確認へWordPressの運営 / 表示速度の切り分け
WORDPRESS / PERFORMANCE
遅い原因を、
待っている場所から
見つける。
画像を軽くしたのに変わらない。プラグインを増やす前に、「何が、どこで遅いか」を一つずつ確認しましょう。同じページ・同じ条件で測り、必要な変更だけを試します。
今日のゴールは、点数より「次の一手」。
- 遅いページと症状を一つに絞る。
- 同じ条件で3回測り、遅い区間を見る。
- 候補を一つ試し、表示・操作と数値を確認する。
困っていないページを100点にするために、設定を次々と変更する必要はありません。本番でまとめてプラグインを停止したり、DBを削除したりしないでください。
01 / LOCATE THE WAIT
「遅い」を、3つの症状へ分ける。
押してから反応が遅い
メニュー・ボタン・入力が引っかかる。INPは操作の応答性。LCP改善と同じ対策とは限りません。
操作を切り分ける読んでいる位置が動く
画像や広告が後から広がり、押す位置がずれる。CLSと、画像の寸法・表示領域を確認します。
表示ずれを調べるログイン中の管理画面だけ遅い場合は、公開URLのPSI点数で原因を断定できません。公開側と管理側、特定の記事と全記事、Wi-Fiと別回線で違うかを記録します。500エラーや真っ白な画面は、表示不具合の切り分けへ。
実測値と目安を混ぜない。
Core Web Vitalsの良好目安はLCP2.5秒以下・INP200ms以下・CLS0.1以下。実ユーザー評価は75パーセンタイルで判断します。1回のラボ計測で、この評価に合格したとは言えません。Google：Web Vitalsの定義
02 / MEASURE BEFORE CHANGING
PageSpeed Insightsで、二種類の結果を読む。
以下はGoogle公式資料に基づく操作案内です。この記事では本番PSIの測定や会員画面の操作を行っていません。次の独自実測は、別のローカル環境です。
- 対象URLを決める。公開記事をログアウト状態で開き、最終的なHTTPSのURLを確認。本人だけが見られる管理画面・下書き・認証トークン付きURLは外部計測へ送らない。
- PageSpeed Insightsへ公開URLを入力して分析。モバイルとデスクトップを区別。URL・日時・端末区分・変更前の状態を控えます。
- 実ユーザー欄の対象を確認。データがあれば、当該URLかオリジン全体か、収集期間も読みます。データなしは閲覧ゼロや高速の証明ではありません。
- ラボ欄のLCPと対象要素を見る。点数だけでなく「どの画像・見出しがLCPか」と改善候補を確認。同じ端末区分で3回測り、中央値と最小〜最大を記録します。
実ユーザーデータ
訪問者の環境を含む過去28日間の集計。今日変更して、今日すべてが入れ替わる値ではありません。ページとサイト全体の数値を混ぜません。
ラボデータ
その時の条件による診断。毎回同じ値になるとは限りません。LighthouseのTBTはINPそのものではなく、ラボの点数も実ユーザーの体験を代替しません。
Google：PSIの実ユーザー／ラボデータ。記録例は「URL・日時・端末・指標・単位・3回の値・変更一つ」。合計点が上がっても、必要な画像や操作が壊れたら採用しません。
必要ならChromeで「どの待ち時間か」を確認
- 対象の公開記事でChromeのメニューから「その他のツール → デベロッパーツール」を開き、Networkを選択。
- 最初の訪問に近い比較ではDisable cacheを有効にし、同じ通信制限を選んで再読み込み。これはDevToolsを開いている間のブラウザーキャッシュの設定で、サーバーやCDNのキャッシュ削除とは別です。
- DocでHTMLのリクエストを選びTimingを確認。Imgでは対象画像の開始・取得時間とサイズを見る。Performanceの記録でLCP対象と内訳を確認できる場合は、同じ読み込みの記録で対応づけます。
Waiting/TTFBにはネットワークやサーバー側等の待ちが含まれます。長いというだけでサーバー会社を原因にしません。画面の名称・位置はChromeの版で変わることがあります。Chrome公式：Networkの計測・キャッシュ設定
03 / SAME PAGE, DIFFERENT BOTTLENECK
軽い画像でも、遅くなる場合があります。
画像最適化記事の合成風景画を再利用し、同じ表示の独立HTMLで「画像量」「HTML応答」「画像の読み込み開始」を一つずつ変えました。WordPressやレンタルサーバーの性能比較ではありません。
当サイト独自の合成HTML環境での実験です。本番WordPressの速度改善、実ユーザーのCore Web Vitals、特定サーバーの性能を実証したものではありません。
各条件3回。LCPは中央値、括弧内は最小〜最大。横棒は各条件の中央値LCPとなった1回の区間を同じ4.5秒の軸で表示。
HTML待ち 画像開始まで 画像取得 取得後の描画まで
基準：軽い画像
LCP 0.548秒（0.544〜0.564秒）
TTFB中央値 1.9ms ／ 画像 42,200bytes
画像だけ重く
LCP 3.984秒（3.984〜3.984秒）
TTFB中央値 1.7ms ／ 画像 731,142bytes
HTML応答を遅延
LCP 1.200秒（1.196〜1.200秒）
TTFB中央値 803.7ms ／ 画像 42,200bytes
画像の発見を遅延
LCP 1.360秒（1.360〜1.364秒）
TTFB中央値 1.8ms ／ 画像 42,200bytes
ポイントは、容量が小さくても「HTMLを待つ」「画像が見つかるのを待つ」時間は残ること。画像容量の削減率をLCPの改善率に置き換えず、実際に遅い区間を確認します。
実測条件・再現方法・限界
Chromium 153.0.8010.12、390×844px、DPR1、CPU制限なし。CDPで遅延150ms・下り200,000bytes/秒・上り100,000bytes/秒を設定。各回を新しいブラウザーコンテキストで開き、キャッシュを無効化。実際の文書TTFBは約2msとなる回もあり、設定値がすべてのリクエストに同じ待ちを付ける保証ではありません。PerformanceObserverで全12回のLCP対象が同じhero画像であることを確認。LCP・TTFBはブラウザー計測値、画像容量はResource TimingのencodedBodySizeです。1200×800px画像を342CSSpx幅で表示。
baselineはWebP、large-imageは同じ寸法のPNG、slow-htmlはHTMLを送る前に800ms待機、late-imageはスクリプト実行800ms後に同じWebPのsrcを設定。遅延値は原因を分けるための実験条件で、現実の発生原因を推定した数値ではありません。ローカル環境の結果は、実機・実回線・WordPress・PHP・DB・混雑時の性能へ一般化できません。
04 / CHANGE ONE THING
遅い場所に合わせて、対策を一つ選ぶ。
HTMLの応答までが長い
特定の記事だけか、全体か、ログアウト時も同じかを確認。キャッシュの利用状態・リダイレクト・テーマ／プラグインの処理・サーバー状態等を候補にします。バックアップを取り、検証環境で一つずつ切り分けます。
対象画像の取得が長い
表示寸法に対する画像寸法、実際に選ばれたファイル、容量を確認。必要以上なら画像の寸法・形式・画質の比較へ。全画像を無条件に変換する必要はありません。
画像の読み込み開始が遅い
最初に見える主要画像がJS実行後に追加されていないか、遅延読み込みの対象になっていないかを確認。LCP対象の画像を無条件にlazyにせず、テーマ・最適化機能の設定を検証環境で照合します。
取得後も表示を待つ
CSS・フォント・JavaScriptやメインスレッドの処理を調べます。画像圧縮だけを繰り返さず、Performance記録やテーマの公式案内で確認。理由の分からないCSS削除・JS遅延設定を一括適用しません。
LCPは複数区間に分かれます。対象を早く発見できること、取得後に表示を妨げないことも重要です。Google：LCPの内訳と対策
WordPressで、画像の「登録情報」と「実際の取得」を照合する
設定を変えずにできる確認です。「メディア → ライブラリ」で対象画像を開き、ファイル名・サイズ・寸法を控えます。一覧表示では画像タイトルから詳細へ。下の英語画面は当サイトの隔離WordPress 7.1.2の実画面で、File sizeが容量、Dimensionsが寸法です。確認だけなら更新・削除は押しません。WordPress公式：画像詳細の項目
次に、匿名表示の取得ファイルと比べます。同じ記事をスマートフォン幅でも開き、上のChrome NetworkのImg欄で実際のファイル名・サイズを確認します。登録原本が、そのまま取得されるとは限りません。
隔離環境の390px表示では、画像の表示幅330CSSpxに対し、選ばれた実ファイルは768×512pxのPNG・310,809bytesでした。登録原本が2MBだから「毎回2MBを転送」とは判断できません。必要な画質と実際の取得量を見て、画像最適化が必要かを決めます。
再表示が速い理由も、推測しない。同じURLの初回・再表示・ブラウザーキャッシュ無効を比較しましたが、この環境では対象画像は3条件ともHTTP200・同じデータ量で、キャッシュヒットは確認できませんでした。キャッシュを有効にしただけで効果を確認したとは言えません。サーバー/CDNのキャッシュや、LCP改善はこの操作では未検証です。
この確認では記事・画像・プラグイン設定を変更していません。本文の変更前後SHAは一致し、比較後はブラウザーのキャッシュ無効設定を解除しました。画像量と表示速度は別の判定であり、合成HTMLの4条件の数値をWordPressの改善効果に置き換えません。
反応が遅いなら、同じ操作を再現する
「どのページで何を押したか」を一つ記録します。メニュー・検索・フォームの入力など、遅い操作を同じ条件で比較。スクリプトや処理の負荷を調べ、広告や計測を一括削除して解決扱いにしません。ログイン中だけの問題や外部サービス待ちも分けます。初期読み込みだけの計測では、操作中のINPの問題を否定できません。
位置が動くなら、表示領域と発生タイミングを見る
画像の幅・高さ、埋め込みや広告の領域確保、遅れて出るバナー等を確認。画像の容量を減らす作業とは別です。ページを開いた直後だけでなく、スクロールや読み進めた後も確認。実ユーザーCLSと、短いラボ計測のCLSが一致するとは限りません。
05 / KEEP A WAY BACK
WordPressでは、設定を保存してから一変更。
以下のWordPress操作は公式資料に基づく案内です。この独自実験で実際にプラグインを切り替えたわけではありません。既存の安全な検証環境がなければ、公開サイトで停止テストを始めず、管理担当へ相談します。
- 変更前を保存：現在のプラグイン一覧・版、キャッシュ／圧縮／遅延読み込みの設定画面を自分の非公開保管場所へ保存。ファイルとDBのバックアップ、復元方法を確認。
- 重複を調べる：サーバー・テーマ・プラグインで同じキャッシュ、CSS/JS圧縮、遅延処理が重なっていないか確認。機能名と担当を整理し、根拠のある候補一つだけを検証。
- 検証環境で変更：管理画面の「プラグイン → インストール済みプラグイン」で対象と版を照合。停止する場合は「削除」と区別し、依存機能や影響を先に確認します。個別機能だけ停止できるなら設定の切り替えを優先。複数を同時に止めない。
- 同条件で再測定：キャッシュを比較の都合で変えたなら両側の条件を揃えて記録。管理者の画面だけでなく、匿名表示・メニュー・画像・フォーム・スマホも確認します。
- 悪化・破損したら戻す：対象設定を保存した状態へ戻す／停止した対象を再有効化し、該当キャッシュを公式手順で更新。原因不明の追加変更を重ねず、戻した後の表示と機能を再確認します。
表示・機能が壊れたら、速度点数より復旧を優先。
管理画面へ入れない、フォームが送れない、元設定が分からない場合は停止。必要なら500・白画面の復帰手順へ進みます。DBの一括削除や初期化を速度対策の初手にしません。
数値と使いやすさを、両方確かめる。
0 / 5 確認済み
チェックは読者の確認補助で、端末外へ送信・保存しません。値が少し変わっただけなら成功・失敗を断定せず、測定時刻や混雑、キャッシュ状態も確認。問題がなく、再現できる差も見られなければ、不要な追加設定を止める選択もあります。
次の作業は、原因が分かった後に。
画像の見え方・容量を確認 → 画像最適化
戻せる準備を整える → バックアップと復元
別の運営課題へ → WordPress運営ガイド
HTML待ちが残る場合も、まず設定・回線・処理・サービス状態を照合し、計測記録を添えて管理担当や契約先へ相談。根拠をもって契約条件そのものを見直す段階ならレンタルサーバーの選び方へ進みます。乗り換えだけで解決する保証はありません。
根拠と、このページで確認した範囲
2026年10月20日にGoogle・Chrome・WordPressの公開一次資料を確認。資料に基づく操作案内と、合成HTMLの独立実測を区別しています。本番PSI画面、実ユーザーデータ、実WordPressの設定変更・速度改善、独立した初心者テストは未取得です。
- Web Vitals：指標・評価基準
- PageSpeed Insights：実ユーザーとラボ
- Chrome DevTools：Network
- LCPの内訳と最適化
- WordPress：競合の調査
- WordPress：プラグインの管理
- WordPress：変更の反映とキャッシュ
独立実験は同じ画像・一つのブラウザー・指定した条件だけ。INP・CLS・Lighthouse点数・本番の性能・SEO・確定報酬の改善は実証していません。編集・検証方針 ／ 訂正を連絡する