ブラウザのレンダリング：テキストが画像になるまで

しかし、実務でアニメーションがガラガラしたり、スクロールを下したときに画面が突き破られる現象（Jank）を経験しながら、私の考えは変わった。 「なぜ同じコードを編んでいるのにクロムでは柔らかく、Internet Explorer（IE）では途切れるのか？」 「なぜJavaScriptでスタイルを少し変えたのにCPUが上がるのか？」

わかると、ブラウザは単なる額縁ではありませんでした。ブラウザは、私たちが送ったテキスト（HTML / CSS）を解釈し、ピクセル一つ一つを数学的に計算して撮る巨大な「画家（Painter）」であり「建築家」だった。

過去の時間、私たちは大まかなネットワーク道路を通ってデータを無事に出荷しました。今回は到着したデータボックス（パケット）を開けて、ブラウザがどのように画面という絵を描くのか調べてみよう。これがRe：Booting CS基礎シリーズの最後の話です。

到着した貨物、組み立てを開始する

私たちの「デジタル物流センター」の世界観で、物事（HTMLファイル）が顧客の家（ブラウザ）に到着しました。しかし到着したのは完成品ではなく「組立説明書」だ。ブラウザエンジン（レンダリングエンジン）という作業チームはこのマニュアルを見てすぐに組み立てに入る。このプロセスをレンダリングパイプラインと呼びます。

ステップ1: 設計図の分析 (Parsing & DOM Tree)

最初に到着したHTMLテキストを読み、「スケルトン」を作成します。

ステップ2：インテリアデザイン（CSSOM Tree）

次にCSSファイルを読んで「スタイルルール」を作成します。

ステップ3: 作業指示書の作成 (Render Tree)

今、スケルトン（DOM）とデザイン（CSSOM）を組み合わせます。ここで重要なのは、「実際に画面に見えるもの」だけを選び出すということです。

[Code Verification]リフロー（Reflow）とリペイント（Repaint）

これは本当に重要なステップです。性能最適化の核心がここにある。レンダーツリーが作成されると、ブラウザは2つの重い作業を行います。

コードでこのコストの違いを感じましょう。

const box = document.getElementById('box');

// Case 1: レイアウト（Reflow）を引き起こすコード（高コスト！）
// サイズや位置を変えると、周囲の要素の位置まで全部再計算される。
box.style.width = '200px'; 
box.style.height = '200px';
box.style.margin = '20px';

// Case 2: ペイント（Repaint）だけを引き起こすコード（比較的安い）
// 位置はそのままで、色だけ変える。計算なしで塗り直しだけで済む。
box.style.backgroundColor = 'blue';
box.style.color = 'white';
box.style.visibility = 'hidden';

分析：

実務では、「アニメーションがうるさい」は、ほとんどの場合、width、left、topなどのレイアウト属性にリアルタイムで触れたために発生します。このような場合は、transformのような属性を使ってレイアウト計算をスキップするテクニックが必要です。

実践的なアドバイス：ブラウザを悩ませないでください

学部の時はこんなことを知らなかったので、JavaScriptでDOMを雑誌で操作した。 for ドアを回しながら要素一つ一つの大きさを変え、スタイルを塗った。ブラウザの立場では、1秒に数十回ずつ建物を壊して再建する拷問に遭ったわけだ。

パフォーマンスを守るためのヒント：

シリーズ1の終了：再起動した私のCS

この記事の最後に、 [Re: Booting] CS基礎シリーズが停止しました。

私たちは長い旅をしました。

最初はただ就職のために月々覚えた知識だった。しかし、実務のエラーとぶつかり、再び覗いたCS（コンピュータ工学）は、死んでいる文字ではなく、私のコードを支える硬い地盤だった。

これで基礎工事は終わった。硬くなった地盤の上に本格的に自分だけの城を築く時間だ。次のシリーズ[Monolith Builder]では、私が実務で経験したSpring BootとVue.jsを活用したWebアプリケーションビルダーを扱う予定だ。 「理論」が「実践」になるその過程を期待してほしい。