- フロントエンドの進化はUIの進化ではない
- ブラウザはどうやって画面を描いているのか
- jQuery時代の問題：reflow地獄
- Virtual DOMの本当の役割
- なぜSPAは重くなるのか
- SSRが速い理由
- Hydrationという新しい問題
- RSCが狙っているもの
- CSSの進化も同じ文脈
- 実務で重要な視点
- 最後に
フロントエンドの進化はUIの進化ではない
フロントエンドは「見た目の技術」だと思われがちです。
新しいUIライブラリ、新しいCSSフレームワーク、デザインシステムなどが話題になるため、UI表現が中心に見えます。
しかし実際には違います。
フロントエンドの進化の本質はレンダリングパイプラインの最適化です。
つまり何が変わってきたかというと、ボタンのデザインではなく
「ブラウザが画面を表示するまでの処理」をどう短くするかです。
フロントエンドの歴史を理解するには、まずブラウザがページを表示する手順を知る必要があります。
ブラウザはどうやって画面を描いているのか
WebページはHTMLを受け取った瞬間に表示されるわけではありません。
ブラウザ内部では次の処理が行われています。
1. HTMLパース（DOM生成）
2. CSSパース（CSSOM生成）
3. レンダーツリー生成
4. レイアウト計算
5. ペイント
6. コンポジット
これを総称してレンダリングパイプラインと呼びます。
重要なのは、UIの滑らかさや表示速度はすべてこのパイプラインの処理量で決まるという点です。
フロントエンドの新技術の多くは、この工程のどこかを短縮するために生まれています。
jQuery時代の問題：reflow地獄
jQueryが主流だった頃、開発者はDOMを直接操作していました。
$("#list").append("<li>item</li>");
一見問題ないコードですが、DOM変更はブラウザに再レイアウト（reflow）を要求します。
これが大量に起きると表示が極端に遅くなります。
例えば次のコードです。
for(let i=0;i<1000;i++){ $("#list").append("<li>"+i+"</li>"); }
1回のループごとにレイアウト計算が走る可能性があります。
UIがカクつく原因の多くはここにありました。
つまり当時のボトルネックは
DOM更新コストでした。
Virtual DOMの本当の役割
ReactのVirtual DOMは「高速なDOM操作」と説明されがちですが、正確ではありません。
目的はDOMを速くすることではなく、DOM変更回数を減らすことです。
Reactはまず仮想的なツリーをメモリ上で更新します。
その後、差分だけを実DOMへ反映します。
イメージは次です。
- jQuery：変更のたびにブラウザへ通知
- React：変更をまとめて最後に通知
これによりreflowの回数が激減します。
Virtual DOMは描画エンジンではなく、レンダリングパイプラインの最適化装置です。
なぜSPAは重くなるのか
SPAはページ遷移を減らすことでUXを改善しました。
しかし別の問題を生みます。
初回ロード時に大量のJavaScriptを実行することです。
JavaScript実行中、ブラウザはレンダリングを止めます。
これをメインスレッドブロックと呼びます。
つまり
HTMLが遅いのではなく
JavaScriptが表示を止めている
状態になります。
ここでボトルネックはDOMではなく
メインスレッドの占有へ移動しました。
SSRが速い理由
SSR（Server Side Rendering）が速く感じるのは、ネットワークが速いからではありません。
ブラウザの仕事を減らしているからです。
SSRでは、ブラウザは次の工程を省略できます。
- DOM生成の一部
- JavaScript実行前の描画待ち
結果として、ユーザーはHTMLを受信した直後に画面を見られます。
つまりSSRの本質はSEOではなく
レンダリングパイプラインの前倒しです。
Hydrationという新しい問題
SSRにも課題があります。
それがHydrationです。
サーバが生成したHTMLを、ブラウザ側のJavaScriptと結び付ける処理です。
この間、CPU使用率が急上昇します。
つまり
表示は速い
しかし操作可能になるまで遅い
という状態が起きます。
これを解決するために考えられたのが部分HydrationやStreamingです。
RSCが狙っているもの
React Server Componentsはレンダリング最適化の延長線にあります。
目的は明確です。
ブラウザで実行するJavaScriptを減らす
従来は全コンポーネントがクライアントで動作しました。
RSCではサーバで完結するUIはブラウザで実行しません。
つまり最適化対象が
DOM操作
→ JavaScript実行
へ移っています。
CSSの進化も同じ文脈
FlexboxやGridの登場も、単なるレイアウト機能追加ではありません。
従来のレイアウトはJavaScriptで調整されることが多く、レイアウト計算が増えていました。
CSSでレイアウトが完結すると、JavaScript実行が減ります。
結果としてレンダリングパイプラインが短縮されます。
つまりCSS進化もレンダリング最適化です。
実務で重要な視点
ここを理解すると、技術選定の基準が変わります。
例えば次の判断です。
- アニメーションが重い → CSSで実装
- 初回表示が遅い → SSR検討
- 操作がカクつく → JS実行量削減
フレームワークの違いより、
どのレンダリング工程が詰まっているかを見る方が重要です。
最後に
フロントエンドはUIの分野に見えますが、本質はパフォーマンス工学に近い領域です。
ボタンの見た目より、描画タイミングの制御が重要になっています。
jQuery、React、SSR、RSCは別々の技術ではありません。
すべて「レンダリングを早くする」ための手段です。
フロントエンドを理解する近道は、新しいライブラリを覚えることではなく、
ブラウザがどの順番で画面を描いているかを知ることです。
UIは結果であり、レンダリングが原因です。
そこを見れば、技術の変化は急に分かりやすくなります。
