15kBのページより14kBのページのほうがはるかに速く読み込まれることがある（2022）

 (endtimes.dev)
2 ポイント 投稿者 GN⁺ 2025-07-20 | 1件のコメント | WhatsAppで共有
  • Webサイトのサイズを14kB以下に保つと、15kBの場合よりも読み込み速度を大幅に短縮できる
  • この現象はTCPスロースタートアルゴリズムによって発生し、最初に送信できるデータ量の上限により体感速度の差が生じる
  • 14kBは、ほとんどのサーバーが最初に送る10個のTCPパケットの容量に相当する
  • 衛星インターネットなどの高レイテンシ環境では、1回の追加往復（RTT）が612ms以上の遅延を引き起こす
  • 実際に14kB未満に主要コンテンツを収める、または最初の14kB以内に重要なリソースを配置することが、Webパフォーマンス最適化に有効である

概要と主要な原理

  • Webサイトは小さいほど速く読み込まれることは広く知られている
  • しかし、14kBから15kBに超えた瞬間に、最初の応答速度で劇的な差が生じるのは意外な事実である
  • 15kBと16kBのページの速度差はわずかだが、14kBと15kBの間には最大612msの差が生じうる

TCPとは何か

  • Transmission Control Protocol (TCP) は IP（Internet Protocol） の上で動作し、パケットの信頼性保証を担う
  • WebブラウザーはHTTPリクエスト時に複数のTCPパケットを送信する
  • IPだけを使う場合、パケットが到着したか確認できないため、TCPが**パケット受信確認（ACK）**機能を提供する
  • サーバーはまず少量のパケットを送り、ブラウザーからACKを受け取ると追加のパケットを送信する
  • ACKがない場合は、パケット再送の手続きが実行される

TCPスロースタートとは

  • TCPスロースタートは、サーバーがネットワーク接続品質（帯域幅）を把握するために段階的にパケット送信量を増やしていくアルゴリズムである
  • 接続初期にサーバーは少量（一般的には10個）のパケットだけを送信する
  • 訪問者のコンピューターが正常にACKを返すと、パケット送信量を2倍に増やす
  • ACKの欠落が発生すると、その後は遅い速度でパケットを送る
  • 実際のアルゴリズムは実装ごとに細部の違いがあるが、概念は同じである

14kB基準の根拠

  • ほとんどのサーバーはスロースタートでTCPパケット10個を一度に送る
  • TCPパケットの最大サイズは1500バイトだが、ヘッダー（40バイト）を除くと1460バイトが実データとなる
  • したがって 10 x 1460 = 14600バイト（約14kB） が最初の送信上限となる
  • Webサイトまたは重要なリソースを14kB以下（圧縮適用時は元データで数十kB規模）に収めれば、開始時の往復遅延なしで表示できる

1回の往復がどれほど大きな遅延を引き起こすか

衛星インターネットの例

  • 高レイテンシ環境の代表例として、衛星インターネット（石油掘削船、クルーズ船など）の利用者がいる
  • 携帯電話からホームページをリクエストすると、ルーター → 衛星アンテナ → 宇宙衛星 → 地上局 → サーバーと移動し、各区間で数十〜数百msを要する
  • 全体の伝送往復には、2回の宇宙往復、ネットワーク区間の移動、サーバー処理まで含めて約612msの追加遅延が発生する
  • HTTPSを使う場合、追加のハンドシェイクにより1836msまで増えることがある

地上ネットワークのレイテンシ

  • 2G、3Gなどのモバイルネットワークでも100〜1000msのレイテンシが発生する
  • 混雑時やサーバー過負荷、パケット損失など、さまざまな環境で追加遅延が発生しうる

14kBルールを適用したWebサイト最適化戦略

  • Webサイトやページをできるだけ小さくすることが重要である
  • 各ページの圧縮後の転送量が14kB以下になるよう設計するのが理想的である
    • 圧縮適用時には実コンテンツを約50kBまで含められる
  • 自動再生動画、ポップアップ、トラッカー、不要なJS/CSSなど、ほとんどの不要要素を減らせば十分達成可能である
  • もし14kBで全体を実装するのが難しいなら、最初の14kBに中核リソースと主要コンテンツ（CSS、JS、主要テキストなど）を優先配置することが重要である
  • HTTPヘッダー（圧縮不可）、画像（必要最小限だけ／表示位置のみ読み込む、またはプレースホルダー適用）も14kB内に含まれる

