こんにちは。フロントエンドの現場で「なんでウチのサイト、初期表示がこんなにモタつくんだよ……」と頭を抱えた経験、君にもあるはずだ。Lighthouseを開けば「レンダリングをブロックしているリソースの排除」というお馴染みの赤字警告。

今回は、この厄介者の根源である「CSSOMツリー構築とレンダリングブロッキング」について、ブラウザの裏側の泥臭い動きまで含めて徹底的に紐解いていこう。

教科書的な解説はスルーして、中級からワンランク上のシニアへステップアップするために必要な「ブラウザの機嫌を取る方法」を伝授する。

—

1. なぜCSSはレンダリングをブロックするのか？（ブラウザの裏側の話）

まず、ブラウザが画面を表示するまでのタイムラインを思い出してほしい。
HTMLが降ってくると、メインスレッドはそれを上から順にパース（解析）し、DOM（Document Object Model）ツリーを構築し始める。ここまでは順調だ。

しかし、途中で `` や `

この `onload="this.media='all'"` のテクニックは、実務のパフォーマンスチューニングにおいて非常に多くのプロダクトで採用されている王道のハックだ。ブラウザに「今は印刷用だからブロックしなくていいよ」と油断させておいて、ダウンロードが終わった瞬間に「やっぱ全体適用ね！」と切り替える泥臭さがいかにもプロっぽくて最高だろう？

---

まとめ：ブラウザと対話するフロントエンドへ

CSSOMとレンダリングブロッキングの関係は、単なる知識問題ではなく、ユーザーがサイトを訪れた瞬間の「体感速度」を支配する極めて重要なアーキテクチャだ。

• すべてのCSSはデフォルトでレンダリングをブロックする（FOUCを防ぐための仕様）。
• メディアクエリを活用することで、ブラウザは「今必要なスタイルか」を判断し、不要なブロッキングを回避できる。
• LCPやFirst Paintを極限まで縮めたければ、クリティカルCSSと非同期読み込みを組み合わせよ。

ブラウザが裏側でどう汗をかいて画面を描画しているか。そのメカニズムを想像しながらコードを書けるようになると、君の作るWebアプリのパフォーマンスは見違えるほど軽快になるはずだ。

さあ、今日のデプロイから、無駄なブロッキングを排除しにいこう！