こんにちは！フロントエンドの現場を長年歩んできたチーフアーキテクトの私です。

Webサイトを作っていて、「なんだかパッと画面が表示されずに、白紙の時間が続くな……」と感じたことはありませんか？「コードは間違っていないはずなのに、どうしてブラウザはすぐ描いてくれないんだろう」と、初学者の頃は本当に頭を抱えたものです。

実はこれ、Webブラウザの「中身のルール」を知るだけで、スルスルと謎が解けていきます。今回は、ブラウザが裏側でやっている「CSSOMツリーの構築」と、それが画面表示をストップさせてしまう（＝レンダリングブロック）理由について、身近な例え話と一緒に優しく紐解いていきましょう。

つまずきやすいポイントも「大丈夫、みんな最初はこうなんです」としっかりフォローしていきますので、どうぞリラックスしてコーヒーでも飲みながら読んでいってくださいね。

—

1. ブラウザが画面を表示するまでの「お買い物」のストーリー

Webブラウザがインターネット上のHTMLファイルやCSSファイルを読み込んで、画面にピクセルを描き出すまでのプロセス。これは例えるなら、「大きなお洋服のコーディネートを完成させるお買い物」にそっくりです。

あなたが新しいコーディネート（Webページ）を完成させたいとします。必要なのは、服のパーツ（HTML）と、その色や形、組み合わせ方のデザイン指定（CSS）ですね。

HTMLは「パーツの骨組み」

HTMLは、いわば「シャツが1枚、ズボンが1本、靴が1足ありますよ」という、素材のリストです。ブラウザはこれを上から順に読んでいき、「DOM（Document Object Model）」という骨組みのツリー構造を作ります。「あ、ここに見出しがあって、ここに段落があるんだな」と、パズルのピースを並べるように組み立てていくわけです。

CSSOMは「着こなしのルールブック」

一方でCSSは、「シャツはタックインして、ズボンはロールアップ、靴はピカピカに磨いて……」というスタイリングのルールブックです。
ブラウザはこのCSSを読み込んで、「CSSOM（CSS Object Model）」というデザインのツリー構造を作ります。どの要素にどんな色をつけて、どんなレイアウトにするのかを、ここで一網打尽に整理するんです。

—

2. なぜCSSの読み込みは画面をストップ（ブロック）させるのか？

さて、ここからが今回の核心です。
HTMLをパース（解析）している最中に、`` というCSSの読み込みタグに出会ったとしましょう。

ここでブラウザは、なんとHTMLの読み込み（正確には画面の描画）を一度ピタッと止めてしまいます。 これが「レンダリングブロック」と呼ばれる現象です。

「えっ、HTMLの続きをどんどん読めばいいのに、なんで意地悪するの？」って思いますよね。でも、これにはブラウザなりの切実な理由があるんです。

例え話：服の「仮合わせ」と「一発勝負」の悲劇

想像してみてください。
あなたが全身のコーディネートを考えるとき、まだ届いていない「謎のジャケット」があるのに、先に靴やズボンをバッチリ決めてしまうことってありませんよね？

もし、その「謎のジャケット」が実は派手な蛍光ピンクで、しかもロング丈だったらどうでしょう？ せっかく靴やズボンの色をシックに決めても、ジャケットを着せた瞬間に全部台無しになって、結局すべてを着せ直すハメになります。

Webブラウザの世界でもこれと同じことが起きます。
もしCSS（スタイルのルール）が読み込まれていない状態で、ブラウザが先にHTMLだけで画面（DOM）をパッと描いてしまったらどうなるか。

1. 1回目： 白い背景に、黒い文字の質素な画面がパッと表示される。
2. 2回目： 直後にCSSが読み込まれ、急にデザインが適用されて、文字が巨大化し、レイアウトがガタガタとズレる。

ユーザーからすると、画面が「チラッ」と点滅したり、表示されたものがグニャッと歪んだりしますよね。これがいわゆる「FOUC（Flash of Unstyled Content）」と呼ばれる現象です。現代のWebサイトでこれをやると、「なんだか動作が不安定なサイトだな」とユーザーにストレスを与えてしまいます。

だからこそ、ブラウザはこう言っているのです。
「ちょっと待って！ デザイナー（CSS）の指示書が届くまでは、絶対に画面を描き始めないからね！」

これが、CSSOM構築がレンダリングをブロックする理由です。ユーザー体験の品質を守るための、ブラウザの優しさ（こだわり）なんですね。

—

3. メディアクエリの登場：すべてのCSSがブロックするわけじゃない？

「でも待って、スマホ用のCSSとか、印刷用のCSSとか、今すぐ必要ないスタイルもあるよね？」
そう気づいたあなたは素晴らしい着眼点をしています！

ここで登場するのが「メディアクエリ（Media Queries）」です。

ブラウザは賢いので、CSSファイルを読み込むときにも状況判断をします。
例えば、今あなたがパソコンの大きな画面（幅1200px）でWebサイトを見ているとしましょう。そのとき、ブラウザはスマホ用の `mobile.css` を見つけても、「あ、これ今の私の画面サイズには関係ないや」と判断します。

メディアクエリがCSSOMとブロックに与える影響

• 今の環境に合致するCSS： レンダリングをブロックします（画面を描くために今すぐ必要だから）。
• 今の環境に合致しないCSS（メディアクエリで除外されるもの）： CSSOMの構築には含まれますが、画面の描画（レンダリング）をブロックはしません。

つまり、ブラウザは「今のあなたにとって必要なスタイルのルールブック」だけを厳選して、最小限の足止めで画面を表示しようと必死に頑張ってくれているのです。

—

4. 実務で活かす！レンダリングブロックを優しく回避するコツ

「じゃあ、サイトを速くするためにCSSはどう書けばいいの？」という疑問が湧いてきますよね。現場のエンジニアがよく使う、具体的な工夫をいくつかご紹介します。

① 本当に必要なCSS（Critical CSS）を厳選する

最初に見えるファーストビュー（画面をスクロールせずに最初に見えるエリア）に関係のない、重たい装飾用のCSSは、できるだけ後ろの方で読み込むか、分割するようにしましょう。

② メディアクエリを正しく活用する

先ほどお話した通り、使わない条件のCSSにはしっかりと `media` 属性をつけておくことで、ブラウザの無駄な足止めを防ぐことができます。

以下に、ブラウザの読み込みを意識した、シンプルで実用的なHTMLのサンプルコードを置いておきますね。

—

最後に：ブラウザと仲良くなろう

最初は「なんでここで止まるの？」と呪文のように思えたCSSの読み込み制限も、こうしてブラウザの気持ちになって考えてみると、「なるほど、ユーザーに綺麗な画面を届けるための気配りなんだな」と愛おしく思えてきませんか？

Webブラウザは、私たちが書いたコードをただ機械的に処理しているだけではなく、「どうすればユーザーに最高の体験を届けられるか」を常に考えて動いている優秀な相棒です。

もし「サイトの表示が遅いな」と感じたら、ぜひ今回お話しした「DOMとCSSOMのキャッチボール」を思い出してみてください。きっと、どこをどう直せばいいのか、優しい解決策が見えてくるはずですよ。

それでは、また次の現場でお会いしましょう！あなたのWeb制作ライフを、心から応援しています。