TTFBとは？サーバー応答速度の見方と改善方法

TTFBは、Webページを開こうとしてから、サーバーから最初の1バイトが届くまでの時間を表す指標です。サーバー応答の遅さを確認するときによく使われますが、TTFB＝サーバー内部の処理時間ではありません。

実際のTTFBには、リダイレクト、DNS名前解決、TCP接続、TLSネゴシエーション、サーバー処理などが含まれます。そのため、数値が遅いときは「サーバーを変えれば解決」と決めつけず、どこで時間がかかっているかを切り分けることが重要です。

30秒でわかる結論

TTFBとは？

TTFBは「Time to First Byte」の略です。

ブラウザがページへのアクセスを開始してから、Webサーバーなどから最初の1バイトのレスポンスを受け取るまでの時間を表します。

TTFBが短いほど、ページ表示の「最初の返事」が早い状態と考えられます。

TTFBには何が含まれる？

TTFBは「サーバーがPHPを処理した時間」だけを測る指標ではありません。

Googleのweb.devでは、TTFBに次のような時間が含まれると説明されています。

TTFBの目安は何秒？

web.devでは、TTFBの大まかな目安として次の基準を示しています。

TTFBはCore Web Vitals？

TTFBはCore Web Vitalsそのものではありません。

Core Web VitalsではLCP・INP・CLSが中心ですが、TTFBはLCPやFCPより前に発生するため、最初のレスポンスが遅ければ後続の表示開始も遅れやすくなります。

TTFBとレスポンスタイムの違い

TTFBとレスポンスタイムは混同されやすい言葉ですが、同じ意味とは限りません。

「レスポンスタイム」はサービスや監視ツールによって測定範囲が違うため、数値を比較するときは定義を確認してください。

WordPressでTTFBが遅くなる主な原因

1．PHP処理が重い

WordPressはアクセス時にPHPを実行します。テーマやプラグインの処理が重いと、HTMLを生成し始めるまでに時間がかかります。

2．データベース処理が遅い

WordPressは記事・設定・ユーザー情報などをデータベースから取得します。複雑なクエリや肥大化したデータ、重いプラグイン処理があると応答が遅くなる場合があります。

3．ページキャッシュが使われていない

毎回PHPとデータベースでページを生成するより、生成済みHTMLを再利用できる構成では応答を短くできる場合があります。

4．プラグインが多い・処理が重い

プラグイン数だけで遅さは決まりませんが、外部API通信、複雑なDB処理、毎回実行される処理が多いプラグインはTTFBへ影響する可能性があります。

5．サーバーが混雑している

共用レンタルサーバーでは、同じ物理環境の負荷状況によって処理速度が変動する場合があります。時間帯によってTTFBが大きく変わるなら、混雑も候補になります。

6．CPU・メモリなどのリソース不足

動的処理が多いサイトやアクセスが集中するサイトでは、CPUやメモリの不足によりPHP・DB処理が遅くなることがあります。

7．外部APIや外部サービス待ち

ページ生成時に外部APIへ問い合わせる構成では、その返答待ちがサーバー処理を止める場合があります。

8．リダイレクトが多い

http→https、wwwあり→なし、旧URL→新URLのように複数段階のリダイレクトがあると、その分TTFBへ時間が加算されます。

TTFBを確認する方法

Chrome DevToolsで確認する

Chromeの開発者ツールではNetworkパネルから各リクエストのタイミングを確認できます。

ブラウザキャッシュ、既存接続、地域、回線状況などで数字は変わるため、1回だけで判断しないことが重要です。

CrUXなどの実ユーザーデータを見る

Chrome UX Report（CrUX）では、実際のChromeユーザー環境から集計されたフィールドデータとしてTTFBを確認できる場合があります。

ラボテストは同じ条件で比較しやすい一方、フィールドデータは実際の利用者の地域・回線・端末・キャッシュ状態などを含みます。

TTFBを測るときの注意点

1回の測定で決めない

ネットワークやサーバー負荷は毎回同じではありません。複数回測定し、中央値や傾向を見る方が実用的です。

測定場所をそろえる

東京から国内サーバーへ測る場合と、海外から測る場合ではネットワーク遅延が異なります。サーバー変更前後を比較する場合は、同じ地域・同じ条件で測ります。

キャッシュあり・なしを分ける

ページキャッシュやCDNキャッシュに当たった場合と、WordPressが毎回PHP処理する場合ではTTFBが大きく変わることがあります。

トップページだけ見ない

トップページがキャッシュ済みでも、検索ページ・商品ページ・会員ページなど動的ページだけ遅い場合があります。代表的な複数ページを確認してください。

TTFBを改善する方法

1．不要なリダイレクトを減らす

複数段階のURL転送がある場合は、可能なら最終URLへ直接転送する構成を検討します。

不要な中間転送を減らせれば、その分の待ち時間を削減できます。

2．ページキャッシュを利用する

WordPressでは、毎回PHPとデータベースを動かす必要がないページなら、ページキャッシュによってTTFBを短縮できる場合があります。

3．PHPを適切なバージョンへ更新する

サポート中のPHPを使い、WordPress本体・テーマ・プラグインとの互換性を確認します。古いPHPを使い続けることは性能だけでなくセキュリティ面でも避けるべきです。

4．重いプラグイン・テーマ処理を確認する

外部API通信、重いDBクエリ、大量の処理を毎回実行する機能がないか確認します。プラグインは「数」ではなく「何をしているか」で判断します。

5．データベースを確認する

不要データの蓄積、巨大な自動読み込みデータ、重いクエリなどがないか確認します。闇雲なDB削除はせず、バックアップを取ってから原因を特定します。

6．サーバーリソースを確認する

CPU使用率、メモリ使用量、同時アクセス、PHP実行制限などを確認します。常にリソース上限へ達しているなら、上位プランやサーバー変更も検討対象になります。

7．CDNを検討する

利用者とオリジンサーバーの距離が遠い場合、CDNによって近い拠点から応答できる構成では、ネットワーク遅延を減らせる場合があります。

TTFBが遅いときの確認順序

サーバー変更は最後に判断する

TTFBが遅いと、すぐに「レンタルサーバーが悪い」と考えがちですが、WordPressではプラグイン・テーマ・DB・キャッシュ構成などサイト側の原因も多くあります。

一方で、軽いHTMLページでも常に応答が遅い、時間帯による遅延が大きい、CPU・メモリ上限へ頻繁に到達する、といった場合はサーバー環境の見直しが有効なことがあります。

どんな場合にTTFBを重視する？

注意点

• TTFBだけでレンタルサーバーの優劣を決めない
• 1回だけの計測結果を絶対視しない
• 測定地域・回線・キャッシュ条件を揃えて比較する
• TTFB＝PHP処理時間と決めつけない
• Core Web VitalsとTTFBを同じ指標として扱わない
• キャッシュで改善しても、動的ページの根本原因が残っていないか確認する
• SEO目的だけで数十msを追い込むより、ユーザー体験全体を見る

教科書判定

よくある質問

まとめ