- Webエンジニアと一般ユーザーが ブラウザの内部動作原理 を直感的に理解できるように作られた インタラクティブ学習ガイド
- アドレスバーへの入力から HTTPリクエスト生成、DNS解決、TCP接続、HTMLパース、DOM構築、レンダリングパイプライン までの過程を段階ごとに可視化
- 各段階は 直接入力したり操作できる例題 で構成されており、ネットワーク通信とレンダリング過程を実験的に体験可能
- DOMの役割 と Layout–Paint–Composite 段階の違いを明確に示し、性能に影響する要素を視覚的に確認可能
- ブラウザ構造を学習したりWebパフォーマンス最適化を理解したい開発者にとって 中核概念を体系的に身につけられる資料
概要
- このガイドは、日常的にWebを使っていても ブラウザの動作方式を明確に理解していない人々 のために作られた
- 既存資料が技術的すぎたり表面的すぎたりする限界を補う
- 小さなインタラクティブ例 を通じて、技術的な詳細を直感的に学べるよう設計
- HTTPバージョン、SSL/TLS、DNSの詳細な動作などは省略されており、中核概念中心に簡潔に構成
- プロジェクトは オープンソース として公開されており、GitHubを通じて改善提案が可能
ブラウザとURL
- ユーザーがアドレスバーに入力するすべての文字列は、内部的に URL形式に変換 される
- 入力後にEnterを押すと、変換過程を直接確認できる 実習インターフェースを提供
URLをHTTPリクエストに変換
サーバーアドレスの解決 (DNS)
- ブラウザは
example.com のような ドメイン名を直接使用できない
- DNSシステムを通じて IPアドレスに変換 する必要があり、そうして初めてサーバーと通信できる
- 入力欄にドメインを入力すると DNS解決結果(IPアドレス) を確認できる
TCP接続の確立
- DNSでIPを取得した後、ブラウザは TCPプロトコル を利用してサーバーと信頼性のある接続を確立
- 3ウェイハンドシェイク の過程で接続が確立される
- SYN: クライアントが接続を要求
- SYN-ACK: サーバーが応答と確認を返す
- ACK: クライアントが最終確認
- TCPは データ順序保証と再送機能 によって安定した通信を維持
- ネットワークを切断したりパケットを操作したりしながら 伝送安定性の実験が可能
HTTPリクエストとレスポンス
- TCP接続後、ブラウザは HTTPリクエストを送信 し、サーバーは HTTPレスポンス を返す
- リクエストとレスポンスの移動過程を 視覚的に表示 し、パケットの流れを観察できる
- レスポンスが到着すると、ブラウザは ヘッダーと本文を分離 してHTMLのレンダリングを開始
HTMLパースとDOMツリー生成
- ブラウザはHTMLバイトを パーサー(parser) に渡して DOMツリー を構築
- 例示HTMLを入力すると
<h1>, <p> などのタグが DOMノードに変換される過程 を視覚的に確認できる
- パースは ストリーミング方式 で進行し、文書全体が到着する前でもノード生成が可能
<script> タグが現れると、パースは一時中断されてスクリプトを実行- 完成したDOMはCSSと結合して レンダーツリー(render tree) を形成
DOMの重要性
- DOM(Document Object Model) はブラウザメモリ内の文書モデルであり、
HTMLパーサー、CSSセレクターエンジン、JavaScriptランタイムが 共有する中核構造
- DOMの変更は即座に レイアウト、スタイル、ユーザーインタラクション に反映
- JavaScriptコードを修正すると DOM変化がリアルタイムで反映されるプレビュー機能 を提供
Layout, Paint, Composite
- DOMとCSSの準備が整うと、ブラウザは レンダリングパイプライン を実行
- Layout(Reflow) : 要素のサイズと位置を計算
- Paint: ピクセルを塗る
- Composite: GPU上でレイヤーを合成
- 色の変更ではPaintだけが再実行されるが、サイズ変更では LayoutとPaintの両方が再実行 される
- 各段階の再実行有無をクリックで確認可能
- Layout計算が多いページはレンダリングが遅くなる ことを視覚的に示す
まとめ
- アドレス入力からレンダリングまでの全過程を 直接体験しながら学べるガイド
- すべての段階を完了すると ブラウザの動作原理に対する明確なメンタルモデル を形成可能
- プロジェクトは オープンソース で、GitHubでIssueやPull Requestを通じて改善提案が可能
1件のコメント
Hacker Newsのコメント
すべてのブラウザが最初から DOM を備えていたわけではない
初期には WorldWideWeb(Nexus, 1990)、Erwise(1992)、ViolaWWW(1992)、Lynx(1992)、NCSA Mosaic(1993)、Netscape 1.0(1994)、IE 1.0(1995) などがあった
Lynx は現在も意図的に 非DOMブラウザ のままである
AOL 1.0–2.0 は、プログラム可能なオブジェクトを持たない静的エンジン(AOLPress)を使用していた
DOM とやり取りできるようになったのは Netscape 2.0(1995)、IE 3.0(1996)、AOL 3.0(1996)、Opera 3.0(1997) からだった
その後、Netscape 4.0(document.layers) と IE 4.0(document.all) はそれぞれ異なるモデルを使っていた
最初の 標準DOM は W3C DOM Level 1(1998) で、IE 5.0(1999) が部分対応し、Konqueror 2.0(2000) と Netscape 6.0(2000) が完全対応を始めた
Safari 1.0(2003)、Firefox 1.0(2004)、Chrome 1.0(2008) は最初から標準 DOM をサポートしており、現在は WHATWG DOM Living Standard に従っている
HTML テキストを直接解釈してレンダリングするため、RAM 使用量が非常に少ない
素晴らしいプロジェクトだ
HN 読者なら High-Performance Browser Networking と Every Layout もあわせて見るとよい
どちらも Web パフォーマンスと CSS 構造 を深く扱う優れた資料だ
4章で TLS フレーム構造 を理解できたおかげで、前職でレイテンシ問題をデバッグできた
TLS フレームサイズを調整する際のトレードオフも興味深かった
実際に使う機会は多くないだろうが、ネットワークレベルの細かな調整が可能だと知れた
インストールなしで browser.engineering を体験しているような興味深いアプローチだ
ブラウザとサーバーの例を見せるときに 視覚的なアイコン（例: デスクトップ/サーバー）を追加すると、さらに理解しやすくなると思う
まずはフィードバックを集めているところで、アイコンの提案は良いアイデアなので検討してみるつもりだ
とても気に入って ブックマーク した
ただ、HTML/DOM を基準に画像、スタイルシート、スクリプトといった リソース読み込みの過程 が抜けているのは惜しい
この部分は、ページのスタイルが崩れたり画像が欠けたりする理由を理解するうえで重要だ
複雑にしすぎずにこれらのブロックを追加する方法を考えている
ブラウザウィンドウが狭いとき（1170px 未満）、目次セクションが本文の上に重なって見える問題 がある
URL パースロジックをもう少し整えるとよさそうだ
ほとんどのユーザーは問題に遭わないだろうが、
https://やhttp://以外の プロトコルスキーム を入力したときもブラウザは特別に処理するこうしたケースも拾えるとよいと思う
参考: List of URI schemes
素晴らしいプロジェクトだ
次の段階として reflow の過程 の詳細を追加する予定があるのか気になる
ページの半分以上がネットワークリクエストに割かれているのは少し残念だ
実際にブラウザの複雑な部分は パースとレンダリングパイプライン にある
どのセクションで深く掘り下げるべきかわからなかったので、ひとまず公開してからフィードバックを集めている
的外れな質問かもしれないが、DNS ルックアップを完全になくして 人間が読めるドメイン名 だけで動作させたらどうなるのか気になる
インターネット全体を 1 つの巨大なスイッチのようにする概念だ
Tailscale の創業者が似たアイデアについて書いた文章を見たことがある
素晴らしい仕事だ