.png?q=75&fm=webp)
TTFB(Time to First Byte)とは?仕組みから計測方法まで徹底解説
このページではTTFB(Time to First Byte)についてわかりやすく解説していきます。
計測される仕組みから、評価内容までをわかりやすく解説していきます。
TTFBの改善方法を知りたい方は「TTFBの5つの改善施策」の記事をご覧ください。
TTFBとは?
TTFB(Time to First Byte)は、ブラウザがWebページをリクエストしてからサーバーから最初の1バイトのデータを受信するまでにかかる時間を指します。
これは、Webサイトのパフォーマンスを測定する重要な指標の一つで、特にサーバーの応答性を示しています。
TTFBが短いほど、サーバーの応答が速く、結果的にページの表示速度が向上します。
特に、LCP指標やFCP指標にも含まれる指標でTTFBが改善されるとLCPやFCPの改善にもつながります。
LCPやFCPの詳しい説明については「LCPとは」「FCPとは」の記事をご覧ください。
TTFBの計測される仕組みをわかりやすく解説
ここではTTFBの計測開始タイミングから終了までの説明を画像を使ってわかりやすく解説していきます。
詳しく理解することで、より一層改善の方法がわかりやすくなります。
主に計測開始から終了までの順序をまとめると下記となります。
- DNSルックアップ(計測スタート)
- TCP接続
- SSL/TLSネゴシエーション
- サーバー処理からレスポンス送信開始(計測終了)
TTFBの計測の流れとしては、まずブラウザやツールがサーバーにリクエストを送信し、DNS解決やTCP接続、TLSハンドシェイクなどの通信処理が行われます。
その後、サーバーがリクエストを処理し、レスポンスを生成してネットワーク経由で送信します。
クライアントは最初のバイトを受信した時点でTTFBを記録し、レスポンス送信完了までの時間がTTFBの時間として計測されます。
1. DNSルックアップ(計測スタート)
WebサイトにアクセスしたタイミングでTTFBの計測がスタートします。
Webサイトにアクセスすると、初めにDNSルックアップの動作を行います。
DNSルックアップとは、ドメインを表示させるためにIPアドレスに変換するためにDNSサーバーへ問い合わせを行う動作のことを言います。
この処理は下記の図のように階層的に実行されます。
IPアドレスを確認する順番
- ブラウザのローカル、OSのDNSキャッシュを確認(キャッシュがあればIPを返す)
- キャッシュサーバーを確認(キャッシュがあればIPを返す)
- DNSサーバー、TLDサーバー、権威DNSサーバーへ確認
- IPを返す
DNSルックアップの動作では、初回アクセス時やキャッシュが無効な場合は数百ミリ秒かかることもあります。
キャッシュの設定を正しく設定することで、応答速度も速くなります。
他にもDNS応答速度、ネットワーク遅延、DNSサーバーの地理的位置などがパフォーマンスに影響する要素です。
2. TCP接続
TCP接続は、クライアント(ブラウザ)とサーバー間で信頼性の高い双方向通信チャネルを構築するプロセスです。
簡単にいうと、クライアントとサーバーで受信する準備をする工程となります。
下記の画像の順番にクライアントとサーバーの接続のためのやり取りが発生します。
図の流れを解説すると、クライアントがサーバーに対してSYN(Synchronize)パケットを送信し接続開始を要求します。
次に、サーバーがSYN-ACK(Synchronize-Acknowledgment)パケットで応答し、接続要求を承認すると同時に自身のシーケンス番号を通知します。
最後に、クライアントがACK(Acknowledgment)パケットを送信して接続確立を完了させます。
接続確立時間は、通常数十ミリ秒から数百ミリ秒かかります。
地理的距離、ネットワーク品質、サーバーの負荷状況などが処理時間に大きく影響します。
3.SSL/TLSネゴシエーション
SSL/TLSネゴシエーションは、安全な通信を確立するためにクライアントとサーバー間で行われる一連の手順で、主に「ハンドシェイク」と呼ばれる段階で実行されます。
ハンドシェイクでは、使用する暗号方式の選択、公開鍵の交換、セッションキーの生成・共有が行われ、通信データの暗号化と整合性が保証されます。
クライアントとサーバーのやり取りという点では、TCPと似ていますが、SSL/TLSの場合は、証明書の送信、鍵交換、暗号方式の情報確定をする動作で、セキュリティに関連する情報のやり取りと考えておくとわかりやすいでしょう。
この過程には複数回の往復通信が必要なため、TCP接続確立後に即座にデータを受信できず、TTFBが増加する原因となります。
特に、RSA鍵交換や大きな証明書チェーンを用いる場合、暗号処理の計算時間もTTFBに影響します。
そのため、HTTP/2やTLS 1.3では往復回数を削減し、暗号処理効率を改善することで、SSL/TLSネゴシエーションによるTTFB増加を抑制しています。
4. サーバーでの処理からレスポンス送信(計測終了)
サーバー処理の工程では下記の図のような動きが行われます。
サーバーでの処理では、まずサーバーがHTTPリクエストを受け取り、ヘッダーやパラメータを解析します。
リクエスト内容に応じてアプリケーションが動的処理やデータベースやキャッシュ、外部APIを呼び出し、必要なデータを取得・計算します。
取得したデータを基にHTMLやJSONなどのレスポンスを組み立てるという処理が行われます。
サーバーでの処理が完了すると、クライアント(ブラウザ)にレスポンスが送信(これが「最初の1バイト」となりる)されTTFBの計測が終了となります。
サーバーの処理能力、データベースの最適化状況、コードの効率性などがこの段階の処理時間に影響します。
TTFBの測定には常にネットワークレイテンシが含まれています。
TTFBの評価の目安となる数値
TTFBは秒数によって評価されます。評価基準は以下の通りです。
下記の表のように0.8秒以下で良好、0.8秒~1.8秒でサーバー処理に改善の余地あり、1.8秒以上でユーザー体験に悪影響といった評価となります。
TTFB | 評価 | 表示色 | 説明 |
|---|---|---|---|
0.8秒以下 | 良好 | 緑色 | 高速。ユーザー体感も快適で、サーバー応答も最適化されている状態。 |
0.8秒~1.8秒 | 平均的 | 黄色 | やや遅め。サーバー処理やネットワーク遅延の改善余地あり。 |
1.8秒以上 | 非常に遅い | 赤色 | ユーザー体験に悪影響。サーバー処理やインフラに重大なボトルネックが存在する可能性。 |
Google PageSpeed Insightsでは、サーバーの応答時間を200ミリ秒未満にすることを推奨しています。
TTFBが重要な理由
TTFB(Time To First Byte)が重要な理由は、ウェブサイトやアプリケーションのユーザー体験と性能評価の基礎指標だからです。
整理すると以下のポイントがあります。
ユーザー体験の向上
TTFBが短いと、ページの最初の表示が早くなり、ユーザーが待たされるストレスを減らせます。
特にモバイルや低速回線では顕著で、初期表示が遅いと離脱率が上がるため、快適な閲覧体験の提供に直結します。
また、ページ全体の読み込み速度改善にも寄与し、ユーザーの操作継続や満足度向上につながります。
サーバー性能の指標
ネットワーク遅延やブラウザ処理を除いた、サーバー側の処理能力を測定できます。
リクエスト受信から最初のバイト送信までの時間を測定することで、アプリケーション処理やデータベースアクセス、サーバー設定の効率を評価できます。
これにより、ボトルネックの特定やサーバー性能改善の効果を定量的に把握でき、安定した高速応答の実現に役立ちます。
SEOや検索エンジン評価
TTFBはページ読み込み速度の指標の一つとして、検索エンジンのランキング評価に影響します。
応答が早いサイトはユーザー体験が向上し、検索エンジンも効率的にクロールできるため、インデックス速度や順位向上につながります。
逆にTTFBが遅いと評価が下がり、検索結果での露出やアクセス数に悪影響を及ぼす可能性があるため、SEO対策上も重要な指標です。
パフォーマンス改善の指標
TTFBはサーバー応答性能を直接示す指標であるため、パフォーマンス改善の効果を定量的に確認できます。
キャッシュ導入やデータベース最適化、アプリケーション処理の効率化などの施策が、TTFBの短縮として現れることで、改善の成果を評価可能です。
また、TTFBを定期的に測定することで、サーバー性能の劣化やボトルネック発生を早期に検知でき、安定した高速なページ表示を維持する指標として活用できます。
TTFBの測定方法をわかりやすく解説
TTFBを計測方法についてはWebPageTestとChrome DevToolsを活用するのがおすすめです。
それぞれわかりやすく解説していきます。
WebPageTestでの計測方法(おすすめ)
WebPageTestでもTTFBの数値を測定することができます。
計測手順は下記の通りです。
- WebPageTestにアクセス
- テスト対象のURLを入力
- テスト環境を選択
- Start Testを推して計測開始
WebPageTestの特徴としては、テストの環境を細かく設定できるという点です。
ユーザーの環境を想定して計測ができる点は大きなメリットとなります。
計測が終わると上記のようなサマリーが出てきて、左上の「Time to First Byte」の箇所に計測結果が出ます。
また、同じ画面で下の方にスクロールすると「Waterfall」という項目が出てくるのでそちらをクリックするとTTFB計測結果の詳細も確認ができます。
詳細画面では、確認したい項目をクリックすると、DNSルックアップやSSLネゴシエーションなどの項目別に計測された数値の確認が取れます。
詳細の確認が取れるので、細かく確認したい場合やユーザー環境に合わせて確認したい場合はWebPageTestがおすすめです。
Chrome DevToolsでの計測方法
測定したいページをChromeブラウザで開きます。
下記の手順に沿って計測ができます。
- Chromeでページを開き、右クリック → 「検証」 を選択
- 「ネットワーク」タブを開く
- ページをリロードしてリクエスト一覧を確認
- 名前の列にあるファイル名を選択(HTMLファイルなど)
- タイミングを選択
下記の画像の「サーバーの応答を待機しています。」の数値がTTFBの計測値となります。
DevToolsは、開発者やサイト運用者がTTFBを計測するのにおすすめなツールです。
よくある質問と回答
Q: TTFBとページ読み込み速度の違いは何ですか?
A: TTFBはサーバーの応答時間を測定する指標であり、ページ読み込み速度とは異なります。TTFBは応答性の測定値で、ページ全体の読み込み完了時間とは別物です。ただし、TTFBが改善されることで、ページ読み込み速度全体も向上することが期待できます。
Q: モバイルサイトでもTTFBは重要ですか?
A: はい、モバイルサイトでもTTFBは重要です。むしろ、モバイル環境では通信速度が不安定になることが多いため、サーバーの応答速度がより重要になります。モバイルファーストインデックスを採用しているGoogleにとっても、モバイルでの表示速度は重要な評価要素です。
Q: TTFBの改善にはどのくらい時間がかかりますか?
A: 改善方法によって異なります。キャッシュの設定やCDNの導入などは比較的短時間で効果が現れますが、サーバーの変更やデータベースの最適化は時間がかかることがあります。LandingHubのようなサービスを利用すれば、タグの追加だけで即座に改善効果を得ることができます。
まとめ
TTFBは、Webサイトの表示速度を改善する上で非常に重要な指標です。
サーバーの応答時間を示すこの指標を改善することで、FCP、LCP、CVRなど、様々な指標の改善が期待できます。
改善方法は多岐にわたりますが、重要なのは現状を正確に把握し、効果的な施策を優先度を付けて実施することです。
技術的な知識が必要な改善もありますが、LandingHub(https://www.landinghub.net/)のようなサービスを活用することで、専門知識がなくても大幅な改善を実現できます。
まずは現在のTTFBを測定することから始めて、できるところから改善に取り組んでみましょう。
