Streaming SSR（ストリーミングSSR）は、サーバが生成したHTMLを「全部できてから一気に返す」のではなく、出来上がった部分から順次チャンクに分けて送り出すレンダリング手法です。Reactは2022年3月に正式リリースされたReact 18でrenderToPipeableStreamとSuspenseを組み合わせたStreaming SSRを正式サポートし、Next.js App Router（2023年5月安定版）でも標準モデルになりました。上流APIが遅くてもページ全体の表示が止まらない、というユーザー体験上の大きな改善が得られます。
この記事の目次
- Streaming SSRの動作モデル
- Streaming SSRが解く3つの問題
- 実装上のチェックポイント
- 従来SSRとの比較
- まとめ
Streaming SSRの動作モデル
Streaming SSRの内部動作は4段階で整理できます。まずサーバはページの「シェル」と呼ばれる骨格部分（ヘッダ・ナビ・本文の枠など、すぐ確定できる箇所）を生成して、レスポンスのチャンクとしてブラウザへ送り出します。この時点で空のHTMLではなく実物の枠組みがブラウザに到着するため、FCPが大幅に改善されます。
次にデータ取得が必要な部分はReactのSuspenseで「待ちポイント」として宣言され、サーバはその領域だけプレースホルダ（スピナーやスケルトン）を埋めたまま先に送信します。上流APIから値が返ってきた瞬間に、サーバは追加のHTMLチャンクを生成して同じHTTPレスポンス内に書き足します。ブラウザはチャンクが届くたびに該当領域を更新するため、ユーザーから見ると「ヘッダはすぐ出る、本文は遅れて出る、レコメンドはさらに遅れて出る」という段階的な表示になり、全データが揃うのを待つ従来型より体感速度が劇的に良くなります。
Streaming SSRが解く3つの問題
Streaming SSRが従来のSSRから前進した点は3つに整理できます。1つ目は初動（First Byte以降）の早さで、シェル部分を先に送るためブラウザがレンダリングを始めるまでの時間が短くなります。従来は全データが揃うまでサーバが応答を保留していたため、上流APIが3秒遅いとブラウザにも3秒間真っ白な時間が生じました。Streaming SSRなら100ms以内でシェルが届き始め、ユーザーは即座にナビゲーションを認識できます。
2つ目は耐遅延性で、複数の上流APIに依存する画面で「一番遅いAPI」に引きずられなくなります。高速なAPIから返ったデータの領域は先に表示され、遅いAPIはSuspenseの境界内でスケルトンのまま残るため、影響が局所化されます。3つ目は段階表示による体感速度の向上で、人間は「動いている画面」を認識すると待ち時間を短く感じるため、「数秒の真っ白」より「1秒以内に部分表示」の方が圧倒的にユーザー満足度が高いと知られています。Eコマースのレコメンドやニュースの関連記事のような「あれば嬉しいが遅くても良い」要素にStreaming SSRは特に有効です。
実装上のチェックポイント
Streaming SSRを導入する際は、まずSuspenseの境界設計が最大のポイントです。「どの領域を待ちポイントにするか」を決めることで、シェルに含める部分と後出しで埋める部分が分かれます。ナビゲーション・パンくず・タイトルなど直ぐ確定する要素はシェル側に置き、レコメンドやレビュー、外部API依存の領域はSuspense境界の中に置くのが基本セオリーです。
次にエラーハンドリングです。Suspense境界内で例外が起きた場合のerrorBoundaryを明示しておかないと、ストリーミング中にエラーが起きると不完全なHTMLが残ってしまうリスクがあります。またCDNやリバースプロキシによってはストリーミングを許可しない設定が初期値の場合があり、Cloudflare WorkersやVercel Edge、Fastlyなどでは事前確認が必要です。OGPやtitleなど検索クローラが先頭で読むメタタグは必ずシェルに含め、計測指標もTTFB単体ではなくFCPやINPなど段階表示を反映したものに切り替える必要があります。
従来SSRとの比較
Streaming SSRと従来SSRの違いは、レスポンスの送り方とそれが体感速度に及ぼす影響に集約されます。従来型は「全データ揃ってからHTML一括送信」なので、もっとも遅い上流APIに引きずられて画面全体の表示が遅れます。Streaming SSRは「できたところから順次送信」なので、シェル＋早いデータの領域は先に出て、遅いデータの領域だけ追加で更新されます。結果としてFCPやLCPなどの指標がほぼ確実に改善されます。
ただし実装側にはSuspenseの境界設計、errorBoundary、CDNの設定確認などのコストが発生します。Reactなら18以降、Vueなら3.5以降、Next.jsなら13以降のApp Router、Nuxtなら3で標準採用、SvelteKitもサーバストリーミングを実装しており、現代の主要フレームワークでは「Streaming SSRがデフォルト、必要なら無効化する」という方向性に揃いつつあります。従来SSRからの移行は段階的に行えるため、まずはレコメンド領域だけをSuspenseで囲むところから始めると体験を改善しやすく安全です。
まとめ
Streaming SSRはReact 18（2022年）以降に主要フレームワークが標準採用したレンダリング手法で、HTMLをチャンク単位で順次送出することで初動と体感速度を大きく改善します。Suspenseによる境界設計と段階表示の発想が組み合わさり、上流API遅延の影響を局所化できる点が現代Webにとって決定的な進歩でした。従来SSRからの移行は段階的に行えるため、レコメンドや関連記事領域から導入を始めるのが現実的な第一歩です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント