フロントエンドのパフォーマンスチューニングを語るとき、私たちはついつい「JavaScriptのバンドルサイズを削ろう」「CSSは非同期で読み込もう」といった、エディタを開いて目に見えるコードの話に終始しがちだ。
だが、ちょっと待ってほしい。ブラウザがサーバーからHTMLの最初の1バイト(TTFB)を受け取ったその瞬間から、画面にピクセルを描き出すまでの裏側の舞台裏――すなわち「ブラウザの頭脳がどうやってリソースを先回りしてかき集めているか」を正確に理解しているエンジニアは、実はそう多くない。
今回は、現代の高速なWebブラウザを支える裏の立役者であり、実務におけるLCP(Largest Contentful Paint)改善のキーストーンである「プリロードスキャナー(Preload Scanner)」の仕組みについて、徹底的に解剖していこう。
—
1. なぜメインパーサーだけでは遅いのか?(ブラウザの歴史的ボトルネック)
まずは、ブラウザがHTMLを受け取ってから何をしているか、その泥臭い現実を思い出してほしい。
ブラウザのメインのHTMLパーサー(レンダリングエンジン)は、上から下へ、届いたストリームを1文字ずつ真面目に舐め回すようにパースしてDOMツリーを構築していく。ここで問題になるのが、HTMLの途中に以下のようなタグが出現したときだ。
メインパーサーは、``や`
何が起きるか:
プリロードスキャナーはJSのコードブロックの中身を事前に実行して解釈することはできない。そのため、このCSSの存在に気づくのは「実際にその `

コメント