クリックして、すぐに ページが 出ると、「はやい」と 思います。まつ じかんには、3つの めやすが あります。0.1びょうは「すぐ」。1びょうは「かんがえが とぎれない」。10びょうを こえると、気もちが ほかへ いきやすく なります［1］。

この めやすは、1968ねんの けんきゅうが もとに なっています［1］。

この 1びょうぐらいの あいだに、パソコンと あいての コンピュータは、なにを して いるのでしょう。まず、どうしても はやく できない ものから 見ましょう。

ページが出るまで、何秒なら待てるのでしょうか。ヤコブ・ニールセンは1993年に、3つの目安を挙げました。0.1秒は「すぐに反応した」と感じる限界、1秒は「考えの流れが途切れない」限界、10秒は「画面に注意を向け続けられる」限界です［1］。

この目安のもとは、1968年と1991年の研究です［1］。

いまのウェブでは、ページでいちばん大きな部分（大きな画像や文字のかたまり）が見えるまでの時間が、目安の一つです。ページを開いた回数のうち4分の3で、2.5秒以内に見えれば「良い」とされます［2］。

この1秒から数秒を「通信に使える持ち時間」と考えて、何に使われるのかを順に見ていきます。まず、どうしても縮められないものから。

待たされていると人が感じる時間には、目安がある。ヤコブ・ニールセンは1993年に、応答時間の限界を3つ挙げた。0.1秒は、システムがすぐ反応したと感じられる限界。1秒は、考えの流れが途切れない限界。10秒は、画面に注意を向け続けられる限界だ［1］。

この助言は30年前からほぼ同じだ、とニールセンは書き、根拠に1968年のミラーと1991年のカードらの研究を挙げている［1］。

いまのウェブでは、ページ内でいちばん大きな画像や文字のかたまりが見えるまでの時間（LCP）が、指標の一つだ。ページの読み込みの75％で2.5秒以内に収まることが「良い」の目安とされる［2］。

以下では、この1秒から数秒を「通信に使える予算」と見て、使いみちを順にたどる。最初に、どうしても減らせない項目から。

やまに むかって「やっほー」と いうと、こえが もどるまで、とおい やまほど まちます。ただし ほんとうは、やまびこは おとが はねかえる だけです。ネットでは、あいての コンピュータが うけとって、へんじを つくって おくります。

ひかりは、ケーブルの なかを 1びょうに 20まんキロメートルぐらい すすみます［3］。それでも、とうきょうから アメリカの ロサンゼルスまで いって もどるのに、88ミリびょう（0.088びょう）ぐらい かかります。ひかりが すすむ じかんだけでも、さっきの 0.1びょうに ちかい ながさです。

とうきょうと おおさかなら、4ミリびょうぐらい。うみの むこうは、20ばい いじょうです。ページを 見るまでに、この「いって もどる」は、なんかい いるのでしょう。

光ファイバーの中を進む光でも、距離のぶんだけ時間がかかります。光は真空中で秒速約30万km。ガラスの中では、屈折率（約1.5）のぶんだけ遅くなります［3］。ざっくり割ると、光ファイバーの中の光は、秒速約20万kmです。

東京からロサンゼルスまでの直線距離は約8,800kmです。秒速20万kmなら、片道で約44ミリ秒、往復で約88ミリ秒。この「行って帰る」時間を、RTT（ラウンドトリップ・タイム）といいます。光が進むだけの理論上の下限でも、さきほどの0.1秒の目安に近い値です。

たとえるなら山びこです。山に向かって「やっほー」と叫ぶと、山が遠いほど、返事が戻るまで待ちます。ただし本当は、山びこは音がはね返るだけです。通信では、相手のコンピュータが受け取って、返事を作って送り返します。

88ミリ秒は、ケーブルが直線で、機器の処理時間がゼロの場合の下限です。実際の海底ケーブルは直線ではないので、もっとかかります。海底ケーブルについては、別のメモで書きました。同じ計算で、東京と大阪（約400km）は往復約4ミリ秒。海の向こうは、国内の20倍以上です。

ページを見るまでに、この往復は何回いるのでしょうか。

