どんな場合でも最速のアーキテクチャはない
訪問者の近くにあるキャッシュ済みのレスポンスは、HTML がもともとどう生成されたかに関係なく速くなりえます。効率的なクエリを使うサーバーサイドレンダリングのページが、JavaScript を過剰に送る静的ページより速いこともあります。TTFB、コンテンツの鮮度、応答性はそれぞれ別の性質です。
この比較は判断のための枠組みであり、クライアントのシステムのベンチマークではありません。フレームワークのバージョン、ランタイム、ホスティングのアダプター、キャッシュ設定、地理的条件、データアクセスのすべてが結果に影響します。
各方式が行う処理を比較する
| 方式 | HTML が作られるタイミング | 最初に向いている用途 | 慎重に確認すべき点 |
|---|---|---|---|
| SSR | リクエスト時(キャッシュに応じて) | 認証が必要なページやリクエストごとに異なるページ | オリジンの処理、タイムアウト、プライベートキャッシュの境界 |
| SSG | 訪問前、通常はビルド時 | 安定した記事ページやドキュメント | ビルド時間と公開までの遅れ |
| ISR | 生成済みの出力を再利用し、更新する | 古さの許容範囲が限られた公開コンテンツ | 無効化、再生成の失敗、キャッシュのない初回訪問 |
リクエストによって答えが変わるなら SSR を使う
アカウントページや権限によって内容が変わる画面では、リクエスト時の判断が必要になることがよくあります。認証と認可はサーバー側で行い、プライベートなレスポンスが共有キャッシュに入らないようにします。ストリーミング、データのキャッシュ、慎重なクエリ設計で待ち時間は減らせますが、計測の必要がなくなるわけではありません。
SSR だからといって、特定のインフラ費用や必須のクラスター規模が決まるわけではありません。それらは負荷、レスポンスごとの処理、スケーリング戦略によって決まります。
訪問より前に公開できるなら SSG を使う
事前にビルドした HTML は、通常の静的ホスティングや CDN で配信できます。予測どおりに変わるコンテンツには良い出発点です。現実的なビルドにかかる時間と、公開前に編集者が下書きをどう確認するかを確かめましょう。
静的サイトのシステムがすべて、編集のたびに全ページを再ビルドするわけではありません。インクリメンタルビルドの挙動はツールによって異なります。ページの描画だけでなく、画像処理、コンテンツの取得、デプロイ時間もテストします。
限られた古さを許容できるなら ISR を使う
ISR は、生成済みの出力と再生成を組み合わせます。Next.js の Pages Router では、再検証の間隔を過ぎた後のリクエストが更新のきっかけになります。これは、ちょうどその秒に新しい内容を保証するタイマーではありません。再生成の間は、キャッシュ済みの出力が表示され続けることがあります。
実際のホスティング環境で、初回訪問、再生成の失敗、オンデマンドの無効化の挙動を検証してください。API の名前や対応状況は、ルーターやフレームワークのバージョンによって異なります。エッジのランタイムが Node.js のデプロイと同じ再生成機能に対応しているとは限りません。
公開の商品説明はある程度の古さを許容できることが多いですが、正式な価格、在庫、決済の判断は取引のフローの中で確認しなければなりません。古いキャッシュページを購入の唯一の信頼できる情報源にしてはいけません。
再現可能な比較を行う
- すべての実装で、同じコンテンツ、同じ画像、同等の操作の挙動を使います。
- フレームワークのバージョン、ランタイム、サーバーのリージョン、CDN、データベースのリージョン、キャッシュのポリシーを記録します。
- 再生成やオリジンの障害も含め、コールドとウォームのリクエストを別々にテストします。
- 複数の場所から、現実的な同時負荷で計測し、サンプル数とレイテンシの分布を記録します。
- TTFB に加えて、LCP、転送バイト数、操作のトレースを比較します。
- サイトを保守するチームと一緒に、公開、公開取り消し、権限の変更、ロールバックをテストします。
よくある質問
複数の戦略を組み合わせられますか?
はい。ブログ、商品カタログ、非公開のダッシュボードでは、レンダリングとキャッシュのニーズが異なることがあります。その境界を明確に定め、運用モードの数をチームがテストできる程度に抑えましょう。
企業ブログに最適なレンダリング戦略は何ですか?
コンテンツが予測どおりに変わるなら、事前ビルドまたはキャッシュした公開 HTML が良い出発点になることが多いです。適切な選択は、プレビュー、公開までの遅れ、連携、保守にも左右されます。レスポンスの最初の1バイトだけでなく、画像や操作の処理も含めたページ全体でベンチマークしてください。
ISR の再検証間隔を設定すれば、すぐに更新されますか?
いいえ。挙動はフレームワークとデプロイ環境によって異なります。前述の Next.js Pages Router のモデルでは、間隔を過ぎた後のリクエストが再生成のきっかけになり、以前に生成したレスポンスが引き続き提供されることがあります。更新の失敗、キャッシュのない初回訪問、オンデマンドの無効化をテストしてください。
非公開のアカウントページで、公開記事と同じ共有キャッシュを使えますか?
非公開のレスポンスや権限によって変わるレスポンスには意図的な境界が必要で、共有の公開キャッシュから漏れてはいけません。保護された情報を返す前に認可を確定させます。公開の記事ページと認証済みのアカウントページでは、異なるレンダリングとキャッシュのポリシーを使えます。
出典と参考資料
- Next.js:Incremental Static Regeneration(Pages Router)
- Next.js:サーバーサイドレンダリング(Pages Router)
- Google:Web Vitals
あわせて読みたい
ヘッドレスと従来型の WordPress を比較したうえで、パフォーマンス計測の手順を活用してください。




Leave a Reply