SSRはなぜ速く見えるのか ― プリロードとプリフェッチの正体

「SSRは速い」のではなく「先に始めている」

SSR（Server Side Rendering）はよく「SPAより速い」と説明されますが、厳密には少し違います。SSRはレンダリングが高速なわけではありません。ブラウザより先に通信とリソース取得を始められるため、ユーザーから速く見えるのです。

その中心にあるのが「プリロード（preload）」と「プリフェッチ（prefetch）」です。ここを理解すると、なぜSSRのページ遷移が速く感じるのかが腑に落ちます。

SSRの画面表示で実際に起きている通信

まず、SSRの初回アクセスで何が起きているかを時系列で整理します。

• HTMLをサーバが生成して返す
• ブラウザはHTMLを受信した瞬間にパース開始
• `` を発見
• CSS・JSのダウンロードを即開始
• HTMLの解析と並行してリソース取得が進む

ここで重要なのは、ブラウザがHTMLの解析中に次の通信を始められる点です。

SPAでは最初に取得できるのは空のHTMLとJSバンドルだけです。一方SSRでは、HTMLの中に「次に必要なもの」が書かれているため、ブラウザは迷わず行動できます。

プリロードとは何をしているのか

preloadの役割

プリロードは「このリソースは確実にすぐ使うから、最優先で取ってきてください」というブラウザへの指示です。

<link rel="preload" href="/assets/main.js" as="script">
<link rel="preload" href="/assets/style.css" as="style">

これがあるとブラウザはHTML解析を待たずに通信を開始します。つまりレンダリングの前倒しが起きます。

ここが非常に重要です。通常ブラウザは以下の順序で動きます。

• HTMLを読む
• CSSを見つける
• CSSを取得
• JSを見つける
• JSを取得

しかしpreloadがあると、

• HTMLを受信
• 同時にCSSとJSのダウンロード開始

になります。ネットワークの待ち時間（RTT）を丸ごと1回分削れることがあり、これが「速く見える」大きな理由です。

SPAとの違い

SPAではHTMLに必要な情報が書かれていません。JSが実行されて初めて「次に何を読み込むか」が分かります。

つまりSPAは

「JSをダウンロードして実行するまで、次の通信が始まらない」

という待機時間を持ちます。この差が体感速度の差になります。

プリフェッチがページ遷移を速くする理由

プリフェッチはpreloadと似ていますが目的が違います。

• preload：今すぐ使う
• prefetch：次に使う可能性が高い

例えばSSRフレームワーク（Next.jsなど）は、画面内のリンクを検出すると次のページのJSを裏で取得します。

<link rel="prefetch" href="/_next/static/chunks/about.js">

ユーザーがリンクをクリックした瞬間、既にJSが手元にあります。これがSSRの「ページ遷移が爆速」に見える理由です。

ここで重要なのは、速いのは遷移処理ではなく待ち時間がすでに終わっていることです。

なぜSPAは遅く見えるのか

SPAでもキャッシュが効けば速くなりますが、初回遷移では次の手順になります。

1. クリック
2. ルーターが発火
3. 必要なJSチャンクが決定
4. JSダウンロード開始
5. データAPI通信
6. レンダリング

ここで「クリックしてから通信が始まる」のが問題です。ユーザーは待ち時間を認識します。

SSR+prefetchでは

1. 画面表示中にJS取得済み
2. クリック
3. 即レンダリング

となります。ネットワーク時間がユーザーの操作前に消化されています。

ネットワークウォーターフォールで見る違い

実際のネットワークの流れは次のようになります。

方式	通信開始のタイミング
SSR	HTML受信中にCSS/JS取得開始
SPA	クリック後にJS取得開始

つまりSSRは「並列」、SPAは「直列」になりやすいのです。人間が速いと感じるかどうかは、この直列待ちがあるかで決まります。

よくある誤解：SSRはレンダリングが速い？

SSRは描画自体が速いわけではありません。サーバでHTMLを組み立てているため、CPU時間はむしろ増えます。

速く見える理由は以下です。

• HTMLがすぐ表示される
• 必要なJSを先に取得している
• 次ページの準備が終わっている

つまり「レンダリング速度」ではなく待ち時間の隠蔽です。

リスクと注意点

プリロードは万能ではありません。むしろ使い方を間違えると逆効果です。

• 不要なJSをpreloadすると帯域を圧迫
• モバイル回線で重要リソースが遅延
• LCPが悪化するケース

特に画像やフォントを大量にpreloadすると、本来最優先のCSSが遅れます。SSRが遅いと報告される原因の多くはここです。

prefetchも同様で、通信量制限のある環境ではユーザー体験を悪化させる場合があります。ブラウザは低優先度で取得しますが、ゼロコストではありません。

どう使い分けるべきか

整理すると次のようになります。

• preload：ファーストビューに必要なJS/CSSのみ
• prefetch：次の画面のコード

そしてSSRの価値は「サーバレンダリング」そのものではありません。ブラウザより早く未来の通信を始められることです。

SSRの本質は描画技術ではなく、ネットワーク制御の技術です。ページが速いのではなく、ユーザーが待つ時間を先回りして消しているだけです。

Webパフォーマンスを改善したいなら、SSRかSPAかを議論する前に「通信がいつ始まるか」を見たほうが、実際の改善に直結します。