投機的パース（Speculative Parsing）：メインスレッドの足かせを外す、ブラウザエンジンの極限の裏技
フロントエンドエンジニアの仕事とは、突き詰めれば「ブラウザという名の超高速かつ気まぐれなバーチャルマシンをいかに手なずけるか」だ。私たちは日々、ReactやVue、あるいは複雑なCSS設計に頭を悩ませているが、その下層でどれほどのドラマが繰り広げられているかを知る者は意外と少ない。
特に、Webページの初期表示速度（Core Web VitalsのLCPやFCP）を語る上で避けて通れないのが「レンダリングブロック（Render-blocking）」の存在だ。そして、その絶望的な足かせを華麗にかわすためにブラウザエンジンが編み出した、最も美しく、最もアグレッシブな最適化機構が今回深掘りする「投機的パース（Speculative Parsing）」である。
今回は、Blink（Chromium）やWebKitの内部アーキテクチャの泥臭い挙動にまで踏み込み、この「先読みの技術」が私たちの書くコードとどうインタラクトし、いかにしてパフォーマンスのボトルネックを粉砕するかを語り尽くす。
—
なぜメインスレッドはこれほどまでに孤独で忙しいのか？
HTMLパーサーとJavaScriptエンジンは、基本的に同じ「メインスレッド」上で動いている。DOMツリーを構築している最中に `` に遭遇した瞬間、ブラウザはパースを一時停止せざるを得ない。なぜなら、そのJavaScriptが `document.write()` を使ってDOM構造を根底から書き換えるかもしれないからだ。
この「同期スクリプトの恐怖」により、メインスレッドはブロックされる。ネットワーク経由でスクリプトが降ってくるまでの数百度、HTMLの解析は完全にフリーズする。
しかし、ここで立ち止まって考えてみてほしい。
メインスレッドがスクリプトのダウンロード待ちで指をくわえている間に、HTMLのドキュメントの「先」には、まだ読み込まれていない画像や外部スタイルシート、さらなるスクリプトが山のように眠っているのだ。もし、これらをスクリプトの実行完了まで一切見向きもしなかったとしたら？ Webの表示速度は今よりも何倍も遅かったはずだ。
ここに救世主として現れたのが、投機的パース（Speculative Parsing）である。
—
投機的パースの内部アーキテクチャ：裏で走る「もう一つの目」
現代のブラウザエンジンはマルチスレッドで動いている。メインスレッドがJavaScriptの実行やDOM構築で身動きが取れなくなっているとき、バックグラウンドでは「プリロードスレッド（Preload Scanner / Speculative Parser）」と呼ばれる軽量なパーサーが別スレッドでこっそりと起動する。
このプリロードスレッドの仕事は極めてシンプルかつ強烈だ。
メインスレッドがブロックされている間に、すでに受信済みのHTMLバイトストリームを先読み（Lookahead）し、``、``、`
コメント