TTFBは、ブラウザーがページを要求してから最初のデータを受け取り始めるまでの時間を示す指標です。画像が表示される時間そのものではなく、DNS、接続、TLS、サーバー処理、ネットワークを含むため、遅いからといって直ちにサーバー会社だけが原因とは限りません。同じURLを複数回、同じ条件で測り、キャッシュの有無とWordPressの処理を切り分けることが改善の第一歩です。
TTFBに含まれる時間
TTFBには、名前解決、サーバーへの接続、TLS通信、リクエスト送信、サーバー内のPHPとデータベース処理、最初の応答が届くまでが含まれます。測定地点が遠い、回線が混雑している、初回接続でDNSやTLSに時間がかかる場合も数字が増えます。
画像の圧縮はページ全体の表示には有効ですが、通常はHTMLの最初の一バイトが返る前に画像本体を送るわけではありません。TTFBとLCP、INP、総読み込み時間を混同せず、それぞれの区間に合う対策を選びます。
一回の測定で判断しない
PageSpeed Insightsやブラウザー開発者ツール、サーバー監視など複数の情報を使います。ラボ測定は時刻や測定地点で変わり、実ユーザーデータは一定量が集まるまで時間がかかります。同じURLを数回測り、中央値とばらつきを記録してください。
トップページだけでなく、キャッシュされやすい記事、ログイン不要のカテゴリー、動的処理がある検索や会員ページを分けて測ります。すべて遅いのか、特定ページだけ遅いのかで原因候補が変わります。測定中にプラグイン更新やバックアップが走っていないかも確認します。
キャッシュ有無を切り分ける
一回目だけ遅く二回目以降が速いなら、ページキャッシュ生成に時間がかかっている可能性があります。常に遅いならキャッシュが効いていない、対象外、削除が頻繁、またはキャッシュより前の接続処理が遅い可能性があります。レスポンスヘッダーやキャッシュプラグインの状態を確認します。
管理者としてログイン中はキャッシュ対象外になることが多いため、シークレットウィンドウで公開ページを測ります。キャッシュを二重に入れると競合する場合があるので、サーバーキャッシュ、CDN、プラグインの役割を表にし、一つずつ有効性を検証します。
PHPとプラグインの処理を見る
重いプラグイン、外部API待ち、複雑なテーマ処理、古いPHPはサーバー処理を長くすることがあります。サイトヘルスでPHPを確認し、エラーログ、Query Monitorなど検証用の診断手段をステージングで使います。診断プラグインを本番へ常時置くと負荷になる場合があります。
有効プラグインを本番で無計画に停止せず、ステージングで一つずつ比較します。フォームやECなど必要機能まで速度だけを理由に削除しません。遅い処理が判明したら、設定見直し、代替、コード修正、キャッシュ対象化の順に検討します。
データベースを確認する
投稿や設定が増えると、肥大化したoptions、期限切れ一時データ、重い検索、インデックス不足などが応答へ影響することがあります。データベース容量だけで遅さを断定せず、どのクエリが時間を使うかを確認します。SQLを直接削除する前に完全なバックアップを用意します。
自動読み込みされる設定が大量にある、削除済みプラグインのデータが残るなどの問題は、原因プラグインの公式手順で整理します。最適化ボタンを何度も押しても設計上の重いクエリは直りません。専門的な解析が必要ならログを添えて制作者へ相談します。
サーバー資源と同居サイト
CPU、メモリ、プロセス数、同時実行数の制限に達すると応答が遅くなります。サーバーパネルのリソース使用量やエラーログを、遅かった時刻と照合します。同じ契約にある別サイトのアクセス集中、バックアップ、cronが影響する場合もあります。
一時的な混雑なのか、毎日同時刻に再発するのかを監視します。慢性的に上限へ達するなら、プラグイン調整だけでなく、サイト分離や上位プラン、より余裕のあるサーバーを検討します。サーバー変更前後は同じURLと条件で測ります。
外部通信とDNS・CDN
PHPが外部API、広告、フォント、ライセンス確認を同期的に待つと、HTML応答が遅れる場合があります。外部サービスの障害やタイムアウトも確認します。ブラウザーで後から読む外部スクリプトはTTFB以外へ影響するため、ネットワークの開始時刻を見て区別します。
DNSやCDN設定の誤り、遠い配信元、キャッシュミスも候補です。CDNを入れれば必ずTTFBが下がるとは限りません。配信地域、キャッシュ対象、オリジンサーバーへの接続、SSL設定を確認し、導入前後の実測で判断します。
TTFBの記録テンプレート
測定日、時刻、URL、測定地点、ログイン状態、キャッシュ状態、TTFB、同時に走っていた処理を一行に記録します。改善前後でツールや条件が違うと比較できないため、同じ端末または同じ測定サービスを使います。平均だけでなく中央値と最大値を残すと、一時的な遅延も把握できます。
変更履歴には、プラグイン設定、PHP、キャッシュ、CDN、サーバープランを記録します。数週間後に再び遅くなったとき、最後に何を変えたかが分かれば原因を戻せます。速度測定のスクリーンショットだけでなく、数値を表へ転記して検索できるようにします。
サーバー変更を検討する判断
コードや画像を整え、キャッシュも正常で、同居サイトの処理を分けても慢性的に資源上限へ達する場合は、上位プランや移転を比較します。CPU名称や高速という広告文だけでなく、PHP実行環境、ストレージ、キャッシュ、バックアップ、サポート、プラン変更の容易さを確認します。
候補サーバーにテスト環境を作れるなら、同じサイトの複製を同じ条件で測ります。DNS切り替え前に機能と速度を確認し、改善幅が目的に合うか判断します。移転後も外部サービスやテーマが原因なら改善しないため、測定記録を残して比較してください。
TTFBには接続とサーバー処理の両方が含まれるんですね。
ログアウト状態で同じ記事を数回測り、キャッシュの一回目と二回目も比べます。
はい、その比較で原因候補をかなり絞れます。
遅かった時刻とサーバー資源、バックアップ実行も照合してください。
いきなりプラグインを全部消したり、サーバーを替えたりしなくてよいと分かりました。
一つ変えて同じ条件で再測定なら、私にも結果が追えそうです！
その通りです。
速度改善は変更量より、原因と効果を対応させることが大切です。
改善の優先順位
測定結果を保存し、次の順で一項目ずつ変更します。
- 同じURLを複数回測り中央値を出す
- ログイン状態とキャッシュ有無を分ける
- 遅いページと時間帯を特定する
- PHP・プラグイン・クエリ・外部通信を調べる
- サーバー資源と同居サイトを確認する
- 一変更ごとに同条件で再測定する
迷わず始めたい人向けの選択肢
広告・PRを含みます。料金と特典は公式ページで最新条件をご確認ください。
TTFBが赤い数字だっただけで、サーバーが悪いと決めつけるところでした。
キャッシュ、PHP、データベース、資源を順番に調べて、同じ条件で比べます！
その切り分けができれば、必要な対策を選べます。
改善後も定期測定を続け、再発した時刻と変更履歴を残しましょう。
改善完了の基準
一度速い数字が出ただけでは完了ではありません。複数回の中央値が改善し、主要ページと実ユーザーデータに悪化がなく、変更内容を説明できる状態を完了とします。
- 同一条件で複数回測った
- キャッシュ有無を分けた
- 遅いページと時刻を特定した
- リソースとログを照合した
- 一変更ごとに再測定した
- 主要機能へ悪影響がないことを確認した
測定結果と高速化機能を照合する
原因を切り分けてもサーバー資源が慢性的に不足する場合は、高速化機能とプラン条件を公式ページで確認しましょう。測定一回ではなく、同条件の記録と照合して移転や変更を判断してください。
広告・PRを含みます。料金・特典・適用条件は公式ページで最新情報をご確認ください。