WordPressのTTFBを改善する方法｜サーバー応答時間の測り方と遅い原因の切り分け

2026.09.282026.10.20

PageSpeed Insightsでサーバーの応答が遅いと指摘されたのに、何から手を付ければいいか分からないことがあります。

TTFBは、ナビゲーション開始から応答の最初のバイトを受け取るまでの時間です。接続や通信の待ち時間も含み、サーバー内部の処理時間だけではありません。

この記事では、WordPressのTTFBを無料のツールで測り、遅い原因を切り分けて直す順番を紹介します。

この記事で使う高速化診断は、当サイトと同じMOTOKI合同会社が作った「WEBツール箱」の1つです。

無料で、会員登録なしで使えます。

最終確認日：2026年9月28日

この記事で分かること

TTFBの目安と、ツールでの測り方
時間の内訳から、通信とサーバー側のどこを追加調査するか絞る方法
WordPressでTTFBを縮める順番（ページキャッシュ・PHP・プラグイン）
ツールを使わずに測る方法

WEBツール箱

高速化診断｜サーバー応答速度(TTFB)を無料で実測 URLを入れるだけで、サーバーの応答速度(TTFB)を実測し、ページキャッシュ・圧縮・表示を妨げる読み込みなど高速化の設定状況を100点満点で採点します。WordPressが遅い原…

最初の答え｜計測条件をそろえ、通信とサーバー側の待ち時間を切り分ける

TTFB（このツールの独自基準）	判定
0.4秒以内	良好
0.4〜0.8秒	やや遅め
0.8秒を超える	改善の対象

PHPやデータベースの処理は原因の候補ですが、DNS、接続、TLS、転送、通信経路、キャッシュの状態も確認します。TTFBだけで原因を特定することはできません。

ページキャッシュなどから返せないリクエストでは、WordPressがPHPやデータベースを使ってページを組み立てます。

ページキャッシュを入れると、一度作ったHTMLをそのまま返すようになり、ページ生成の待ち時間を短縮できる場合があります。効果はキャッシュのHIT/MISSと変更前後の計測で確認します。

まずキャッシュ、次にPHPのバージョン、最後にプラグインの順で見ていくのが効率的です。

ツールで測る手順

高速化診断を開く
調べたいページのURLを入れて「診断する」を押す
上のカードで「TTFB」と「サーバー内部の処理」を見る
「時間の内訳」で、どの段階に時間がかかっているかを見る
「診断結果」で、ページキャッシュや圧縮の設定を見る

ツールは、日本国内のサーバー（エックスサーバー）から実際に3回接続し、いちばん速かった値を使います。

閲覧者の回線や端末の速さは含まれません。

TTFBのほかに、ページキャッシュ・HTMLの圧縮・ブラウザキャッシュ・表示を妨げる読み込みなどの設定を100点満点で採点します。

実測｜このサイトのトップページ

2026年9月28日に、このサイトのトップページを調べた結果です。

高速化診断でこのサイトのトップページを調べた結果 — このサイトのトップページを調べた結果。TTFBは152ミリ秒（2026/09/28時点の表示）

TTFBは152ミリ秒で、0.4秒以内の「良好」に入りました。

当時のツールは差分147ミリ秒を「サーバー内部の処理」と表示しました。この差分にもリクエスト送信や応答が戻るまでの通信が含まれ得るため、PHP処理時間の実測とは区別します。

同じ設置場所からの計測では通信の影響が小さくなる場合がありますが、この結果だけでは通信時間を確定できません。読者の回線からの計測とは条件を分けて読みます。

現在の結果はこのサイトの診断をいま開くと確かめられます。

ページキャッシュは「効いていると見られます（WP Rocket）」と出て、点数は82点でした。

減点されたのは、headの中で読み込むCSSが16件ある点と、画像の遅延読み込みが無い点です。

同じページを、手元の回線からcurlで3回測ると、TTFBは0.29〜0.33秒でした。

この差には通信経路だけでなく、測定時のキャッシュやサーバー負荷の違いも含まれ得ます。距離だけの影響とは断定しません。

ツール側の測定にも、その測定地点と対象サーバー間の通信が含まれます。「サーバー内部の処理」という表示も外部計測からの推定で、PHPやDBだけを直接測った値ではありません。

時間の内訳を読む

次の表は、外部計測の内訳を読むための分類です。「サーバー処理」欄にもリクエスト送信と応答が戻るまでの通信が含まれ得るため、PHPやDBの処理時間とは区別します。ブラウザーのナビゲーション全体のTTFBには、条件により転送やService Workerの準備時間も含まれます。

