TTFB（Time To First Byte）は、ブラウザーがページを要求してから、サーバーの応答の最初の1バイトが届くまでの時間です。DNS の名前解決、接続、TLS のやり取り、サーバーが HTML を作る時間が含まれます。web.dev では、多くのサイトの目安として 0.8秒以下 を挙げています。
WordPress では、TTFB の大部分を「PHP が HTML を作る時間」が占めることが多く、ページキャッシュの有無で大きく変わります。この記事では、計測してから、効果の大きい順に見直す手順を説明します（2026年10月時点）。
手順1：TTFBを計測して内訳を見る
curlで計測する
curl の -w オプションで、各段階までの経過時間を表示できます（単位は秒）。
curl -s -o /dev/null -w 'DNS: %{time_namelookup}\n接続: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\n合計: %{time_total}\n' https://example.com/Windows の PowerShell では curl が別のコマンドの別名になっていることがあるため、curl.exe と書きます。また、出力先は -o NUL にします。
結果の読み方は次のとおりです。
TTFBからTLSを引いた時間が、サーバーが応答を作っていた時間の目安DNS・接続・TLSが長い場合は、サーバーの処理ではなく、DNS やネットワーク、サーバーまでの距離の問題（CDN が効く部分）
1回だけでは揺れがあるので、3〜5回続けて測ります。キャッシュの効いていない1回目と、2回目以降を分けて見ます。
キャッシュが効いているか確かめる
ページキャッシュを使っている場合、応答のヘッダーにキャッシュの状態が出ることがあります。
curl -sI https://example.com/ | grep -iE '^(cache-control|x-cache|cf-cache-status|x-litespeed-cache|age)'ヘッダーの名前はキャッシュの種類によって違います（Cloudflare なら cf-cache-status、LiteSpeed Cache なら x-litespeed-cache など）。
ログイン中は別に考える
管理画面にログインしているときは、多くのページキャッシュが働かないため、TTFB は長くなります。訪問者の体感を測るときは、ログアウトした状態か、シークレットウィンドウ、または上の curl で測ります。
手順2：ページキャッシュを使う
ページキャッシュは、PHP が作った HTML を保存しておき、次のアクセスでは PHP とデータベースを使わずに返す仕組みです。TTFB への効果がもっとも大きい対策です。
- レンタルサーバーのキャッシュ機能：多くのレンタルサーバーに、管理画面からオンにできるキャッシュ機能がある
- キャッシュプラグイン：WP Super Cache、W3 Total Cache、LiteSpeed Cache（LiteSpeed サーバーの場合）など
- Webサーバーのキャッシュ：VPS なら nginx の FastCGI キャッシュなど
キャッシュは1種類にします。同じ働きのものを重ねると、更新が反映されない原因になります。プラグインの選び方はWordPressの高速化（キャッシュ）プラグイン比較を参照してください。
導入したら、手順1の計測をもう一度行い、2回目以降の TTFB が短くなったことを確かめます。
手順3：PHPを見直す
ページキャッシュが使えないページ（ログイン中、カート、検索結果など）や、キャッシュが切れた直後の速さは、PHP の処理速度で決まります。
PHPのバージョンを上げる
管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で、PHP のバージョンを確かめます。PHP 7.4 や 8.0 など、サポートが終わったバージョンを使っている場合は、レンタルサーバーの管理画面などから PHP 8.2 以降に上げます。上げる前にバックアップを取り、ステージング環境で動作を確かめます。
OPcacheを有効にする
OPcache は、PHP のスクリプトをコンパイルした結果をメモリに保存し、毎回のコンパイルを省く機能です。レンタルサーバーでは多くの場合すでに有効です。VPS で自分で設定する場合は、Webサーバー経由の PHP が読む php.ini（Debian・Ubuntu で PHP 8.3 の PHP-FPM なら /etc/php/8.3/fpm/php.ini など）を確かめます。
opcache.enable=1
; 単位はMB。数字だけを書く（「64M」のような単位は付けない）
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000変更したら PHP-FPM を再読み込みします（例：sudo systemctl reload php8.3-fpm）。設定の詳細と状態の確認方法はWordPressのOPcache設定を参照してください。
PHP-FPMの待ちを確かめる（VPS）
同時アクセスが多いときだけ TTFB が長くなる場合は、PHP-FPM のプロセスが足りず、リクエストが順番待ちになっていることがあります。pm.max_children の考え方はVPSでPHP-FPMを最適化する方法を参照してください。
手順4：遅い処理を見つける
キャッシュが無い状態の TTFB が長い場合は、どのプラグインやテーマの処理が時間を使っているかを調べます。
Query Monitor で調べる
Query Monitor プラグインを入れると、ページごとに、データベースへの問い合わせ（クエリ）の数と時間、遅いクエリ、外部への HTTP リクエストを、どのプラグインが出したかとあわせて確かめられます。外部 API への通信を毎回待っているプラグインは、TTFB を大きく延ばします。使い方はQuery Monitorの使い方とWordPressパフォーマンス診断を参照してください。調べ終わったら無効にします。
プラグインを1つずつ止めて比べる
ステージング環境などで、プラグインを1つずつ無効にして TTFB を測り、差の大きいものを探します。WP-CLI なら次のように操作できます（example-plugin はプラグインのフォルダー名に置き換えます）。
wp plugin list --status=active
wp plugin deactivate example-plugin
# 計測してから元に戻す
wp plugin activate example-pluginキャッシュプラグインやセキュリティプラグインを「不要なもの」として一律に止めるのではなく、計測して遅い原因になっているものを見つけ、設定の見直し・代わりのプラグイン・削除を検討します。
autoload の量を確かめる
WordPress は、wp_options テーブルのうち autoload が有効なオプションを、すべてのページで最初にまとめて読み込みます。使わなくなったプラグインの設定などで、この量が大きくなっていることがあります。WordPress 6.6 以降では、合計が約800KBを超えるとサイトヘルスに「自動読み込みオプションがパフォーマンスに影響する可能性があります」という趣旨の問題が表示されます。WP-CLI では次のように確かめます。
# autoload が有効なオプションの合計サイズ（バイト）
wp option list --autoload=on --format=total_bytes
# サイズの大きいもの10件（下ほど大きい）
wp option list --autoload=on --fields=option_name,size_bytes --format=csv | sort -t, -k2 -n | tail大きいオプションが削除済みのプラグインのものなら、バックアップを取ってから削除します。使っているプラグインのものは、プラグインの作者に問い合わせます。
手順5：永続オブジェクトキャッシュとデータベース
ログイン中のページや、ページキャッシュを使えない動的なページが多いサイトでは、Redis や Memcached を使った永続オブジェクトキャッシュが効きます。データベースへの同じ問い合わせを、メモリから返せるようになります。設定はWordPressのオブジェクトキャッシュをRedisで高速化する方法を参照してください。
VPS で MySQL・MariaDB を自分で管理している場合は、innodb_buffer_pool_size がデータベースの大きさに対して小さすぎないかも確かめます。設定ファイルの [mysqld] の項目に書き、データベースを再起動して反映します。
[mysqld]
innodb_buffer_pool_size = 1G値はサーバーのメモリ量とデータベースの大きさから決めます。PHP やWebサーバーが使う分のメモリを残してください。
手順6：サーバーまでの距離とネットワーク
手順1の DNS・接続・TLS が長い場合は、サーバーの処理ではなく、通信の部分に時間がかかっています。
- 利用者の多い地域から遠いサーバーを使っている場合は、CDN で HTML までキャッシュするか、近い地域のサーバーを検討する
- HTTP/2・HTTP/3 や TLS 1.3 に対応しているかを確かめる
CDN の導入はWordPressにCDN（CloudFront・Cloudflare）を設定する方法を参照してください。
まとめ
curl -wで TTFB と内訳を測り、サーバーの処理か通信かを分ける- 効果がもっとも大きいのはページキャッシュ。1種類にして、導入後に測り直す
- PHP は 8.2 以降に上げ、OPcache を有効にする（php.ini の値は単位を付けずにMBの数字で書く）
- 遅い原因は Query Monitor やプラグインの切り替えで計測して探し、autoload の量も確かめる
- 動的なページが多いなら永続オブジェクトキャッシュ、遠い地域の利用者が多いなら CDN を検討する