Webエンジニアの採用試験でもよく聞かれる「URLを入力してから実際にページが表示されるまでの流れ」について、自分の理解を整理する意味も込めてまとめました。
大きく分けると、流れは以下の2段階です。
- ネットワーク部分: サーバーと通信してデータを受け取るまで
- レンダリング部分: 受け取ったデータをブラウザが画面に組み立てるまで
1. ネットワーク部分:サーバーとやり取りするまで
URLを入力
ブラウザのアドレスバーにURLを入力するところからスタートします。
💭 たとえるなら...
「〇〇というお店に行きたい」と決めて、出発する場面です。この時点ではまだお店の正確な場所(住所)はわかっていません。
DNS名前解決
DNS（Domain Name System） とは、人間が覚えやすいドメイン名（例: example.com）と、コンピューターが通信で使う数字のIPアドレス（例: 192.0.2.1）を自動で変換・結びつける仕組みのことです
example.com のようなドメイン名は人間向けの名前であり、コンピューター同士が通信するにはIPアドレスが必要です。
ブラウザはまず、「このドメイン名に対応するIPアドレスを以前調べたことがあるか」 をキャッシュ（ブラウザ、OS、ルーターなど）から確認します。キャッシュに情報があればそれを利用し、なければDNSサーバーへ問い合わせてIPアドレスを取得します。
💭 たとえるなら...
「〇〇レストラン」という店名だけでは目的地にはたどり着けません。まずはGoogleマップなどで店名を検索し、住所を調べてから向かいます。DNSサーバーも同じように、ドメイン名（example.com）から通信先のIPアドレスを調べる役割を担っています。
TCP接続確立
TCP（Transmission Control Protocol） とは、データを確実に相手へ届けるための通信ルール（プロトコル） です。
取得したIPアドレス宛に接続し、SYN → SYN/ACK → ACK という3回のやり取り（3ウェイハンドシェイクと呼ばれる）を行います。このやり取りによって、お互いに通信できることを確認し、信頼できる通信路を確立します。
💭 たとえるなら...
電話をかけて、「もしもし、聞こえますか？」「はい、聞こえます。そちらはどうですか？」「はい、こちらも聞こえています」と、お互いに声が届いていることを確認するイメージです。この確認が終わって初めて、本題の会話（データの送受信）が始まります。
TLSハンドシェイク
HTTPSでは、通信内容を安全にやり取りするための準備として、TLS（Transport Layer Security）ハンドシェイクを行います。
ここでは、サーバーが本物であることを証明する「証明書」の検証や、通信を暗号化するための鍵交換を行います。これらが完了すると、以降のHTTP通信は暗号化され、安全にデータをやり取りできるようになります。
💭 たとえるなら...
大切な書類を送る前に、まず相手から公的な身分証を見せてもらい、「本当に送りたい相手であること」を確認します。その後、お互いだけが開けられる鍵付きの封筒を用意し、その中に書類を入れてやり取りします。こうすることで、途中で誰かに見られたり、別人に渡ってしまったりすることを防げます。
HTTPリクエスト送信 / レスポンス受信
ブラウザが「このページをください」というリクエストを送り、サーバーが処理した結果(HTML、ステータスコードなど)を返します。
💭 たとえるなら...
レストランで店員さんに「このメニューをください」と注文する(リクエスト)と、キッチンで調理されて料理が運ばれてくる(レスポンス)、という一連のやり取りに似ています。
もし注文した料理がメニューに存在しなければ「その料理はありません」と言われるように、存在しないURLにアクセスした場合は404 Not Foundのようなステータスコードが返ります。
実際の本番環境では、この「HTTPリクエスト送信/レスポンス受信」の間に、nginxのようなリバースプロキシが挟まっていることがほとんどです。
ブラウザからのリクエストは、アプリケーションサーバーに直接届くのではなく、いったんnginxを経由し、そこから適切なアプリケーションサーバーに振り分けられます。アプリケーションが返したレスポンスと、実際にブラウザが受け取るレスポンスが違って見えることがあるのは、大抵このリバースプロキシ層が原因です。
2. レンダリング部分:受け取ったデータを画面にするまで
HTMLを解析(DOM構築)
受け取ったHTMLを上から順に読み、タグの親子関係をツリー構造(DOM)として組み立てます。
💭 たとえるなら...
家を建てるときの「骨組み(柱や壁の配置)」を組み立てる作業です。「この部屋の中にこの棚がある」「この棚の中にこの本がある」といった親子関係を、設計図として整理していくイメージです。
CSSを解析(CSSOM構築)
同様にCSSも解析し、どの要素にどんなスタイルが適用されるかを表すツリー構造(CSSOM)を作ります。
💭 たとえるなら...
骨組みに対する「内装・外装の仕様書」を作る作業です。「この壁は白色にする」「この棚は横幅60cmにする」といった、見た目のルールをまとめたものだとイメージするとわかりやすいです。骨組み(DOM)と仕様書(CSSOM)は、この時点ではまだ別々に存在しています。
レンダーツリー構築
DOMとCSSOMを組み合わせて、「実際に画面に表示される要素だけ」を集めたツリーを作ります(display: none の要素などはここで除外されます)。
💭 たとえるなら...
骨組み(DOM)と仕様書(CSSOM)を照らし合わせて、「実際に建てる部分」だけをリストアップする作業です。設計図には描かれていても、「今回は使わない部屋(display: noneの要素)」は、ここでリストから外されます。ただし、骨組み自体(DOM)からは消えているわけではなく、あくまで「表示リストに入らない」だけという点がポイントです。
レイアウト計算
各要素が画面上のどこに、どのくらいの大きさで配置されるかを計算します。
💭 たとえるなら...
「表示リスト」に載った部屋や家具について、実際の敷地(画面サイズ)に対して「どこに、どのくらいの大きさで置くか」を測量して決めていく作業です。画面の幅が変わる(ウィンドウをリサイズする)と、この計算がやり直されます。
ペイント
計算結果をもとに、色やテキストなどを実際にピクセルとして描画します。
💭 たとえるなら...
測量が終わった設計図をもとに、実際に壁を塗り、家具を運び入れて完成させる、いわば「仕上げ工事」の段階です。ここでようやく、私たちが目にする実際の見た目(色・文字・画像)が画面上に描かれます。
JavaScriptの影響について
HTML解析(DOM構築)の最中に <script> タグに出会うと、ブラウザはそこで解析を一時停止し、スクリプトの読み込みと実行を先に済ませてから解析を再開します。
これは、JavaScriptが document.write() などでHTML自体を書き換える可能性があり、ブラウザ側では「続きを解析していいのか」を事前に判断できないためです。
まとめ
- URL入力 → DNS名前解決 → TCP接続 → (TLS) → HTTPリクエスト/レスポンス、という流れでサーバーからデータを取得する
- 取得したHTML/CSSを、DOM → CSSOM → レンダーツリー → レイアウト → ペイント、という流れで画面に描画する
- JavaScriptの実行タイミングによって、この流れが止まったり遅くなったりする
普段何気なく使っているブラウザですが、URLを入力してから画面が表示されるまでの間に、これだけの処理が動いています。
最後に
この記事を書こうと思ったきっかけは、社長から「これ、説明できる?」と問われた時に、うまく答えられなかったことでした。
「Webエンジニアだから説明できて当然」というより、「これがわかっていないと、何かエラーが起きたときやうまくいかないときに、『なぜ』の部分をイメージすらできない」という言葉にハッとしました。
同じように「説明できる自信がない」と感じている方の、何か気づきになれば嬉しいです。