内訳	中身	長いときの原因
DNS解決	ドメインからIPアドレスを調べる	DNSの応答、名前解決のキャッシュ状態、通信経路を確認
サーバー接続	サーバーとの接続を作る	通信経路、混雑、再接続などを確認
SSL handshake	暗号化の準備をする	通信の往復、TLSの交渉、接続の再利用条件などを確認
サーバー処理	ページを組み立てて返し始める	キャッシュが無い・PHPが古い・プラグインが重い

比べるために、wordpress.org を調べた結果です。

高速化診断でwordpress.orgを調べたときの時間の内訳 — wordpress.orgを調べたときの時間の内訳。接続とSSLの時間が大きい（2026/09/28時点の表示）

TTFBは506ミリ秒で、そのうちサーバー接続が166ミリ秒、SSL handshakeが173ミリ秒でした。

当時の推定欄は167ミリ秒でした。接続とTLSの合計が大きいことは読み取れますが、残りを純粋なサーバー処理時間とは断定できません。

接続やTLSが長い場合は距離や通信経路、混雑、再接続などを調べます。遠距離だけが原因とは限らないため、複数地点・複数回の結果を比べます。

日本の読者が中心なら国内の測定地点でも確認します。サーバーの所在地だけで決めず、CDNや経路、キャッシュ条件を含めて比較してください。

WordPressでTTFBを縮める順番

1｜ページキャッシュを入れる

匿名で閲覧できる記事ページでは、ページキャッシュの状態を最初に確認すると原因を絞りやすくなります。会員ページやカートなど、個人別の内容を返すページは対象を分けます。

エックスサーバーやmixhostなど、サーバーの管理画面に高速化の設定があるなら、その対象範囲と既存キャッシュとの重複を確認してから設定します。

サーバー側に無ければ、LiteSpeed Cache（LiteSpeedのサーバー向け）やWP Fastest Cacheなどのプラグインを使います。

有料のWP Rocketの設定は「WP Rocketの設定方法」で解説しています。

WordPressにログインしたまま自分のサイトを開くと、多くのキャッシュは使われません。

キャッシュの効き目は、ログアウトした状態か、このツールで確かめてください。

2｜PHPのバージョンを上げる

PHPは新しいバージョンほど処理が速くなる傾向があります。

サーバーの管理画面で、WordPressとプラグインが対応している範囲の新しいバージョンに切り替えます。

切り替える前にバックアップを取り、切り替えたあとは表示と管理画面が動くかを確かめてください。

3｜重いプラグインを探す

キャッシュを入れても管理画面や検索結果のページが遅い場合は、プラグインの処理が重い可能性があります。

Query Monitorなどの調査用プラグインを入れると、1ページを作るのにかかった時間や、遅いデータベースの問い合わせが分かります。

使っていないプラグインは、停止するだけでも処理が減ります。

4｜サーバーを見直す

キャッシュを設定した後もTTFBが長い場合は、HIT/MISS、通信経路、PHPやDBの計測結果、サーバーの負荷を確認します。外部計測の0.8秒という値だけでサーバー性能の不足を判断せず、原因を絞ってからプラン変更や移転を検討します。

同じ会社のサーバーでも、プランによって使えるCPUやメモリが違います。

サーバーを替える前に済ませておくことの順番は「ホームページ表示速度改善の手順と優先順位」にまとめています。

ページキャッシュの判定の読み方

ツールは、ページキャッシュが効いているかを、次の順に手がかりを探して判定します。

レスポンスヘッダーのキャッシュの印（x-cache・x-litespeed-cache・cf-cache-status・ageなど）
HTMLの末尾にキャッシュ系プラグインが書き込むコメント（WP Rocket・LiteSpeed Cache・WP Super Cacheなど11種類）
キャッシュ系プラグインの読み込みがあり、サーバーの処理が200ミリ秒以内で終わっていること

表示	手がかり	読み方
ページキャッシュが動いています	ヘッダーかHTMLのコメントに印がある	手掛かりを検出した状態。HIT/MISSなどの値と対象レスポンスを確認する
ページキャッシュが効いていると見られます（プラグイン名）	印は無いが、キャッシュ系プラグインがあり、処理が速い	速度やプラグインの存在だけではキャッシュHITを確定できない
キャッシュ系プラグインはありますが、キャッシュから返された印は確認できませんでした（注意）	プラグインはあるが、処理が200ミリ秒を超えている	キャッシュ対象外や再生成は候補。通信・負荷の影響もあり、HIT/MISSとログで確認する
ページキャッシュはヘッダーやHTMLからは確認できませんでした（減点なし）	印もプラグインも無いが、処理が速い	印を出さない形でキャッシュが効いている可能性がある
ページキャッシュの痕跡はヘッダーやHTMLからは見つかりませんでした（注意）	印もプラグインも無く、処理が200ミリ秒を超えている	印がないだけでは未使用と断定できない。対象URLのHIT/MISSや設定を確認する

