HTTP/2・HTTP/3は本当に速い？TTFBとスループットに与える影響を仕組みから徹底解説

URLをコピーしました！

「HTTP/2にしたら速くなるはず」「HTTP/3なら遅延が消える」 ── 実務では、このような誤解が非常に多く見られます。

HTTP/2・HTTP/3は万能な高速化技術ではありません。 TTFBに効くケース／効かないケース、 スループットが改善する条件を理解していないと、導入しても「体感が変わらない」結果になります。

本記事では、

HTTP/1.1・HTTP/2・HTTP/3 の違い
TTFB・スループットにどう影響するのか
実務で効果が出る／出ない判断基準
導入時の落とし穴

をネットワーク視点で徹底解説します。

まず結論：HTTP/2・HTTP/3が効くのは「条件付き」

項目	HTTP/2	HTTP/3
TTFB改善	△（条件付き）	◯（特に高遅延環境）
スループット改善	◯	◯
パケットロス耐性	△	◎

「TTFBが遅い＝HTTP/2にすれば解決」ではありません。

HTTP/1.1が抱える本質的な問題

① コネクション数依存

HTTP/1.1では、ブラウザは複数リソース取得のために 複数TCPコネクションを張ります。

TCPハンドシェイク
TLSハンドシェイク

これがTTFBを押し上げる要因になります。

② Head-of-Line Blocking（HOL）

1つのレスポンスが遅れると、後続リクエストも詰まります。

結果として、

スループットが出ない
体感が悪化

HTTP/2の仕組みとTTFB・スループットへの影響

HTTP/2の核心：多重化（Multiplexing）

HTTP/2では、 1つのTCPコネクション上で複数リクエストを並行処理します。

TCP Connection
 ├─ Stream 1
 ├─ Stream 2
 ├─ Stream 3

TTFBへの影響

TCP/TLS接続回数が減る
→ 初回TTFBは改善する可能性あり

ただし、

DNSが遅い
サーバ初期処理が重い

場合はほぼ効果なしです。

スループットへの影響

HOL Blockingが大幅に軽減
帯域を効率よく使える

→ 多数の画像・JSがあるページでは体感改善しやすい

HTTP/2の限界：TCPという足枷

HTTP/2はTCP上で動作します。

そのため、

TCPレベルのパケットロス
輻輳制御による速度低下

が発生すると、全ストリームが巻き添えになります。

これが次世代の HTTP/3 が生まれた理由です。

HTTP/3の仕組みと革命的な違い

HTTP/3 = QUIC + HTTP

HTTP/3は、

TCPを使わない
UDPベースのQUICを使用

という根本的な違いがあります。

TTFBへの影響

TCPハンドシェイク不要
TLS 1.3を統合

→ 特に高遅延・モバイル環境でTTFBが劇的に改善します。

スループットへの影響

ストリーム単位で独立
一部ロスしても他に影響しない

→ 不安定な回線ほど効果大

実務での判断基準（重要）

HTTP/2が向いているケース

社内LAN
安定したWAN
画像・JSが多いWeb

HTTP/3が真価を発揮するケース

モバイル回線
海外アクセス
パケットロスが発生しやすい環境

導入時の落とし穴（非常に重要）

① FW・プロキシでUDPが遮断される

HTTP/3はUDP/443を使用します。

② 可視化・監視が難しい

従来のTCPキャプチャ手法が使えません。

③ 全クライアントが対応しているわけではない

実務向けまとめ

HTTP/2はスループット改善に強い
HTTP/3はTTFBと不安定回線に強い
TTFBが遅い原因を誤診しないことが最重要
NW・DNS・Serverを理解した上で導入判断する

「速そうだから導入」ではなく、「どこが遅いかを理解して選ぶ」 これが実務で失敗しない最大のポイントです。