SSRのストリーミングレンダリングは何を速くするのか

SSR（Server Side Rendering）の進化として、近年よく登場するのが「ストリーミングレンダリング」です。React 18以降やNext.jsで特に強調される機能ですが、ここで誤解されがちなのが「HTML生成が高速化された」という理解です。

実際には違います。ストリーミングレンダリングはサーバの処理を高速化しているわけではありません。ユーザーが待っている時間の見え方を変えています。
具体的には「ページが完成するまで待たせる」から「できた部分から見せる」へ変えています。

従来のSSRは次の手順でした。

1. データ取得（DB/API）
2. テンプレート描画
3. HTML完成
4. ブラウザへ送信
5. 画面表示

ここで重要なのは、HTMLが完成するまで1バイトも送られない点です。

たとえばページ内に次の3つのデータがあるとします。

従来SSRでは、最後の「900ms」が終わるまでブラウザは何も受け取れません。ユーザーから見ると「白い画面が続く」状態になります。

この待ち時間はTTFB（Time To First Byte）として計測されます。

ストリーミングレンダリングはHTMLを分割して送ります。

1. ヘッダー完成 → 即送信
2. 記事一覧完成 → 送信
3. おすすめ商品完成 → 最後に送信

つまりHTMLを1つのファイルとして扱わず、「データの流れ（stream）」として扱います。

HTTP/1.1 200 OK
Transfer-Encoding: chunked

chunked転送では、サーバはHTMLを完成させる必要がありません。生成した瞬間に送れます。

ここで初めて「SSRの表示が速い」と感じる体験が生まれます。

ストリーミングレンダリングが改善している指標は次の通りです。

逆に改善していないものもあります。

つまり処理時間は同じでも表示開始が早くなるのです。

ReactのSuspenseはストリーミングとセットで使われます。遅いデータを待たず、仮のUIを先に出します。

例：

ユーザーは「表示されている」と認識します。実際には裏で処理が続いています。

ここで重要なのは、ユーザーは処理完了を待っていないという点です。人間は「何も表示されない時間」に敏感で、「変化がある状態」には寛容です。

SPAの初期表示は次の順序になります。

1. JSダウンロード
2. JS実行
3. API通信
4. 描画

最初の描画はJSとAPIの両方を待ちます。

一方ストリーミングSSRでは、

1. HTML受信
2. 即描画開始
3. JSとデータは後追い

になります。ここが本質的な差です。
描画が通信を待つか、通信が描画の後に続くかの違いです。

ストリーミングレンダリングにもリスクがあります。

特にCDNキャッシュは「完成HTML」を前提とするため、ストリーム出力は扱いづらくなります。また、検索エンジンのクローラが必ずしもストリームを完全解釈するとは限りません。

さらに重要な点として、JavaScriptのハイドレーションが遅いと体感は逆に悪化します。表示はされているのに操作できない状態（インタラクション遅延）が発生します。

従来のSSR
「完成したページを送る」

ストリーミングSSR
「生成中のページを送る」

ここでSSRの役割が変わっています。サーバはHTMLを配布する装置ではなく、ブラウザの描画を先導する存在になっています。

ページ表示速度の改善とは、CPU処理を短縮することではありません。ユーザーが何を待っていると感じるかを制御することです。

ストリーミングレンダリングはパフォーマンス最適化というより、UX設計に近い技術です。Webの高速化は「速く計算する」から「先に見せる」へ移行しています。