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

2026.09.282026.10.01

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をそのまま返すようになり、TTFBが数分の1になることも珍しくありません。

まずキャッシュ、次に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だけを直接測った値ではありません。

時間の内訳を読む

TTFBは、次の4つの時間を足したものです。

内訳	中身	長いときの原因
DNS解決	ドメインからIPアドレスを調べる	DNSサーバーが遅い
サーバー接続	サーバーとの接続を作る	サーバーが遠い
SSL handshake	暗号化の準備をする	サーバーが遠い・設定が古い
サーバー処理	ページを組み立てて返し始める	キャッシュが無い・PHPが古い・プラグインが重い

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

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

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

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

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

日本の読者向けのサイトなら、日本国内のサーバーを選ぶのがいちばんの近道です。

WordPressでTTFBを縮める順番

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

いちばん効くのがページキャッシュです。

エックスサーバーやmixhostなど、サーバーの管理画面に高速化の設定があるなら、まずそれを有効にします。

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

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

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

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

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

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

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

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

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

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

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

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

4｜サーバーを見直す

キャッシュを入れても、サーバー処理が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ミリ秒を超えている	ページキャッシュを入れる

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

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

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

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

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

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

調べたいページを開き、F12（Macはcommand＋option＋I）で開発者ツールを開く
「Network」（ネットワーク）のタブを選び、ページを読み込み直す
いちばん上のHTMLの行を選び、「Timing」（タイミング）のタブを開く
「Waiting for server response」の時間がTTFBにあたる

コマンドで測る

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時間だけ一時保存されるので、設定を変えた直後は古い結果が出ることがある

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

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

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

よくある質問

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

TTFBとは別の項目です。

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

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

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

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

CDNでHTMLまでキャッシュする設定にすれば、閲覧者の近くから返すので縮みます。

画像やCSSだけを配信する設定では、HTMLのTTFBは変わりません。

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

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

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

まとめ

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