『Webブラウザエンジニアリング』第1~3章を読みました。
以下の書籍を1から3章まで読みました。
全部で16章もあるので、こまめに感想を残しておこうと思います。
Webの歴史
Web が成り立つ経緯について解説がありました。
ふーん、ぐらいの気持ちで読み進めました。
その Web 歴史の中で、Netscape Navigator と Internet Explorer によるブラウザ戦争についても触れられていました。
WebKit のプロジェクトが1999年から始まっており、Gecko は1997年の Netscape の開発が始まりだったそうです。
今日での主要なレンダリングエンジンは、Webkit、それをフォークした Blink、Gecko の3つですが、1990年代からのプロダクトのようです。
そんな遥か昔のプロダクトは、今でいうレガシーと呼ばれる存在ですが、今でもバリバリの現役というのがすごいですね。
そんなプロダクトのソースコードは、以下のようなコードがあるようです。
- なんであるのか不明なコード
- 消すと壊れる不思議なコード
メンテナンスが非常にシビアな印象ですね...。
抽象化（関数、クラスなど）をすると極端にパフォーマンスが悪くなるそうです。
様々な処理がレンダリングエンジンには搭載されていて、
かつ、滑らかなユーザー体験をする上で60fpsを目指すためには、非常に難易度が高そうです。
面白そうですね。
また、標準化とオープンソース化ということにも触れられていました。
さまざまなブラウザが独自実装してしまうと、Web開発者（Web上にサービスを提供する開発者）から離れられてしまいます。
それはそうですよね、複数のブラウザをサポートしようとWeb開発者はプログラムを実装するので、独自ブラウザへのケアはやりたくありません。
そこで標準化というブラウザの足並みを揃える動きと、透明性のあるオープンソース化によって、
Web プラットフォームのエコシステムが成長していったのかと思います。
学習体験が素晴らしい
座学は終了し、実際にブラウザを作って学ぶ章へ突入しました。
ここの書籍は、学習体験が素晴らしいです。
本書では、読み進めていくにつれて段階的にブラウザを完成していきます。
そのサンプルコードは、以下のリポジトリからチェックアウト（ダウンロード）できます。
サンプルコードを提供する本というのは、よくあります。
本書の特徴は、Gitのコミットログです。
セクション単位に、Gitのコミットログが積まれています。
実装はセクション1.4から始まるので、そのコミットへスイッチします。
git switch --detach d09345d # Section 1.4スイッチすると、セクション1.4のコードを見ることができます。
動作する環境は、 Docker を使っているので環境構築が楽になっています。
make docker_build
make docker_run URL=<your_url_here>次のセクションに進む場合は、コミットを1つ先に進めば良いのです。
git switch --detach "$(git rev-list --reverse HEAD..main | head -n 1)"これを繰り返すことで、徐々にブラウザが進化していくのです。
本とソースコードと動くもの、この3点セットが常に揃っているのです。
デスクトップ環境とアプリ
PCなどのデスクトップ環境から、Chrome などのアプリを起動します。
その際、デスクトップ環境はアプリに対して表示するウィンド領域の確保を行います。
ウィンドウ領域内で、アプリが描画されます。
デスクトップ環境は、マウスクリックやスクロールなどのイベントを検知してアプリへ伝えます。
アプリは、イベントからアクションを実行し応答します。
デスクトップ環境は、イベントを受け付けてまた同じことを繰り返します。
イベントループという無限ループを常に実行します。
アプリ開発には、Apple や Google など各ベンダーが提供する開発ツールキットがあります。
そのツールキットにはUI部品などが提供されているので、デザインがベンダー色に揃います。
本書の実装では、そのような部品を一切使わずに2次元キャンバスとして描画します。
この発想を見て、『あれ、HTMLのcanvasを使えば、ブラウザの中でブラウザ作れるの？』とか思っちゃいました。
まずは通信
ブラウザを開いて、まず行うのは URL を指定することです。
URL は、Web上のリソースを識別するものです。
最初の実装では、指定するURLへサーバリクエストを行いレスポンスのボディをターミナル上で出力するものです。
内容的に簡単な感じだったので、ささっと読み進めました。
レキサーの登場
サーバリクエストのレスポンスは、HTML文書です。
HTMLを解析するために、超簡易的なレキサー（字句解析器）が登場します。
1文字ずつチェックし、タグの開始・終了を確認し、タグの中のテキストだけを出力するようにします。
画面に初描画
本書では、Python3 と Tkinter GUIライブラリの Canvas を使います。
Canvas は、x,y座標を指定して文字を出力します。
左上が起点となり、下に行くほどy座標は増えて右に行くほどx座標が増えます。
抽出したテキストを、固定の画面幅に、固定の文字サイズで、横に並べます。
文字が画面を越えるなら、x座標をリセットしてy座標を増やして、文字を横に並べます。
これだけでも、HTMLの文章を出力できるのは少し感動しました。
どこで折り返すか？の考えに、ハイフネーション という考えがあります。
英単語だと、改行で単語を跨ぐ場合にハイフンで繋げる、みたいなことがあるようです。
日本語だと、文章をスペースでは区切りません。
どこで改行すべきかというのも考える必要があるようです。
CSS の word-break は関係が近そうです。
スクロール
文字が多いと、固定画面に収まらなくなります。
そこでスクロールを導入します。
スクロールって、全ての文字が入っている領域をページ（レイアウト）、見えている領域を画面と考えるようです。
入力されたテキストからディスプレイリスト（どの文字がどこに表示するか）へ変換し、
スクロール量に応じて出力するテキストを限定して出力します。
愚直に実装すると、スクロールが発生するたびに処理が重なり 60fps に間に合わなくなります。
ブラウザでは、さまざまな最適化が施されているようです。
本書では、見えないところを描画しないシンプルな方法が紹介されていました。
注釈で面白い話がありました。
スクロールみたいな動くアニメーションは 60fps (約16ミリ秒)を下回るとストレスに感じるのに対し、
ボタンクリックなどのアクションレスポンスは 100ミリ秒以内 に返せれば良い、みたいな話です。
アクションの方は、決定して実行して応答を理解する 一連の流れがあるので、時間がかかるようです。
動くアニメーションの場合は、そういう理解するステップが不要で直感的に理解できるからでしょうか？
全部が全部、60fps を目指す必要がないのです。
フォント
文字によって、文字の大きさ（横幅・縦幅）は違います。
xは小さいけど、Gは大きいです。
太字やイタリック文字によっても、大きさが変わります。
文字の大きさが変わると、Canvasで表示するx,y座標も変わります。
文字の大きさはフォントデータから取得できます。
フォントデータから、1文字の縦横幅を取得できます。
それらの縦横幅を使って、文字を横に並べるのです。
フォントデータから文字の情報を取得するのは重い（？）みたいで、最適化する必要があります。
フォントデータをKey/Valueで保持しておいて、使用時にフォントデータを参照するみたいにします。
あとは文字をただ横に並べると、物干し竿にぶら下がったように文字が上に引っ付いた感じになります。
y座標は上から下に数値が上がるためかと思います。
そこで、文字の中心となるベースラインを見つけて、表示する文字のy座標を調整するロジックがありました。
これは文字を左から右に並べて読む文章を前提としています。
言語によっては、右から左に文字を並べたり、上から下に文字を並べたりします。
こういうケースを考慮するとなると、ロジックが複雑になり理解するのが大変そうな印象です...。
多言語対応をやめたら、かなりスリムなコードになるのでは...。
終わりに
まだ CSS や Javascript が出ていません。
HTMLの簡単なパースと画面表示のみです。
けれど、HTMLを読み込んで画面に描画する、一番基礎となるブラウザができたのは感動しました。
続きも、しっかり読み込もうと思います。
-
※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「書籍レビュー」の記事
以下の書籍を購入しました。 Chrome開発者による、ブラウザの仕組みについて解説されています。 https://www.oreilly.co.jp//books/9784814401574/ ちょうど今朝、自宅へ届きました。 ページ数が5
2026年03月17日
以下の書籍を読みました。 感想について書こうと思います。 https://books.mdn.co.jp/books/3225303033/ 概要 本書では、数年以内に流行った比較的新しいCSSテクニックについて紹介されていました。 例えば
2026年03月15日
Googleレコメンドで、以下のCSSに関する書籍が流れてきました。 CSS 優良デザイン×アイデア事典 プロがシェアする現場の即戦力テクニック｜株式会社エムディエヌコーポレーション - books.mdn.co.jp なんとなくレコメンド
2026年03月10日
タグ「ブラウザ」の記事
最近、iframeを使っています。 クライアントサイドで埋め込む想定で、iframeを使おうとしています。 色々と苦労したことがあったので、書いて残しておこうと思います。 レスポンスヘッダー 前提として、ウェブアプリケーションをプロダクショ
DuckDB WASMとOrigin Private File System (OPFS) を組み合わせ、Google マイアクティビティの履歴をブラウザ内に閉じたまま扱えるようにしたときの設計と学びを整理しました。
こんにちは、@silverbirderです。最近、湖県に移住してWebフロントエンドのお仕事をしています。お仕事をしていると、ユーザー体験を良くするためには、大きな改善をせずとも小さな改善だけでも十分な効果があると思い始めました。本記事では、その小さな改善となる、3つのことについて書きたいと思います。