光ファイバーの中を進む光でも、距離のぶんだけ時間がかかる。光の速さは、真空中で秒速約30万km。物質の中では、真空中の速さを屈折率で割った速さになり、ガラスの屈折率は約1.5だ［3］。単純に割ると、光ファイバーの中の光は秒速約20万kmになる。

東京とロサンゼルスの直線距離は、緯度・経度から求めて約8,800km。これを秒速20万kmで進むと、片道で約44ミリ秒、往復で約88ミリ秒になる。この往復にかかる時間をRTT（ラウンドトリップ・タイム）という。光が進むだけの理論上の下限でも、前章の0.1秒の目安に近い。

88ミリ秒は、ケーブルが直線で、機器の処理時間がゼロの場合の下限だ。実際の海底ケーブルは、直線ではなく、もっと長い道のりを通る（海底ケーブルのメモ）。同じ計算で、東京と大阪（約400km）なら往復約4ミリ秒。海の向こうは、国内の20倍以上の「往復の値段」になる。

以降は、この往復＝RTTを単位にして数える。ページを1枚出すのに、往復は何回いるのか。

ブラウザに なまえを うつと、まず、あいての ばんごうを しらべます（DNS）。インターネットの メモにも かきました。しらべた こたえは、ちかくの コンピュータが おぼえて おきます［4］。

にかいめからは、とおくまで いかずに、ちかくの おぼえて いる こたえで すむ ことが あります。ともだちの いえの ばしょを、いちど しらべたら てちょうに かいて おくのと にています。ただし ほんとうは、こたえには おぼえて おく じかんが きまって いて、すぎると すてられます。

ブラウザーにURLを打つと、まず必要なのは、相手の番号（IPアドレス）です。名前から番号を調べる仕組みがDNSで、インターネットのメモにも書きました。

何も保存されていなければ、問い合わせは、ルートサーバー、.jpや.comのような末尾を担当するサーバー、そのドメインを担当するサーバーの順にたどります［4］。1回ごとに往復がいります。

そこで、答えは保存されます。パソコンやキャッシュサーバーは、問い合わせの結果を、決められた時間（TTL）のあいだ保存して、使い回します。時間が過ぎたら捨てます［4］。一度調べた友だちの家の場所を、手帳に書いておくのと似ています。ただし本当は、手帳と違って、書いておく時間が決まっています。

同じ名前を2回目に引くときは、遠くまで行かず、近くの保存で答えられることがあります。最初の一歩は、保存があるかどうかで、往復がほぼ要らない場合から、何度も要る場合まで変わります。次は、番号が分かった相手に、最初の一言を届ける段階です。

ブラウザーにURLを打つと、まず必要なのが、相手の番号（IPアドレス）だ。名前から番号を調べる仕組みがDNSで、詳しくはインターネットのメモで書いた。

保存が何もなければ、問い合わせは、ルートサーバー、TLD（.jpや.comなどの末尾）を担当するサーバー、そのドメインを担当する権威サーバーへと、順にたどる［4］。1回ごとに往復が要る。

そこで、答えは保存される。パソコンやキャッシュサーバー（リゾルバー）は、問い合わせの結果を、レコードごとに決められたTTLの間、保存して再利用する。TTLが切れたら破棄する［4］。同じ名前を2回目に引くときは、遠くの権威サーバーまで行かず、近くの保存分で答えられることがある。

この最初の一歩は、保存があるかどうかで、往復がほぼ要らない場合から、複数回要る場合まで変わる。次は、番号が分かった相手に、最初の一言を届ける段階だ。

でんわの「もしもし」「はい」に にた あいさつ（TCP）で、1かい。つぎに、ほかの 人に よまれない ための あんごうの やくそく（TLS）で、1かい［6］。そして「ページを ください」（HTTP）で、また 1かい。あわせて 3かいです。

ただし ほんとうは、あいさつの なかみは、おたがいの ばんごうを そろえる しごとです［5］。

アメリカの ロサンゼルスの あいてなら、1かいが 0.088びょうなので、3かいで 0.26びょうぐらい。ページの なかみは、まだ ひとつも とどいて いません。では、なかみは、どう あつまるのでしょう。

番号が分かったら、相手との接続を作ります。まず、電話の「もしもし」「はい」のようなあいさつ（TCP）で、1往復。ただし本当は、あいさつの中身は、お互いに使う番号をそろえる作業です［5］。

