jQuery→SPA→SSR→RSC移行のボトルネック

フロントエンド SPA SSR React アーキテクチャ

フロントエンドは流行ではなく「ボトルネック移動」で変化している

jQueryの時代、SPAの時代、SSRの時代、そしてRSC。
フロントエンドは何度も大きく変化してきましたが、これは技術トレンドが移り変わっているからではありません。

実際には、毎回違う問題を解決するためにアーキテクチャが変更されてきただけです。

つまり

jQuery → SPA → SSR → RSC

は世代交代ではなく、
「ボトルネックが移動した履歴」です。

それぞれの段階では、解決すべき課題が明確に存在していました。

jQueryが解決した問題：ブラウザ差異

2000年代後半、最大の問題は「同じJavaScriptが動かない」ことでした。
Internet ExplorerとFirefoxでDOM操作やイベント仕様が異なり、Webアプリの実装は困難でした。

例えばイベント処理です。

document.getElementById("btn").onclick = function(){};

当時はこれがブラウザによって挙動が違いました。
jQueryはこの差を吸収します。

$("#btn").on("click", function(){});

jQueryの本質はUI操作ではありません。
ブラウザ互換レイヤーです。

しかしAJAXの普及により、別の問題が現れます。

次のボトルネック：状態管理の崩壊

ページ遷移せず画面を更新するアプリが増えると、DOMを直接操作する設計は破綻します。

起きた問題は次のようなものです。

  • リスト削除すると別の表示が壊れる
  • モーダルを閉じると別画面が更新されない
  • カウンターがズレる

これはDOM操作の問題ではなく、
アプリケーション状態を人間が管理していたことが原因です。

jQueryでは、UIの正しさをコードではなく開発者の記憶に依存していました。

ここで登場したのがSPAフレームワークです。

SPAが解決した問題：状態管理

ReactやVueはDOM操作ライブラリではありません。
アプリケーション状態の管理モデルです。

核心は次の考え方です。

「状態が決まればUIは一意に決まる」

つまり画面を直接変更するのではなく、状態を変更します。

setCount(count + 1);

この1行により、UI更新が自動で行われます。
Virtual DOMは手段であり、本質ではありません。

これにより画面の整合性問題は大幅に減りました。

しかしSPAにも新しい問題が現れます。

SPAのボトルネック：初回表示

SPAはブラウザでアプリを実行します。
そのためページ表示前にJavaScriptの読み込みと実行が必要です。

表示までの流れです。

1. HTML取得
2. JSダウンロード
3. JS実行
4. DOM生成
5. 画面表示

ここで発生したのがLCP悪化とSEO問題です。
モバイル環境では特に顕著になります。

つまりボトルネックが
ブラウザCPUとネットワークへ移動しました。

SSRが解決した問題：描画位置

SSR（Server Side Rendering）は、描画処理をサーバに移動します。

方式 描画場所
SPA ブラウザ
SSR サーバ

サーバでHTMLを生成し、ブラウザはそれを表示するだけになります。
これにより初回表示が大幅に高速化します。

SSRの目的はSEOではありません。
レンダリング計算をユーザー端末からサーバへ移すことです。

しかしSSRでも問題は残りました。

SSRのボトルネック：不要なJavaScript

SSR後も、クライアント側でHydrationが必要です。
つまりHTMLはサーバが作っても、最終的には同じJavaScriptが配布されます。

ユーザーが触らないUIまでJSが送られるため、次の問題が発生します。

  • モバイルで重い
  • 実行時間が長い
  • メモリ消費が増える

ボトルネックが「レンダリング」から「JavaScript配布量」に移動しました。

RSCが解決しようとしている問題

React Server Components（RSC）はここを改善します。

  • インタラクションが必要な部分だけクライアントJS
  • それ以外はサーバコンポーネント

つまり、全コンポーネントをブラウザで実行しません。

従来のSSR：

サーバでHTML生成 → ブラウザで再実行

RSC：

サーバで完結する部分はブラウザに送らない

これはSSRの改良ではなく、
実行場所の最適化です。

よくある誤解

新しい技術が出ると、古い技術が無価値になると考えられがちです。
しかし実際にはそうではありません。

例として、管理画面のような社内ツールではSPAの方が適することがあります。
ネットワーク遅延やSEOが重要でないためです。

つまり

  • jQueryが劣っていた
  • SPAが失敗した
  • SSRが正解

という関係ではありません。

解決対象が違うだけです。

技術選定の注意点

実務でよくある問題は、課題と技術が一致していないケースです。

例えば次です。

  • 小規模サイトにSSR導入
  • 静的サイトに複雑な状態管理
  • 社内ツールに過度な最適化

これらは「必要なボトルネックが存在しない」状態です。
技術は万能ではなく、特定の問題に対する解です。

最後に

フロントエンドの歴史はフレームワークの歴史ではありません。
性能問題の歴史です。

ブラウザ差異
→ 状態管理
→ 初回表示
→ JavaScript配布量

と問題が移動するたびに、最適なアーキテクチャが変わってきました。

新しい技術を選ぶ基準は「新しいから」ではなく、
「今のシステムのボトルネックは何か」です。

フロントエンドの理解とは、フレームワーク名を覚えることではありません。
どこで時間と計算資源が使われているかを見極めることです。