- フロントエンドの歴史はUIではなく「計算資源の配置」の歴史
- ダイヤルアップ時代：回線が最も高価だった
- ブロードバンド時代：通信が安くなりUIが増える
- スマートフォン時代：CPUが弱くなる
- SSRの再評価：計算をサーバへ戻す
- CDNとエッジの登場：距離が問題になる
- RSCの意味：通信量の最適化
- まとめ：フロントエンドは振り子運動
- 技術選定で役立つ視点
- 最後に
フロントエンドの歴史はUIではなく「計算資源の配置」の歴史
フロントエンド技術の流れは複雑に見えます。
jQuery、SPA、SSR、RSC、そして最近のエッジレンダリングまで登場し、「何が正解なのか分からない」と感じる人も多いでしょう。
しかし視点を変えると、驚くほど単純に理解できます。
フロントエンドの進化は「ネットワーク帯域」と「CPU性能」のどちらを使うかの選択の歴史です。
つまり新しい技術は思想ではなく、
「どこで計算するのが一番安いか」を変えてきただけです。
ダイヤルアップ時代：回線が最も高価だった
2000年前後のインターネットは非常に遅く、回線が最大のボトルネックでした。
数百KBの画像を表示するだけで数十秒かかることも珍しくありません。
この時代の設計方針は明確です。
通信量を最小化する
そのためサーバ側でHTMLを完成させてから送信していました。
ブラウザは表示だけを行います。
| 項目 | 特徴 |
| 通信 | 非常に遅い |
| CPU | ほぼ使わない |
| アーキテクチャ | サーバレンダリング（従来型） |
この構造ではJavaScriptは最小限でした。
フロントエンドはアプリケーションではなく文書ビューアだったからです。
ブロードバンド時代：通信が安くなりUIが増える
ADSL・光回線の普及により、通信速度が劇的に向上します。
ここで初めてWebに「操作性」が求められるようになります。
AJAXが登場し、ページ遷移を減らす設計が普及しました。
地図、チャット、メールなどがブラウザ上で動き始めます。
このときの変化は重要です。
通信よりもユーザー操作の待ち時間が問題になったのです。
その結果、jQueryが広まりました。
DOM操作を簡単にし、インタラクティブなUIを作るためです。
つまり
回線が遅い → サーバ中心
回線が速い → クライアント処理増加
という転換が起きています。
スマートフォン時代：CPUが弱くなる
次に訪れたのがスマートフォンの普及です。
ここで状況が一変します。
通信は高速なままですが、
端末CPUが弱いという新しい問題が生まれました。
SPAはブラウザでアプリを実行します。
PCでは問題ありませんが、モバイルでは描画とJavaScript実行が重くなります。
結果として起きた問題です。
- 初回表示が遅い
- スクロールがカクつく
- バッテリー消費増加
つまりボトルネックが再び移動しました。
通信ではなく
クライアント計算能力です。
SSRの再評価：計算をサーバへ戻す
この問題を解決するため、SSRが再び注目されます。
サーバでHTMLを生成し、ブラウザは描画のみを行います。
ここで起きているのは「新技術の登場」ではありません。
計算場所の再配置です。
| 方式 | CPU負荷 |
| SPA | クライアント |
| SSR | サーバ |
モバイルではサーバCPUの方が圧倒的に高速なため、
初回表示が改善します。
つまりSSRは過去への回帰ではなく、
端末性能に合わせた合理的な選択です。
CDNとエッジの登場：距離が問題になる
さらに新しい問題が現れます。
サーバCPUは高速でも、物理的距離が遅延を生みます。
ユーザーとサーバが遠いほど、TTFBが増えます。
ここでCDNやエッジレンダリングが使われます。
エッジサーバでHTMLを生成すれば、遅延が減ります。
つまり今度は
CPUの場所
ではなく
計算地点の距離
が最適化対象になります。
RSCの意味：通信量の最適化
React Server ComponentsはSSRの改良のように見えますが、本質は違います。
目的はJavaScript配布量の削減です。
従来のSSRでは、最終的にクライアントで同じコードを実行します。
つまり通信量は減りません。
RSCではサーバで完結する処理をブラウザへ送らないため、
通信量と実行コストが減少します。
これは再び「回線コスト」への最適化です。
つまり歴史が一周しています。
まとめ：フロントエンドは振り子運動
ここまでを整理すると、フロントエンドは次のように動いています。
回線が遅い → サーバ中心
回線が速い → クライアント中心
端末が弱い → サーバへ戻る
通信量が増える → 再分割
これは技術トレンドではなく、
資源コストの最適化です。
技術選定で役立つ視点
新しいフレームワークを選ぶとき、
「どれが人気か」ではなく次を考えると判断しやすくなります。
- 計算はどこで行われているか
- ネットワークはボトルネックか
- 端末性能は十分か
例えば社内システムでは回線が安定しているためSPAが適する場合があります。
一方、公開サイトではSSRや静的生成が有利になることが多いです。
最後に
フロントエンドの進化は複雑に見えますが、
実際には「帯域」と「CPU」のどちらを節約するかを繰り返しているだけです。
フレームワーク名を覚えるより、
どの資源が不足しているかを見る方が長く役立ちます。
技術の流行は変わりますが、
コンピュータの制約は変わりません。
フロントエンドの理解とは、UIの知識ではなく、計算資源の配分を理解することです。