次に、httpsのページでは、暗号の方式や鍵を決めます（TLS）。TLS 1.2までは2往復かかりました。2018年のTLS 1.3で、新しい接続の取り決めは1往復になりました［6］［7］。

ここまで済んで、やっと「このページをください」という要求（HTTP）を送ります。返事の最初の1バイトが戻るまで、さらに1往復です。東京からロサンゼルスの相手に、初めてつなぐときの内訳は、次のとおりです。

最初の1バイトが着くまでに、約0.26秒。1秒の持ち時間の4分の1あまりが、ページの中身が1つも届かないうちに、往復だけで消えます。TLS 1.2なら、1往復増えます。DNSの問い合わせと機器の処理時間は含んでいません。では、最初の1バイトが届いたあと、ページの中身はどう集まるのでしょうか。

番号が分かったら、相手と接続を作る。TCPは、SYN、SYN-ACK、ACKという3つのメッセージのやりとりで、双方が使う番号をそろえてから通信を始める［5］。こちらは、SYN-ACKが戻るまで、先へ進めない。ここで1往復。

httpsのページでは、続いてTLSで、暗号の方式と鍵を取り決める。TLS 1.2までは、データを送れるようになるまでに2往復かかった。2018年8月のTLS 1.3（RFC 8446）で、新しい接続の取り決めは1往復になった［6］［7］。

暗号が整って、ようやくHTTPの要求を送る。返事の最初の1バイトが戻るまで、さらに1往復かかる。東京からロサンゼルスの相手に、初めてつなぐときの内訳を、下限の計算で並べる。

最初の1バイトが着くまでに、光の速さのままでも約0.26秒。1秒の予算の4分の1あまりが、まだ中身のない往復だけで消える。TLS 1.2なら、さらに1往復増える。DNSの問い合わせと機器の処理時間は含まない、直線距離での下限だ。最初の1バイトのあとで、ページの中身はどう集まるのか。

さいしょに とどくのは、もくじのような ファイル（HTML）です。その なかに「がぞうを ください」「もじの かたちを ください」と、ほかの ファイルの ことが かいて あります。

1まいの ページで、ファイルは 70ぐらい、と いわれます［8］。1ぽんの みちに まとめて はこぶ ほうほう（HTTP/2）も できました［9］。それでも、いって もどる かずは、まだ へらせるのでしょうか。

最初に返ってくるのは、たいてい1つのHTMLファイルです。その中に、見た目を決めるCSS、動きをつけるJavaScript、画像、文字のデザイン（フォント）など、別のファイルのことが書かれています。ブラウザーは、HTMLを読みながら、それらを追加で要求します。

HTTP Archiveの調査では、2025年7月のデータで、1ページのリクエスト数の中央値は、パソコンで77、スマートフォンで72でした。いちばん多いのは、JavaScriptのファイルです［8］。

HTTP/1.1では、同時にたくさん取るために、サーバーへの接続を複数作りました［9］。新しい接続を作るたびに、前の章のあいさつがいります（つないだ接続を使い回せる場合もあります）。2022年のHTTP/2（RFC 9113）は、1つの接続の上で、複数のやりとりを同時に行えるようにしました［9］。

順番の壁もあります。HTMLが届かないと、どのファイルが必要かも分かりません。ブラウザーには、HTMLを読む本体とは別に、先に見つけて要求する仕組み（プリロードスキャナー）があります［10］。それでも、数十の要求は、往復の壁にぶつかります。この待ちを、どう減らしているのでしょうか。

最初に返ってくるのは、たいてい1つのHTMLファイルだ。その中に、スタイルシート（CSS）、JavaScript、画像、フォントなど、別のファイルへの参照が書かれている。ブラウザーは、HTMLを読みながら、それらを追加で要求する。

HTTP Archiveの調査によると、2025年7月のデータで、1ページのリクエスト数の中央値は、デスクトップで77、モバイルで72だった。いちばん多いのはJavaScriptのファイルだ［8］。

HTTP/1.1では、同時にたくさん取るために、サーバーへの接続を複数作ってきた［9］。新しい接続を作るたびに、前章のあいさつが要る（つないだ接続を使い回せる場合もある）。2022年のHTTP/2（RFC 9113）は、1つの接続の上で、複数のやりとりを同時に行えるようにした［9］。