14kBルールの例外と最新プロトコルの論点

  • 14kBルールは極端な一般化ではないが、いくつかの例外がある
    • 一部のサーバーは初期ウィンドウを30パケットに拡張している
    • TLSハンドシェイクにより、より大きなウィンドウが許可される可能性がある
    • ルートごとに送信可能なパケット数をキャッシュし、次回接続時により多く送れることがある
  • HTTP/2でも、サーバーがTCPスロースタートで10パケットから始める慣行は概ね変わらない
  • HTTP/3、QUICでも14kBルールは公式に推奨されている

要約と参考資料

  • 技術的根拠と追加説明資料は各リンクから確認できる
  • 初回公開: 2022-08-25、最終更新: 2022-08-26、著者: Nathaniel、関連タグ: Webパフォーマンス、HTTP、TCP

参考リンク

  • EthernetフレームとTCPヘッダー構造、レイテンシおよび帯域幅に関する追加資料、TCP/QUIC仕様など

関連記事

1件のコメント

 
GN⁺ 2025-07-20
Hacker Newsの意見

  • ソフトウェア開発者はメディア層にもう少し関心を持つべきだと思う。特に、3G/5Gの信頼性と遅延について著者が指摘している点が印象的だった。無線ではほぼ常に再送が起きるし、ほとんどのHTTP通信ではパケットが順番どおりに到着しないとUIが更新されない。実際、単一のRESTリクエストであっても、リクエストとレスポンスが1400バイト未満のときにだけ本当に1パケットで処理される。それを超えると「単一」のリクエストも実際には複数のパケットに分割される。このうちどれか1つでも問題があると、すべてのパケットが順番どおりに到着しなければ画面は正しく更新されない。試してみたければ、Chrome開発者ツールで3Gモードとパケット損失を有効にしてテストすれば、小さな最適化ひとつでもUIの応答性が大きく改善するのが分かる。だからAPIとUIをできるだけ小さくするのには十分な説得力がある

  • 自分のホームページの転送量は圧縮後で7.0kB

    • /
    • main.css
    • favicon.png
    • 合計 7.0kB ブログ一覧とサイト全体は、自作の静的サイトジェネレーター（公開: site.lisp、Common Lisp製）で作っている。数学関連の投稿ではKaTeXをクライアントレンダリングで使っているが、この場合は347.5kBも追加される
    • katex.min.css 23.6kB
    • katex.min.js 277.0kB
    • auto-render.min.js 3.7kB
    • KaTeX_Main-Regular.woff2 26.5kB
    • KaTeX_Main-Italic.woff2 16.7kB
    • 追加合計 347.5kB いつかKaTeXをサーバーレンダリングに変えるべきか考えている。このブログは大学の寮にいた頃から続けている自分だけの情熱プロジェクトだ。HTMLもテンプレートもCSSもすべて自分で書いていて、各ページに本当に必要な要素だけを入れるよう常に慎重に構成しているので、小さなサイズを維持できている
    • 自分のホームページ
    • 数学ポスト一覧
      • だからといって、より良い方法を使うなと言いたいわけではないが、LaTeX表現のような動的コンポーネントがロードされる際にクライアントレンダリングで発生する遅延は、一般ユーザーにはほとんど（あるいはまったく）知覚されない。過度な最適化も問題だ。こうしたSEO起点のパフォーマンス追求は、何百万ビューものトラフィックがあるサービスでない限り、費やした時間に対する見返りがあまり大きくない。無人ボートを海上で潮流で操縦しているのに空力まで心配するようなものだ。限られたリソースの中で総コストと便益を考えると、最適化が常に最善の選択とは限らない
      • 数学コンテンツが少ないのにKaTeXを使うなら、代替としてMathML（mathml-core）を検討してみるのもよい
      • 数式やLaTeX表現をわざわざクライアント側のjsでレンダリングする理由が理解できない。なぜあらかじめHTML/CSSに変換して、事前レンダリング済みの状態で入れないのか疑問だ
      • 重いライブラリは初期ページレンダリング後に読み込むか、ビューポートに見えたときだけSVGで数式グラフィックを読み込むのもアイデアだと思う

  • 14kB目標はやや挑戦的だが、初期10パケット以内に制限するという考え方は面白い。自分のようにWebサイトのサイズに注目するプロジェクトとして 512kb.club がある。サイトサイズをゴルフスコアのように比較する場所だ。自分のサイト（anderegg.ca）は登録前に全リソース合計71kBだった。このプロジェクトのおかげで Cloudflare Radar も知ったが、サイト分析やページサイズ測定に良いツールがある。主目的はインターネット全体のダッシュボードだが、ページサイズ分析ツールも含まれている

    • ユーザーとして聞きたいのだが、残りの500kBは何のために使うのか？ 自分は90%がテキストだけで十分で、残りもベクターグラフィックで足りる。14kBだけでもテキストとグラフィックはかなり入るのに、残りの500は何に使うんだ？
    • 512kbは現実的な基準だ。自分も自分のWebサイトにこの基準を適用している。14kb級のWebサイトは、もうWebの基準を超えてしまっている
    • 個人Webサイトなら512kbは十分達成可能だ。自分の次の目標は99kb（100kb以内）。週末を何回か使えば無理なくいける。自分のサイトは512kbでOrange等級だ

  • これをもう少し面白く実験したいなら、初期ウィンドウ（IW）サイズはサーバー側で設定できる。たとえば次のように変更可能だ

    • ip route change default via <gw> dev <if> initcwnd 20 initrwnd 20 調べると、最近ではCDNが初期ウィンドウを30パケット（45kb）まで与える場合もあるらしい
    • 13年前は10パケットでも「チート」と見なされていた。関連情報は こちら と Ben Strongのブログ（アーカイブ） を参照
    • CDNの初期ウィンドウが30パケットだという根拠資料はあるのだろうか
    • ただの「悪い市民」のように1000パケットに設定することもできる……ただし欠点として、誰かがダイヤルアップやbufferbloatのある接続を使っているとボトルネックになるかもしれない

  • 以下の記事で説明されている内容も当てはまる: Cloudflareブログ - ロシアのISPが16KBまでしか許可せず、ほとんどのWebブラウジングが不可能になった現象。Cloudflareの分析によれば、ロシアのISPは国内ユーザーへのインターネットスロットリングによって、Webアセットごとに最初の16KBまでしか読み込めないよう制限している

  • TCP Slow Startが何かを知らない人と、Webサイトの読み込み遅延を細かいところまで気にするほど関心のある人の交差はごく小さい。スタートアップはまずスタートアップに集中すべきで、こういう最適化に執着できる余裕があるのは大企業だけだ

    • 「重要なことから集中するから、性能最適化まで気を回す暇がない」という発想でいくと、永遠に気にしないままになる。だから今の大半のアプリやサイトは遅くてひどい
    • もしそれが本当なら、Microsoftのような会社のソフトウェアは常に完璧で最高効率で動いていなければならない
    • 概念的には正しい気がする。だが、FigmaのEvan Wallaceが性能に執着していなかったら、Figmaは今の姿にはなっていなかったはずだ。ときには「性能」そのものが製品の主要機能になることもある
    • これは選択の問題ではなく、単にデフォルトで付いてくるようにもできる。自分は10億セルやチェックボックスのデモ[1]もすべてdatastarを使っていて、やっと10kbを少し超える程度だ。モバイルネットワークや3Gでは差が大きい。自分の実験では、14kbを超えると品質の低い接続ではさらに3秒かかった。datastarのメンテナーがTCP slow startまで面倒を見てくれているおかげで、こちらが努力しなくても副次的な恩恵を受けられた
    • 企業規模が性能最適化と大きく関係しているとは思わない。むしろ大企業のほうが遅いことが多い

  • 自分のホームページは17.2KBだ！（依存関係を除く） 個人ページとして本気で最適化して、Lighthouse満点100も達成した。以前は不可能だと思っていたが成功した。ちなみにRailsで作った。こういう最適化は実際やる価値がある。もたつき感なく稲妻のように表示されるページ体験は、それ自体がとても満足感が高い

    • news.ycombinator.com が即座に読み込まれるのを体験すると、心理的にもすごく快適で、休み時間ごとに自動的に開いてしまう
    • 何千ものサイト向けテンプレートコードを徹底的に最適化して、Lighthouse 100/100/100/100を出した。モバイルでも完璧な100。初期ロードは17.2kBよりずっと大きく120kBほどあるが、秘訣は不要なHTTPリクエストをすべてなくし、「above-the-fold」領域だけでJSを実行し、残りはlazy evalやdeferなどで可能な限り遅延ロードすること。JS/CSSはインライン化し、サードパーティウィジェットもポップアップアイコンなどの「ファサード」方式で実際のリクエストを後ろに回す。SSRバックエンドの恩恵も大きい。Vimeoの背景動画付きでも100点だったが、YouTubeでは不可能だった。満点を出す方法は、Lighthouseの結果を解釈してコードベース自体を完全に書き直すことだった。そのおかげで速度関連のクライアントクレームは完全になくなり、SEOや実際のスコアそのものでも大きな競争力になっている
    • Railsはレンダリング最適化と直接の関係はない。完璧なLighthouseスコア、おめでとう

  • この文章には論理的な弱点が2つあると思う

    1. 衛星通信ではパケット1つ送るのに約1600msかかるという式があるが、14kbルールの根拠としては弱い。大きなWebサイトとの比較がないので、10パケット ≠ 16秒であることを示せていない
    2. Webページの画像も14kbルールに含めるとしているが、画像が初回ロードでインライン化されるケースがどれほどあるのか？ 実際にはかなりまれな例外で、99.9%には当てはまらない点をもっと明確に言うべきだ - 「<i>画像がインライン化されるケース？</i>」という話なら、典型例として初期画面にだけ出る低解像度サムネイルにCSS blurを加え、本物の画像は後から非同期でフェードインする手法がある。うまくやれば追加消費は1〜200バイト程度しか発生しない。自分のブログにも適用しているし、WordpressやMediumのようなプラットフォームでも広く採用されている。主に商用フロントエンドのハイパー最適化向けのテクニックだ - ユーザーの大半が低遅延の衛星接続を使っているかのように想定している点にも、そして現実にはどのWebサイトも数MB単位なのに自分のページだけが耐えられないという前提にも同意できない

  • 最近の世代は、単純な静的WebサイトですらNext.jsのようなフレームワークで作る傾向がある。HTML+CSS+jsの時代が終わっていくようで残念だ

    • 同意する。自分も最小リソース・JavaScript手動最適化・14kbルールのサイトを全部やってみたが、この方式は設計やアーキテクチャの制約につながる。機能が増えると、そのときの「最小化」の判断が全部技術的負債になる。多くの人は「フレームワークなしの純粋なWeb」に幻想を抱くが、ある時点でそれがかえって苦行になる。でもアイソモーフィックJSフレームワークを使えば、まず静的ページとして始めて、適度に最適化しつつ、必要になればthick client JSへ移行できる
    • すでにトレンドはまた動き始めている。最近のフレームワークの大半は静的サイトもきちんとサポートしている。Astroのようなものは、そもそも静的サイト向けに生まれた
    • 今さら気づいたのかという感じだが、実際にはjQueryの人気が急上昇していた2010年より前からずっとそうだった
    • Next.jsはバンドルコードをかなり強力に最適化していて、Lambdaや小さなサーバーの立ち上げに最適だ。Nextで作った静的サイトもバンドルをかなり小さくできる

  • 遅延だけでなく、資源消費の最小化は持続可能な未来に不可欠な条件だ。ネットワークが環境に与える影響も決して小さくない。コメント欄の空気がやや皮肉っぽいのは残念だ。この最適化が究極の解決策である時代ではないとしても、エネルギー使用量削減の効果がもっと強調されてもよいと思う

    • インターネットトラフィックの大半は動画ストリーミングだ。Webページで数MB最適化したところでほとんど目立たない。効率性自体を議論する必要はあるが、あらゆる領域で最適化に取り組むことが、本当に最適化が必要な分野への資源を消耗させる可能性もある
    • これは落ちている果実ですらない。Webページで1〜2mWh節約しようと最適化している間に、検索エンジンのクエリ1回で100倍、チャットボット1回で1万倍も使う。キャッシュやlazy loadingでかなり緩和されてもいる
    • ページサイズ削減に気を遣うのは、ほとんど無意味な行為だ。年間のWebブラウジングで使う電力量を安全側に10倍で見積もっても、ハンバーガー1個を作るエネルギーよりずっと少ない。むしろ開発者が1週間最適化する代わりにサラダを1食食べるほうが環境への影響は大きい
    • 完全に同意する。以前BBCに行って、小さなテキスト記事1本でキャッシュに120MBも保存されるのを見て衝撃を受けた。無駄に多くのエネルギーと浪費文化を助長している。自分のWebサイトもできるだけミニマルにしているし、YouTubeへのアップロードも4Kではなく1080Pだけにしている。4Kや8Kは、わざわざ存在する必要がない。人々は太陽光を何MW追加するかという話ばかりするが、実際には「より少なく生産する」努力がどれだけ有効かを想像してみるべきだ。56Kモデム時代の小さなWebの規模が懐かしいし、どこかに中間点があったはずなのに、今ははるかに行き過ぎてしまった
    • 人々が気にするようになるのは、結局のところ自分に直接影響が及び始めたときだ。自分も環境を考えるほうだ。AIのほうがもっと悪いという反論もあるが、実際にはAIもこうした重いページをクロールしている。そして14kb基準は、モバイルの平均ページペイロードの1%にも満たない