このサイトは、ヘッダーにもHTMLのコメントにも印はありませんでした。

それでも、WP Rocketの読み込みがあり、ツールの推定欄が147ミリ秒だったので、「効いていると見られます（WP Rocket）」と出ています。

wordpress.orgは印もキャッシュ系プラグインも見つかりませんでしたが、ツールの推定欄が167ミリ秒だったので、減点しない「確認できませんでした」になりました。

判定の文言とあわせて、TTFBとサーバー処理の数字そのものを見てください。

ツールを使わずに測る方法

ブラウザの開発者ツールで測る

調べたいページを開き、F12（Macはcommand＋option＋I）で開発者ツールを開く
「Network」（ネットワーク）のタブを選び、ページを読み込み直す
対象URLのDocument（HTML）の行を選び、「Timing」（タイミング）のタブを開く
「Waiting for server response」を確認する（接続準備を含むナビゲーション全体のTTFBとは範囲が異なる）

DevToolsの「Waiting for server response」は、リクエスト送信後の待ち時間で、通信の往復と応答準備を含みます。下のcurlのtime_starttransferは接続準備も含む開始からの時間なので、両者の数字をそのまま同じ条件の値として比べないでください。

コマンドで測る

Windowsのコマンドプロンプト、Macのターミナルでは、curlで測れます。

curl -s -o /dev/null \
  -w "%{time_starttransfer}\n" \
  https://example.com/

表示された数字（秒）がTTFBです。

Windowsでは「/dev/null」を「NUL」に変えて、1行にまとめて入力します。

何回か測って、ばらつきも見てください。

WordPress 6.1以降は、管理画面の「ツール → サイトヘルス」にも、ページキャッシュとサーバーの応答時間の項目があります。

サイトヘルスの読み方は「サイトヘルスの状態を改善する方法」で解説しています。

このツールの限界

計測するのは日本国内の1か所からで、閲覧者の回線や端末の速さは含まれない
計測するサーバーと同じ場所にあるサイトは、TTFBが数十ミリ秒と極端に速く出る
LCPやCLSなどの体感速度（Core Web Vitals）は測らない
結果は最大1時間だけ一時保存されるので、設定を変えた直後は古い結果が出ることがある

確認した範囲は、2026年9月28日の掲載結果と手元の回線からのcurl計測3回です。設定変更による改善、ページキャッシュのHIT、PHPやDBだけの処理時間は未確認です。

体感速度は、PageSpeed Insightsとあわせて確かめてください。

ページ全体の重さ（転送量）はページ重量診断で測れます。

WordPressの高速化の全体像は「サイトの高速化（コアウェブバイタル）に関する施策」にまとめています。

よくある質問

Q. 「表示を妨げる読み込み」はTTFBと関係ありますか？

TTFBとは別の項目です。

headの中にあるCSSや、async・deferの付いていないJavaScriptのことで、読み終わるまで画面が描かれません。

TTFBが速くても、ここが多いと画面が出るまで待たされます。

SWELLでCSSやJavaScriptを減らす方法は「読み込みファイル（CSS/JS）を極力減らす方法」で紹介しています。

Q. CDNを使えばTTFBは縮みますか？

CDNの近い配信拠点からHTMLをキャッシュHITで返せれば、TTFBを短縮できる場合があります。MISSや再検証時は配信元への接続が必要になるため、導入だけで短縮を保証するものではありません。

画像やCSSだけをキャッシュしても、HTML自体がキャッシュから返されるわけではありません。HTMLリクエストの配信経路とHIT/MISSを別に確認します。

Q. 他人のサイトも測れますか？

公開されているページなら測れます。

同じテーマやサーバーを使っているサイトと比べると、自分のサイトの遅さが設定のせいかどうかの目安になります。

まとめ

TTFBは高速化診断で測れ、独自の0.4秒・0.8秒の判定と一般的な目安を区別する
時間の内訳で追加調査する段階を絞る。外部計測だけで純粋なサーバー処理時間を分離しない
WordPressでは、ページキャッシュ → PHPのバージョン → プラグインの順に見る
測定値には測定地点からの通信も含まれ、サーバー内部処理を直接測った値ではない
キャッシュの判定は、ヘッダー・HTMLのコメント・プラグインと処理の速さの順に見ている