WordPressの表示速度は「何秒で全部読み込んだか」だけでは判定できません。 Googleの現在の目安は、LCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下を、実ユーザーの75パーセンタイルで満たすことです。サーバー応答を見るTTFBは良好の目安が800ミリ秒以下ですが、TTFBが速くても大きな画像やJavaScriptで表示が遅れることがあります。
この記事では、WordPressサーバー研究所の10種類の公開ページを2026年7月31日に各5回計測し、TTFB・HTML転送完了時間・HTML容量の中央値を公開します。実測結果だけでなく、何を測れて何を測れていないかまで明記します。
最初に結論：1つの秒数ではなく4指標を見る
| 指標 | 何を表すか | 良好の目安 |
|---|---|---|
| LCP | 主要な画像や見出しが表示されるまで | 2.5秒以下 |
| INP | クリックやタップに画面が反応するまで | 200ミリ秒以下 |
| CLS | 読み込み中にレイアウトがずれた量 | 0.1以下 |
| TTFB | 要求から最初の応答が返るまで | 800ミリ秒以下が良好の目安 |
Core Web Vitalsの合格判定はLCP・INP・CLSです。TTFBは原因を切り分ける補助指標であり、TTFBだけ速くしてもCore Web Vitals合格とは限りません。
今回の実測条件
- 計測日: 2026年7月31日
- 対象: jpansystem.infoのTOP、カテゴリ3ページ、記事6ページ
- 回数: 各URLを連続5回
- 取得: HTTPSリダイレクトを追い、HTTPステータス、TTFB、HTML転送完了時間、HTMLバイト数を記録
- 集計: 極端な1回に引っ張られにくい中央値
- 対象外: 画像・CSS・JavaScriptの描画、ユーザー操作、実端末の通信速度
計測地点や回線が変われば値も変わります。この表はサーバー応答を同一条件で比べる資料であり、全読者の体感速度を保証するものではありません。
HTMLの転送が0.1秒くらいでも、画像が見えるまで同じ速さとは限らないんですね。
私は小さい数字を見つけたら、それだけで全部速いと思い込んでいました。
そこを分けて考えられたら十分だよ。今回の実測はサーバーとHTMLの入口を見て、画像や操作感はPageSpeed Insightsの別指標で確認するんだ。
五回のうち一番速い値を載せるのではなく、真ん中の値を使うのも少し安心しました。
ただ、アクセスが混んだ時間には変わりそうで、その点はまだ気になります。
いい気づきだね。時間帯を変えて同じ測定を追加し、悪い側の値も残せば、普段だけでなく混雑時の弱さも見つけられるよ。
10ページ・各5回の実測結果
| ページ種別 | TTFB中央値 | HTML完了中央値 | HTML容量 |
|---|---|---|---|
| TOP | 79ms | 119ms | 198,973B |
| WordPressカテゴリ | 78ms | 118ms | 192,847B |
| レンタルサーバーカテゴリ | 76ms | 116ms | 200,601B |
| サーバー基礎記事 | 89ms | 113ms | 80,131B |
| SEO基礎記事 | 78ms | 106ms | 110,853B |
| 404解決記事 | 81ms | 123ms | 103,731B |
| 高速化記事 | 76ms | 95ms | 88,668B |
| サーバー比較記事 | 77ms | 94ms | 66,494B |
| エラー辞典 | 83ms | 101ms | 69,123B |
| 必須プラグイン記事 | 92ms | 95ms | 34,727B |
実測から分かったこと
- 10ページのTTFB中央値は76〜92msに収まり、GoogleがPSIで示す良好目安800msを大きく下回った
- HTML容量が約35KBから約201KBまで違っても、TTFB中央値の差は16msだった
- HTML容量が最大のレンタルサーバーカテゴリでも、HTML転送完了中央値は116msだった
- この結果だけではLCP・INP・CLSの合格を判定できない
中央値だけでなく変動幅も残す
今回のTTFBで最も小さい測定値は約66ms、最も大きい測定値は約100msでした。中央値が近いページでも、一回ごとの値には揺れがあります。改善前後を比べるときは、最速値だけを選ばず、五回すべての値と中央値を残してください。
たとえば変更前が「80、82、95、110、150ms」、変更後が「75、78、81、85、140ms」なら、最悪値だけでなく普段の応答も改善したと読めます。一方、変更後の一回だけが60msでも、残り四回が遅ければ効果を断定できません。
HTML容量はページ全体の通信量ではない
表のHTML容量には、別ファイルとして読み込む画像、CSS、JavaScript、フォントは含まれません。TOPが約199KBでも、それだけで記事ページより体感が遅いとは判断できません。ブラウザで実際に読み込む全リソースはPageSpeed Insightsや開発者ツールで別に確認します。
TTFBが速いのに画面が遅い原因
メイン画像が重い
サーバーがHTMLをすぐ返しても、画面上部の大きな画像が遅ければLCPは悪化します。実際の表示サイズを超える画像、圧縮不足、画面上部画像への不要な遅延読み込みを確認します。
CSSやJavaScriptが表示を止める
HTML取得後に多数のCSSやJavaScriptを読み、解析・実行する時間がかかる場合があります。機能を止める前に、PageSpeed Insightsの「レンダリングを妨げるリソース」と実際に使っている機能を照合します。
広告や埋め込みで画面がずれる
画像・広告枠の幅と高さが予約されていないと、読み込み後に本文が押し下げられてCLSが増えます。削除だけでなく、表示前から必要な領域を確保できているか確認します。
ボタン操作後の処理が重い
INPは読み込み速度ではなく、操作への反応を見ます。検索、メニュー、フォーム、絞り込みなど、読者が実際に触る機能をスマートフォンで試します。
PageSpeed Insightsを開いたら、携帯電話とデスクトップの結果が分かれていました。
点数だけ見ずに、LCP・INP・CLSのどれが悪いかを先に見るんですね。
そうだよ。まず実ユーザーのデータがあるか確認し、なければラボデータを改善の手掛かりとして使おう。
一回だけLCPが遅かったとき、すぐプラグインを消しそうになりました。
同じURLを三回以上測って、共通して出る指摘から触るほうが安全そうです。
その順番がいいね。変更前の値を残し、一項目だけ直して同じ条件で測れば、本当に効いた改善か判断できるよ。
初心者が同じ測定を再現する手順
- 測るURLをTOP・カテゴリ・記事から3〜10件選ぶ
- 同じ端末・同じ回線でPageSpeed Insightsを開く
- URLを入力して「分析」を実行する
- 携帯電話とデスクトップを分けて、LCP・INP・CLS・TTFBを記録する
- 同じURLを最低3回測り、中央値を残す
- 改善は画像、CSS・JavaScript、キャッシュなど一項目ずつ行う
- 変更後に同じURL・同じ条件で再測定する
成功状態: 点数だけでなく、対象URL、日時、端末区分、各指標、変更内容、変更前後の値が一行で追える状態です。
どの数値から改善するか
| 状態 | 最初の確認 |
|---|---|
| TTFBだけ遅い | キャッシュ状態、PHP処理、DB処理、サーバー負荷 |
| TTFBは速くLCPが遅い | メイン画像、フォント、レンダリング阻害 |
| INPが遅い | 操作時に動くJavaScript、長いメインスレッド処理 |
| CLSが悪い | 画像・広告・埋め込みの寸法、後から挿入される要素 |
| ラボだけ悪い | テスト条件の差を確認し、実ユーザーデータを優先 |
サーバー変更を検討する条件
画像やJavaScriptが原因なのにサーバーを変えても、LCPやINPが十分改善しないことがあります。複数ページでTTFBが継続して悪く、キャッシュ・PHP・データベースを確認しても改善せず、現在のプランでリソース不足が確認できた場合に初めて比較します。
以下はWordPress向けの高速化・キャッシュ・ログ確認機能を持つ3社です。すでにTTFBが安定している場合、この記事を理由に乗り換える必要はありません。移転を検討する場合だけ、同じURL構成で移転前後を測れるよう記録してください。
公式基準と測定資料
よくある質問
PageSpeed Insightsは何点なら合格ですか？
ラボスコアは90以上が緑ですが、検索や読者体験の判断では実ユーザーのLCP・INP・CLSも確認します。点数だけで合否を決めません。
TTFBが800ms以下なら表示速度は問題ありませんか？
いいえ。サーバー応答が良好でも、メイン画像、CSS、JavaScript、広告によってLCP・INP・CLSが悪化する場合があります。
毎回違う数値が出るのは異常ですか？
回線、計測地点、端末負荷、サーバー負荷で変動します。同じ条件で複数回測り、中央値と悪い側の値を記録してください。
最初はスコアを一回見て、赤ならサーバーを変えるしかないと思っていました。
今は、TTFBとLCPを分ければ、サーバーなのか画像なのかを少しずつ探せそうです。
測る目的がはっきりしたね。数字に追いかけられず、読者が待っている場所を一つずつ直せばいいんだ。
まだ実ユーザーデータが少なくて表示されないページもありそうです。
そのときはラボ結果を確定値だと思わず、同じ条件の比較に使いたいです。
それで大丈夫だよ。測定条件と変更前後を残し、速くなった理由を説明できる改善を積み重ねようね。
まとめ：中央値と指標の役割で速度を判断する
WordPressの速度は、LCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下を実ユーザーの75パーセンタイルで見るのが基本です。TTFBは800ミリ秒以下を良好の目安として、サーバー応答の切り分けに使います。今回の10ページ実測ではTTFB中央値が76〜92msでしたが、これだけでCore Web Vitals合格とは判定していません。
実測値は2026年7月31日の特定環境によるものです。地域、回線、キャッシュ、サーバー負荷で変動します。広告・PRを含みます。