「ページ表示が始まるまでが遅い」「真っ白な時間が長い」 このような症状の多くは TTFB(Time To First Byte) が原因です。
本記事では、実務で即使えるように TTFBが遅くなる原因をレイヤ別(NW / DNS / Server)に切り分け、 具体的な確認方法と改善策を解説します。
目次
TTFBとは何か?
TTFB(Time To First Byte)とは、 リクエスト送信から最初のレスポンスバイトを受信するまでの時間です。
Browser
↓ HTTP Request
[ DNS解決 / Network / Server処理 ]
↓ HTTP Response (First Byte)
Browser
TTFBが遅い= 「通信開始前」または「サーバ処理」で時間を消費していることを意味します。
TTFBが遅い時の代表的な症状
- 画面が真っ白な時間が長い
- リロードすると速くなることがある
- 海外拠点・在宅環境で特に遅い
① Network(NW)が原因の場合
確認方法
ping example.com
tracert example.com
チェックポイント
- RTTが大きい(100ms以上)
- 経路途中で遅延が急増している
- パケットロスが発生している
原因例
- WAN帯域逼迫
- QoS未設定
- FWセッション処理遅延
改善策
- WAN帯域増強
- HTTP/HTTPS通信のQoS優先化
- FWの非対称ルーティング解消
② DNSが原因の場合
確認方法
dig example.com
nslookup example.com
チェックポイント
- Query time が長い(数百ms以上)
- TimeoutやRetryが発生
原因例
- 外部DNS参照遅延
- DNSキャッシュ無効
- DNSサーバ高負荷
改善策
- 内部キャッシュDNS導入
- TTL設計の見直し
- DNS冗長化
③ Server(Web / AP / DB)が原因の場合
確認方法
top
vmstat
iostat
チェックポイント
- CPU使用率が高止まり
- メモリスワップ発生
- ディスクI/O待ち時間増加
原因例
- アプリ初期処理が重い
- DB接続待ち
- コールドスタート
改善策
- アプリ初期化処理の最適化
- DBコネクションプール調整
- APサーバの常駐化
Chrome DevToolsでTTFBを確認する方法
- F12 → Network タブ
- 対象リクエストを選択
- Timing → Waiting (TTFB) を確認
Waiting が長い場合は、 NW / DNS / Server のいずれかに問題があります。
実務向け:原因切り分け早見表
| 状況 | 疑う箇所 |
|---|---|
| 初回だけ遅い | DNS / キャッシュ |
| 常に遅い | NW / Server |
| 海外拠点のみ遅い | WAN / CDN |
| 時間帯依存 | Server負荷 |
まとめ
- TTFBは「表示が遅い」の最重要指標
- NW → DNS → Server の順で切り分け
- DevToolsの数値を根拠に判断する
TTFBを制すれば、 Web表示トラブルの8割は説明できるようになります。
あわせて読みたい


Webサービスが遅い原因を即切り分ける方法【NW / DNS / Server / Browser別チェック手順】
「Webページの表示が遅い」「たまに固まる」「時間帯によって極端に遅くなる」 このような事象は、原因が1箇所とは限りません。 本記事では、実務現場で即使えるように …
あわせて読みたい


TTFBとスループットの違いを完全理解【表示が遅い原因を誤診しないための実務解説】
Webが「遅い」と言われたとき、 TTFB(Time To First Byte) と スループット を混同してしまうと、 原因を誤診し、的外れな対策を打ってしまいます。 本記事では、 TTF…
あわせて読みたい


HTTP/2・HTTP/3は本当に速い?TTFBとスループットに与える影響を仕組みから徹底解説
「HTTP/2にしたら速くなるはず」「HTTP/3なら遅延が消える」 ── 実務では、このような誤解が非常に多く見られます。 HTTP/2・HTTP/3は万能な高速化技術ではありません。…
