ハクソク

世界を動かす技術を、日本語で。

14kbのページは15kbのページよりもはるかに速く読み込むことができる (2022)

2025年7月19日原文(endtimes.dev)

概要

  • 小さなWebページ は 高速表示 が可能
  • TCP slow start アルゴリズムが 14kBの壁 を生む
  • 最初の14kB に重要情報を詰めることが 体感速度向上 の鍵
  • 高遅延環境 では 1ラウンドトリップの遅延 が大きな影響
  • 14kBルール は目安であり、 例外や進化 も存在

TCP slow startと14kBルールの仕組み

  • Webページの容量 が小さいほど 表示速度 が向上
  • 14kBページ は 15kBページ よりも 最大612ms高速 な場合がある
  • 15kBと16kB の差は ほぼ無視できるレベル
  • この現象の背景には TCP slow start アルゴリズムの存在
  • TCP は IP を拡張し、 信頼性の高いデータ転送 を実現
  • HTTP通信 は複数の TCPパケット で構成
  • IP単体 では パケット到達確認機能 がない
  • TCP は 到達確認（ACK） により 再送制御 を行う

TCP slow startの動作原理

  • サーバー は 接続直後 にどれだけデータを送れるか 未知
  • 初期送信量 は通常 10 TCPパケット
  • パケットサイズ は 最大1500バイト （Ethernet標準）
  • ヘッダー で 40バイト 消費、 実データ1460バイト
  • 10パケット で 14600バイト（約14kB）
  • 14kB以内 なら 1ラウンドトリップ で全データ送信可能
  • 14kBを超えると 追加ラウンドトリップ が必要

遅延（レイテンシ）の影響

  • ラウンドトリップ遅延 は ユーザー体感速度 に直結
  • 衛星インターネット では 1往復612ms 以上かかる場合も
  • HTTPS は 追加で2往復 必要、 合計1836ms の遅延
  • 2G/3G回線・混雑時・不安定なネット ではさらに遅延増大
  • パケットロス が起きると 再送で更なる遅延

14kBルールの活用方法

  • ページ全体 を 14kB以内 に収めるのが理想
  • 圧縮後14kB なので、 非圧縮で約50kB まで可能
  • 重要コンテンツ （CSS/JS/テキスト）を 最初の14kB に配置
  • HTTPヘッダー も 14kBに含まれる ため注意
  • 画像は極小化 または プレースホルダー 利用推奨

14kBルールの例外と進化

  • 初期ウィンドウ が 30パケット に拡張されているサーバーも存在
  • TLSハンドシェイク で ウィンドウ拡大 が可能な場合あり
  • サーバーが経路情報をキャッシュ し、再接続時に多く送信可能なケース
  • HTTP/2 でも 基本的に14kBルールは有効
  • HTTP/3/QUIC も 14kBルールを推奨

実践的な最適化ポイント

  • 自動再生動画・ポップアップ・トラッキングスクリプト等 は削除
  • 必要最小限のCSS/JS のみを 最初に読み込む設計
  • ファーストビュー （above the fold）に必要な画像のみ読み込み
  • 14kBルール は 絶対ではなく目安 と認識

参考資料

  • High performance browser networking by Ilya Grigorik
  • Increase HTTP Performance by Fitting In the Initial TCP Slow Start Window by Simon Hørup Eskildsen
  • Critical Resources and the First 14 KB - A Review
  • HTTP3 performance improvements
  • 著者：Nathaniel, 公開日：2022年8月25日, 最終更新：2022年8月26日

Hackerたちの意見

TCPスロースタートが何か知らない人と、ウェブサイトの読み込みが数ミリ秒早くなることを気にするべき人の重なりは、めちゃくちゃ少ないよね。スタートアップは、パフォーマンスよりもまずは立ち上げに集中すべきだし、大企業ならそのレベルのスピード最適化をするための経験豊富なSREチームがいるはずだよ。

└

大企業ならそのレベルのスピード最適化をするための経験豊富なSREチームがいるはずだよ。ああ、そうだったらいいのに。最近、大企業が開発したアプリケーション見たことある？ :)

└

そうだね。それが、例えばMicrosoftのソフトウェアが完璧に動いて、最高の効率で動作する理由だよ。

└

同意するよ、そういう風に説明すべきだと思う。でも、Evan WallaceがFigmaを作るときにパフォーマンスにこだわらなかったら、今のFigmaにはなってなかっただろうね。時には、パフォーマンスが機能の一部なんだ。

└

企業の規模がパフォーマンスや最適化にどう関係あるのか、全然わからない。大きなビジネスがオンラインで何かを迅速に実行してるのをほとんど見たことないよ。

└

パフォーマンスが重要じゃないって考え方、ほんとイライラする。これがDockerやKubernetes、そして何でも壊す絶対的なスロップスタックを生んだ原因だよ。パフォーマンスは大事だよ。私たちは数十年にわたってKnuthの最適化に関する名言を誤解して、ハードウェアのパフォーマンス向上を5〜6桁も無駄にして、未だに遅くて膨れ上がった欠陥のあるソフトウェアを提供してる。パフォーマンスは実際に重要で、他の条件が同じなら、速い製品の方が遅いのよりも快適だよ。幸いなことに、Figmaの人たちみたいにリスクを取って証明してくれた人たちもいる。たとえ難しい技術的な問題で革新しているとしても（ほとんどの人はそうじゃないけど）、パフォーマンスはやっぱり重要なんだ。

└

「もっと重要なことに集中してるから気にしない」ってアプローチだと、結局何も気にしなくなるよ。ページロードを最適化してサーバーにアクセスするためのTCPウィンドウサイズに合わせるよりも、会社にとってもっと重要なことは必ずあるからね。だから、最近のほとんどのアプリやウェブサイトは遅くてひどいんだよ。

それに、.exeファイルは無駄が多いって知ってるよね？ .comファイルは、実行可能ファイルのサイズを0xFF00h未満に抑えられれば、かなりバイト数を節約できるんだよ（ああ、俺も歳を取ったな）。

└

それに、a.outフォーマットはelfよりもディスクスペースを節約することが多いけど、実行ファイル間でコードが重複するんだよね。

これを楽しみたいなら、初期ウィンドウ（IW）は送信者によって決まるんだ。だから、サーバーをウェブサイトに合ったパケット数に設定できるよ。こんな感じになると思う：ip route change default via dev initcwnd 20 initrwnd 20。ウェブ検索によると、CDNは今や初期ウィンドウで30パケットになってるから、そこで45kb得られるよ。

└

悪い市民になって、パケットを1000に設定しちゃえばいいんじゃない？ダイヤルアップ接続の人が詰まる可能性があるくらいで、特にデメリットはないよ。

└

ウェブ検索によると、CDNは初期ウィンドウで30パケットになってるから、そこで45kb得られるみたい。これについての参考はある？

Hacker Newsで議論の続きを見る