TTFBとスループットの違いを完全理解【表示が遅い原因を誤診しないための実務解説】

Webが「遅い」と言われたとき、 TTFB（Time To First Byte） と スループット を混同してしまうと、 原因を誤診し、的外れな対策を打ってしまいます。

本記事では、

• TTFBとは何か
• スループットとは何か
• なぜ両者は全く別物なのか
• 実務ではどう切り分けるべきか

を図解イメージと具体例を交えて徹底解説します。

まず結論：TTFBとスループットは「遅さの種類」が違う

指標	意味	影響する体感
TTFB	最初の1バイトが返るまでの時間	「表示が始まらない」
スループット	一定時間あたりの転送量	「表示完了までが遅い」

TTFBは「待ち時間」、 スループットは「流れる速さ」です。

TTFB（Time To First Byte）を深く理解する

TTFBの定義

TTFBとは、 クライアントがリクエストを送信してから、最初のレスポンスデータを受信するまでの時間です。

Browser
  ↓ HTTP Request
[ DNS解決 / Network / Server処理 ]
  ↓ HTTP Response (First Byte)
Browser

TTFBが遅くなる主な要因

• DNS名前解決に時間がかかる
• ネットワーク遅延・パケットロス
• サーバ側の初期処理が重い

TTFBが遅い時の体感

• 画面が真っ白な時間が長い
• 「固まっている」ように見える

この状態で帯域を増やしても、 ほとんど改善しないのがTTFB問題の特徴です。

スループットを深く理解する

スループットの定義

スループットとは、 単位時間あたりに実際に転送できるデータ量を指します。

例：

• 100Mbps回線
• 実効スループット：20Mbps

スループットが低下する主な要因

• 回線帯域不足
• TCPウィンドウサイズ不適切
• パケットロスによる再送

スループットが遅い時の体感

• 表示は始まるが完了まで長い
• 動画や画像の読み込みが遅い

この場合、 帯域増強やTCP調整が効果的です。

実務でありがちな誤解

誤解①「回線が遅いから帯域を増やそう」

TTFBが原因の場合、 帯域を増やしても意味がありません。

誤解②「表示が遅い＝サーバが悪い」

実際には、

• DNSが遅い
• FWでセッション待ち
• 非対称ルーティング

が原因のことも多いです。

TTFBとスループットの切り分け方法（実務手順）

① Chrome DevToolsで確認

• Waiting → TTFB
• Content Download → スループット影響

② 判断基準

状態	問題箇所
Waitingが長い	TTFB
Content Downloadが長い	スループット

改善アプローチの違い

TTFB改善策

• DNSキャッシュ導入
• サーバ初期処理最適化
• FW・LB処理見直し

スループット改善策

• WAN帯域増強
• TCPウィンドウ調整
• QoS設定

実務向けまとめ

• TTFB＝「最初の待ち時間」
• スループット＝「流れる速さ」
• 対策は完全に異なる
• DevToolsで数値を見て判断する

この違いを理解しているかどうかで、 トラブル対応の精度が大きく変わります。