順番の壁もある。HTMLが届かないと、どのファイルが必要かも分からない。ブラウザーには、HTMLを読む本体とは別に、先に見つけて要求する仕組み（プリロードスキャナー）がある［10］。それでも、数十の要求は往復の壁にぶつかる。この待ちを、どう減らしてきたのか。

ひかりの はやさは かえられません。だから、いって もどる かずを へらします。あいさつを ひとつに まとめたり［6］［12］、おなじ ものの コピーを ちかくの コンピュータに おいたり します［15］。

ロサンゼルスまで いかずに、とうきょうに コピーが あれば、いって もどるのは 4ミリびょうぐらいの はなしに なります。でも、とどいても、まだ えには なりません。ブラウザは、どう するのでしょう。

光の速さは変えられません。そこで、往復の回数と、1回の往復の距離を減らす工夫が重ねられてきました。

回数を減らす工夫の1つが、TLS 1.3です。新しい接続の取り決めを、2往復から1往復にしました。前に一度つないだ相手には、0-RTTという方法で、最初のメッセージと一緒に暗号化したデータを送れます。ただし、途中で捕まえられた最初のデータが、もう一度実行されても防げない、という弱さがあり、規格はこれを性能との引き換えとして書いています［6］［7］。

QUICは、TCPのあいさつに当たる接続の確立と、TLS 1.3の取り決めを一体にして、接続の確立を速くします［12］。Googleが2013年に実験として始めたもので［13］、2021年にIETFがRFC 9000として標準にしました［11］。TCPの上ではなく、UDPの上に作られています。既存の機器やネットワークに広げやすくするため、と規格には書かれています［11］。新しい仕組みを広げる難しさは、IPv6のメモにも出てきました。

HTTP/3（RFC 9114、2022年）は、HTTPをQUICの上で動かします。HTTP/2はTCPの1本の接続を使うので、パケットが1つ失われると、関係のないやりとりまで止まります。QUICは、やりとりごとに別々に扱えるので、その止まりを避けやすくなります［14］。

もう1つは、距離を縮める工夫です。CDNは、同じ内容のコピーを世界のあちこちのサーバーに置き、利用者に近いサーバーが答える仕組みです。距離が遠いほど、そのぶん遅延が大きくなるので、近くのサーバーが答えれば、往復は安くなります［15］。東京や大阪にコピーがあれば、往復は、2章の計算で数ミリ秒台です。でも、届いただけでは、まだ画面は絵になりません。ブラウザーは、届いたものをどう組み立てるのでしょうか。

光の速さは変えられない。そこで、往復の回数と、1回の往復の距離を減らす工夫が重ねられてきた。

回数を減らす工夫の1つが、TLS 1.3（RFC 8446、2018年8月）だ。新しい接続の取り決めを、2往復から1往復にした。すでに一度つないだ相手には、0-RTTという方法で、最初のメッセージと一緒に暗号化したデータを送れる。ただし、攻撃者に捕捉された0-RTTのデータが再実行される（再送攻撃）ことへの保証がない、という弱さがあり、規格はこれを性能との引き換えとして書いている［6］［7］。標準になるまでには、2013年の提案から数年の議論があった［7］。

QUICは、TCPの3ウェイハンドシェイクに当たる接続の確立と、TLS 1.3の取り決めを一体にして、接続の確立を速くする［12］。Googleが2013年に実験として始め［13］、2021年にIETFがRFC 9000として標準にした［11］。TCPではなくUDPの上に作られたのは、既存の機器やネットワークに展開しやすくするため、と規格に書かれている［11］。新しい仕組みを、古い仕組みの上に広げる難しさは、IPv6のメモの互換性の壁とも重なる。

HTTP/3（RFC 9114、2022年）は、HTTPをQUICの上で動かす。HTTP/2はTCPの1本の接続を使うので、パケットが1つ失われると、関係のないやりとりまで止まる（head-of-line blocking）。QUICは、ストリームごとに別々に扱えるので、その止まりを避けやすくなる［14］。

