Size matters, even on very fast connections - サイズは重要、超高速接続でも

最初の$13\ \mathrm{kB}$でユーザー体験が決まる――高速回線でも無視できない「初期ウィンドウ」の話

要約

TCPの初期送信ウィンドウ（初回ラウンドトリップで届くデータ量）はおよそ$13\ \mathrm{kB}$前後で、これがページ初期表示の速度に直結する。高速回線でも遅延やネットワーク仕様で体感速度が制限される。

この記事を読むべき理由

ウェブやモバイルアプリの初回表示速度は国や回線速度だけで決まらない。日本でもモバイル回線や国際通信の遅延が影響するため、初期ペイロード設計はUX改善に直結する。

詳細解説

• ネットワークは小さな「パケット」単位でやり取りされ、TCPは各パケットに順番を付けACKで受信確認することで信頼性を確保する。
• パケット喪失が起きると再送が発生し、混雑時は再送がさらに混雑を招くため、TCPは「輻輳ウィンドウ（congestion window）」で送信量を制御する。
• 現代の多くの実装で接続開始時のウィンドウは約10パケットに設定されており、実測では1パケットあたりのペイロードが約1368バイトで、初回RTTで受け取れるのはおおよそ$13\ \mathrm{kB}$（環境差あり）。その後のRTTでウィンドウは増え、2回目で合計約$40\ \mathrm{kB}$、3回目で約$92\ \mathrm{kB}$と急増する。
• ただし実測値は経路のMTU、リンク種別、VLANなどで変わる。TLSやHTTPヘッダも初期ペイロードを消費する一方、圧縮による削減も期待できる。

実践ポイント

• 初回表示に必要なリソース（重要CSS・クリティカルJS・最初のHTML）は可能な限り初回$13\ \mathrm{kB}$前後に収める工夫をする。
• クリティカルCSSをインライン化し、非同期ロードや遅延読み込みで残りを後回しにする。
• 画像は低解像度のプレースホルダや遅延読み込みを活用する。
• 圧縮（gzip/ Brotli）とヘッダ最適化で初期転送量を削る。
• 実際の経路での挙動は可視化ツール（例：Wiresharkやブラウザのネットワークタブ）で確認する。
• 日本向けサービスでも、モバイルや国際コンテンツ配信を考えるとこの設計原則は重要。

元記事の示す教訓はシンプル：回線速度が速くても「最初に送れる量」が体感性能を左右する。最初の数十キロバイトをどう設計するかが、ユーザーの印象を大きく変える。