SSRのアイソモーフィックJavaScriptを理解する

「アイソモーフィックJavaScript」は“同じコードを2回実行する”という設計のこと

SSRにおける「アイソモーフィックJavaScript」とは何かを一言で説明するなら、サーバとブラウザの両方で同一のJavaScriptコードを実行する仕組みです。

ここが最も重要なポイントです。
SSRは「サーバでHTMLを作る技術」と説明されることが多いのですが、実際にはそれだけでは成立しません。SSRが本当にやっているのは、サーバとクライアントの実行環境を揃え、同じUIロジックを二度実行することです。この考え方を「アイソモーフィックJavaScript（Isomorphic JavaScript）」と呼びます。

なぜSSRはJavaScriptをサーバで実行する必要があるのか

通常のSPAはブラウザでJavaScriptを実行し、DOMを生成します。
一方、SSRは最初のHTMLをサーバで生成します。つまり、ブラウザがやっていた仕事をサーバが代行します。

ここで問題が発生します。
「UIを構築するロジック」はJavaScriptで書かれているため、サーバ側でも同じコードを動かさないと同じ画面が生成できません。

そのためNode.js上でReactやVueを実行します。

function App() {
  return `<h1>Hello</h1>`;
}

このUI生成ロジックは、

• サーバではHTML生成のために実行
• ブラウザではインタラクションのために実行

という二重の役割を持つことになります。
この「同一コードの二重実行」こそがアイソモーフィックJavaScriptです。

SSRの本質：HTMLを返すのではなく“状態を同期する”

多くの人がSSRを誤解するポイントがあります。
SSRの目的は「HTMLを早く表示すること」ではありません。

本当の目的は、サーバとブラウザのUI状態を一致させることです。

SSRではまずサーバがHTMLを生成して返します。

<h1>ユーザー名: Taro</h1>

この時点でブラウザは画面を表示できます。
しかし、ここではまだボタンは動きません。イベントリスナーが存在しないからです。

そこでブラウザ側のJavaScriptが起動します。
同じReactコンポーネントが再度実行され、既存のDOMにイベントを接続します。この処理を「Hydration」と呼びます。

つまりSSRは次の順序で動いています。

• サーバでUIを生成
• ブラウザで同じUIを再構築
• DOMを再利用しイベントだけ接続

この仕組みが成立するためには、サーバとブラウザが同じコードを実行できなければなりません。
これがアイソモーフィックJavaScriptの必要条件です。

なぜ“ユニバーサルJavaScript”ではなく“アイソモーフィック”なのか

似た言葉に「ユニバーサルJavaScript」があります。
両者は混同されがちですが、ニュアンスが少し異なります。

用語	意味
ユニバーサルJS	どこでも動くJavaScript
アイソモーフィックJS	同じ構造・同じ結果を保証するJavaScript

SSRで重要なのは「どこでも動く」ではありません。
サーバとクライアントで同一の結果が出ることです。

例えば次のコードはSSRで問題を起こします。

const now = new Date().toLocaleString();

サーバとブラウザで実行時刻がズレるため、生成HTMLが一致しません。
このときフレームワークは警告を出します。これが「Hydration mismatch」です。

実際に起きるHydration mismatchの原因

現場でよく起きるのは次のパターンです。

• Dateの使用
• Math.random()
• windowオブジェクト参照
• 画面幅依存の分岐

例：

if (window.innerWidth > 768) {
  showSidebar();
}

サーバにはwindowが存在しません。
そのためSSR時とクライアント時でDOM構造が変わります。
これがアイソモーフィックJavaScriptの最大の難所です。

アイソモーフィックJavaScriptが難しい理由

SSR開発が難しいと言われる本当の理由はここにあります。
「サーバとブラウザの差」を常に意識しなければならない点です。

具体的には以下の制約が生まれます。

• DOM APIが使えない（document, window）
• localStorageが使えない
• Cookie取得方法が変わる
• 時刻・乱数が一致しない

つまり、通常のフロントエンド開発とは別の設計思想が必要になります。

それでもSSRが採用される理由

制約があるにも関わらずSSRが使われるのは、得られるメリットが大きいためです。

• 初回表示が速い
• SEOに有利
• クローラが確実に理解できる
• 低スペック端末でも表示できる

特に検索エンジンと相性が良い点が重要です。
HTMLが最初から存在するため、JavaScript実行を待たずにページ内容が取得できます。

向いているケースと向かないケース

SSRは万能ではありません。

向いているケース

• 記事サイト
• ECサイト
• 公開情報ページ
• SEO重視サービス

向かないケース

• 管理画面
• リアルタイムダッシュボード
• 高頻度UI更新アプリ

管理画面では毎回サーバレンダリングすると逆に遅くなることがあります。

最大の注意点：SSRはパフォーマンス最適化ではない

ここが重要な誤解ポイントです。
SSRは「高速化の技術」ではありません。

正確には、初回表示をユーザーに“速く見せる”技術です。

サーバ側ではReactのレンダリングが毎リクエスト発生します。
CPU負荷はむしろ増えます。トラフィックが増えると簡単にボトルネックになります。

つまり、SSRはフロントエンド最適化であり、インフラ最適化ではありません。

結局どう理解すればいいか

SSRを理解する最短ルートは、「HTML生成の技術」と考えるのをやめることです。

SSRの正体は
UIロジックをサーバとブラウザで共有するアーキテクチャです。

そして、その成立条件がアイソモーフィックJavaScriptです。

サーバが画面を描き、ブラウザが同じコードでもう一度描く。
二度描いても壊れないように設計する――ここにSSRの本当の難しさと価値があります。

HTMLを返す技術だと捉えると必ず躓きます。
「実行環境が2つあるJavaScriptアプリケーション」と理解すると、一気に腑に落ちるはずです。