HTMLパーサーの裏側：文字ストリームからトークンへ、そしてブラウザが「HTMLの破綻」を優しく包み込むまで
こんにちは。日々、数百万行のJavaScriptと向き合い、DOMの再描画コストに頭を悩ませているフロントエンドエンジニアの皆さん。ブラウザという名の巨大なブラックボックス、その中で繰り広げられる最初の儀式――「HTMLのパース（構文解析）」について、どれほど深く考えたことがありますか？
「HTMLなんて、ただのテキストを上から順に読み込んでツリーを作ってるだけだろ？」
もしそう思っているなら、今日のこの記事はあなたの世界観を少しだけ、いや、根本から揺るがすことになるかもしれません。
ブラウザのレンダリングエンジン（Blink, WebKit, Geckoなど）のコアにおいて、HTMLの解釈は単なる「文字列の切り出し」ではありません。それは、ネットワーク層から非同期で送られてくる予測不能なバイトストリームを、堅牢なDOMツリーへと昇華させる、極めて高度な「状態機械（State Machine）」のダンスなのです。
今回は、その中でも最もプリミティブでありながら、パフォーマンスと堅牢性の要である「トークン化プロセス（Tokenization）」と、混沌としたマークアップを救う「エラー回復アルゴリズム」の深淵へと皆さんを誘いましょう。
—
1. 文字ストリームからトークンへ：字句解析の裏側
ネットワークのソケットから流れてくるデータは、突き詰めればただの「バイトの配列（Bytes）」です。これをインコード（UTF-8など）し、さらに「文字ストリーム（Character Stream）」へと変換した上で、HTMLパーサーの心臓部であるトークナイザー（Tokenizer）へと流し込みます。
ここで重要なのは、「HTMLパーサーは、通常のプログラミング言語（C++やJavaScriptなど）のコンパイラとは異なり、LL(k)やLRといった厳密な文法解析器ではない」という点です。HTML5仕様書は、文法ではなく「トークナイザーの状態遷移（State Transitions）」を厳密に定義しています。
状態機械（State Machine）の奔流
トークナイザーは、現在位置の文字と「現在の状態（State）」に基づいて、次にどの状態へ遷移するかを決定します。代表的な状態をいくつか挙げてみましょう。
- Data State: 通常テキストを処理している基本の状態。`<` に遭遇すると、Tag Open State へ遷移します。
- Tag Open State: `<` の直後。次に続く文字が `/` なら End Tag Open Stateへ、アルファベットならTagName Stateへ進みます。
- Before Attribute Name State: タグ名が終わった後の空白文字をスキップし、属性の到来を待ち構える状態。
この状態遷移の何がヤバい（すごい）かというと、「不完全なマークアップや、人間が書いた無茶苦茶なHTMLの断片」であっても、この状態機械のループを回し続けることで、絶対にクラッシュせずにトークンを吐き出し続けることができるという点です。
[文字ストリーム]
↓ (一文字ずつ入力)
+—————————————+
| HTML Tokenizer |
| (Data State / Tag Open / Attr Name) |
+—————————————+
↓ (トークンのストリームを出力)
[ StartTag: div, Attr: id=”app”, Text: “Hello” ]
—
2. パフォーマンスのボトルネック：なぜ「一文字ずつ」処理するのか？
現代の高速なCPUにおいて、文字列の走査は一見して朝飯前のように思えます。しかし、フロントエンドのパフォーマンスチューニングにおいて、HTMLパーサーのトークン化プロセスがボトルネックになるケースは実務上存在します。特に、「巨大なインラインJSONの埋め込み」や「深すぎるネスト」がある場合です。
トークナイザーは、基本原則として文字ストリームを前方に向かって一文字ずつ（Sometimes look-ahead for a few characters）消費します。正規表現で一気にゴッソリ切り出すようなアプローチは、HTMLの柔軟すぎる仕様（例えば、属性値のクォート省略や、未エスケープのアンテナ文字など）の前では完全に破綻します。
メモリ効率とキャッシュミス
ブラウザのC++実装（例えばChromiumの `HTMLToken` や `HTMLTokenizer`）では、トークン生成時のアロケーションコストを極限まで削るために、Arena Allocation（アリーナ allocator）やオブジェクトプールが多用されています。
もしあなたが、クライアントサイドで巨大なHTML文字列を動的に生成し、`innerHTML` にぶち込むようなコードを書いているとしたら、裏では以下のような高負荷な処理が走っています。
1. DOMString（UTF-16）から内部の文字エンコーディングへの変換
2. トークナイザーの状態機械の膨大なループ実行
3. 各トークン（StartTag, EndTag, Character）のヒープメモリ確保とパース
4. DOMツリーの構築とレイアウトツリーへの伝播
教訓: クライアントサイドでの不必要な `innerHTML` の乱用は、単なるDOM操作の遅延だけでなく、この「C++層のトークナイザーの暴走」を毎回引き起こしているという自覚を持ちましょう。
—
3. ブラウザの優しさ：エラー回復（Error Recovery）アルゴリズム
HTMLスペシャリストとして最も感嘆すべき、そして同時に「Webの魔窟」を作り出している元凶が、HTML5仕様で標準化されたエラー回復アルゴリズム（Error-Recovery Algorithms）です。
コンパイラの世界であれば、文法エラー（Syntax Error）を見つけた瞬間、パーサーは「ビルド失敗（Syntax Error: Unexpected token）」と叫んで処理を中断します。しかし、Webブラウザが同じことをしたらどうなるでしょう？ 世の中のWebサイトの99.9%は数秒で「真っ白な画面」になり、インターネットは崩壊します。
そのため、ブラウザはHTMLの記述ミスに直面したとき、「こう書きたかったんだろう」と勝手に解釈して修正するという、極めて高度な（そしてお節介な）エラー回復を行います。
実例：タグの交差（Mismatched Tags）
次のような間違ったHTMLを書いたとします。
ここは段落の中です。
常識的に考えれば、`` が閉じられる前に `
` が閉じられており、文法的には完全に破綻しています。しかし、ブラウザのパーサー（Tree Builder）は、この矛盾を次のように解決（回復）します。
1. `
` を開き、`` を開く。
2. `
` に遭遇したとき、アクティブなフォーマットング要素のスタックを確認する。
3. パーサーは「あ、こいつ `` を閉じ忘れて `
` を閉じやがったな」と推測する。
4. 暗黙的に `` を挿入して `
` を閉じ、その直後に再度 `` を開き直す（Reconstruct Formatting Elements）。
実際のDOM構造はこう補正されます。
ここは段落の中です。
この「勝手に補正してくれる優しさ」が、初心者の学習コストを下げた最大の功績ですが、同時に「意図しないDOM構造のバグ」や、セキュリティ上の脆弱性（DOM-based XSSの温床）を生み出す原因にもなります。
—
4. 非同期スクリプトの競合とプレフッカー（Speculative Parser）
さて、トークナイザーとツリービルダーが絶妙なリズムでHTMLを解釈している最中、最大の「邪魔者」が現れます。それが `
上級エンジニアであるあなたなら、これが何を意味するか分かるはずです。
スクリプトの位置、属性（`async` / `defer`）、そして動的なタグ挿入のタイミングが、ブラウザのトークナイザーのライフサイクルにどう影響するかを常に意識し、クリティカルパス（Critical Rendering Path）を最適化し続ける必要があります。
---
5. 実務で活かす：堅牢なフロントエンドのための知見
この深遠なブラウザの仕組みを踏まえ、私たちが実務で書くコードやアーキテクチャ設計にどう活かすべきか、具体的な指針をまとめます。
1. バリデーションされたマークアップの提供
ブラウザのエラー回復アルゴリズムに頼り切らないこと。ブラウザが「よしなに直してくれる」処理には、確実にCPUサイクル（オーバーヘッド）が消費されています。特に大規模なSSR（Server-Side Rendering）アプリケーションにおいては、正しいHTML構造を出力することがそのままレンダリングパフォーマンスに直結します。
2. 動的なHTMLパースの最小化
クライアントサイドで大きな文字列を `innerHTML` に流し込む処理は、トークナイザーとツリービルダーをフル回転させます。可能な限りVirtual DOMの差分更新や、テンプレートのプリコンパイル済みメカニズム（Lit-htmlやVueのテンプレートなど）を活用し、ブラウザのネイティブHTMLパーサーへの過度な依存を避けましょう。
3. リソースのプリロード最適化
プレフッカーを味方につけるため、重要度の高いアセット（フォントやファーストビューの画像）には `` を明示的に付与し、ブラウザの先読みアルゴリズムを助けましょう。
---
エピローグ
HTMLパーサーのトークン化プロセス。それは、人間が適当に書き殴ったテキストの断片を、ブラウザが命がけで構造化されたオブジェクト（DOM）へと翻訳する、壮大なドラマです。
この内部挙動の解像度が高まれば高まるほど、あなたが書くコードの一行一行が、ブラウザのエンジン上でどう解釈され、メモリをどう消費し、どのタイミングで画面にピクセルを描画するのかが、まるで透けて見えるようになってきます。
さあ、ブラウザのエンジンと対話する準備はできましたか？
明日からのコードレビューでは、ぜひ「このHTML、トークナイザーとツリービルダーに余計な苦労をさせていないか？」という視点を取り入れてみてください。世界が変わって見えるはずです。
コメント