もう1つは、距離を縮める工夫だ。CDNは、同じ内容のコピーを世界のあちこちのサーバーに置き、利用者に近いサーバーが答える仕組みだ。距離が遠いほど、そのぶん遅延が大きくなるので、近くのサーバーが答えれば、往復は安くなる［15］。東京や大阪にコピーがあれば、往復は、2章の計算で数ミリ秒台になる。だが、届いただけでは、まだ画面は絵にならない。ブラウザーは、届いたものをどう組み立てるのか。

とどいた ものは、すぐに えに なるわけでは ありません。ブラウザが、もじと いろと おおきさを くみあわせて、がめんに かきます。

ぜんぶ とどくのを またずに、とどいた ぶんから つくりはじめます［10］。はじめの あいてなら、いって もどるのは、まず 3かい。おなじ あいての ファイルは、つないだ ままで もらえます。

届いたバイトは、まだ画面ではありません。ブラウザーは、HTMLを読んでページの構造（DOM）を、CSSを読んで見た目のルール（CSSOM）を作ります。2つを合わせて、描画のための木を作り、大きさと位置の計算（レイアウト）、画面への描き込み（ペイント）へ進みます［10］。

HTMLの解析は、全部届くのを待たず、届いた分から始まります。CSSを待つあいだも、HTMLの解析とダウンロードは止まりませんが、通常のJavaScriptの実行は待たされます［10］。

遅れて届いた画像などで、レイアウトが計算し直されることもあります［10］。1章の目安（いちばん大きな部分が見えるまで）は、こうして組み立てられたページの、その時刻を測ります［2］。冒頭の問いに戻ると、初めての相手なら、最初の1バイトまでに3往復（DNSを除く）です。同じ相手のファイルは、つないだ接続を使い回せます。ページを見るまでの1秒には、この往復と、ブラウザーの組み立ての両方が入っています。

届いたバイトは、まだ画面ではない。ブラウザーは、HTMLを読んでDOM（ページの構造の木）を、CSSを読んでCSSOM（見た目のルールの木）を作る。2つを合わせてレンダーツリーを作り、レイアウト（大きさと位置の計算）、ペイント（画素への描画）へ進む［10］。

HTMLの解析は、全部届くのを待たず、届いた分から始まる。CSSを待つあいだも、HTMLの解析とダウンロードは止まらないが、通常のJavaScriptの実行は待たされる［10］。

遅れて届いた画像などで、レイアウトが計算し直されることもある［10］。1章のLCPは、こうして組み立てられたページで、いちばん大きな部分が描かれた時刻を測る［2］。冒頭の問いに戻ると、初めての相手なら、最初の1バイトまでに3往復（DNSを除く）。同じ相手のファイルは、つないだ接続を使い回せる。「1秒」には、この往復と、ブラウザーの組み立ての両方が入っている。

おうちの 人と いっしょに、ブラウザの「デベロッパーツール」の「ネットワーク」を ひらいて、ページを よみこみなおして みましょう。ファイルが、ながい ぼうの ならびで 見えます［16］。

さがして みる

• ながい ぼうは、どの ファイルかな。もういちど ひらいたとき、みじかく なった ぼうは あるかな。

ブラウザーの開発者ツールで、ページの往復を見ることができます。「ネットワーク」のタブを開いて、ページを再読み込みしてみましょう。家の人といっしょにやってください。

タイミングを見る

• 1つのファイルを選んで、「タイミング」を見る。DNSの検索、接続（TCPとTLSのあいさつを含みます）、サーバーの返事を待つ時間などが、分けて表示されます［16］。
• 2回目に開いたとき、どの欄が短くなるか、なくなるかを見る。この章で数えた往復のうち、消えるものがあるはずです。

原典で確かめる

• RFC 8446の2.3節で、0-RTTの再送攻撃の注意を読む。1往復を減らす代わりに、何を手放したのかが書かれています［6］。
• Web Almanacの「Page Weight」の章で、リクエスト数の年ごとの変化を見る。2025年の中央値のほか、過去の年の値と比べられます［8］。

自分のブラウザーで確かめる

• 開発者ツールの「ネットワーク」で、1つのリクエストの「タイミング」を見る。DNS Lookup、Initial connection、Waiting（TTFB）、Content Downloadの内訳が出る［16］。国内のサイトと海外のサイトで、Initial connectionの長さを比べたとき、2章の往復の計算と合うか。2回目に開くと、どの欄が短くなるか。