SSRで何が変わるか
SSRでは、最初のマークアップの生成がサーバーに移ります。ブラウザーはHTMLを受け取り、その後JavaScriptがインタラクティブなコンポーネントをハイドレートすることがあります。SSRは、静的生成、キャッシュ、速いTTFB、インデックス登録の成功と同じ意味ではありません。
確かめるのは、フレームワークの設定ではなく、実際のURLが返すレスポンスボディとステータスです。
レスポンスを確認する
JavaScriptを無効にするか、生のfetchで、最初のHTMLを確認します。ハイドレーションの前の状態で、ステータス、canonical、主要なテキスト、エラー時の挙動を見ます。
- 最初のHTMLを取得する。
- 存在しないルートを試す。
- 生のコンテンツとレンダリング後のコンテンツを比べる。
- TTFBは別に計測する。
- キャッシュのバリエーションを試す。
レンダリング方式を選ぶ
リクエスト時点のデータやパーソナライズが必要で、オリジンが安定して応答できる場合に、SSRを使います。更新の少ない公開ページには、静的出力やキャッシュ済みの出力のほうが向いていることがあります。
| 確認したいこと | チェック | 限界 |
|---|---|---|
| 最初のコンテンツ | レスポンスのHTMLに含まれている | HTMLがあるだけでは品質は保証されない |
| エラーのルート | 正しい404/410/500のステータスを返す | クライアント側のUIがステータスを隠すことがある |
| パフォーマンス | TTFBとアセットを別々に見る | 1つのスコアでは各層が見えない |
SSRの限界
サーバーでレンダリングしたページでも、表示が遅い、エラーを返す、後からのクライアント側の呼び出しの先にコンテンツが隠れる、といったことは起こります。
実際のHTTPレスポンス、HTML、エラー時の状態を確認するまでは、そのルートのSSRを完了と見なさないでください。
FAQ
SSRにすれば、Core Web Vitalsは良くなりますか？
いいえ。オリジンの処理時間、HTMLのサイズ、アセット、クライアント側の処理は、別々に計測する必要があります。
SSRになっているかは、どう確認しますか？
代表的なルートについて、最初に返るHTMLそのままの内容とHTTPステータスを確認し、レンダリング後のページと比べます。
SSRのルートがソフト404を返すことはありますか？
はい。デザインされたエラー画面でも、適切なHTTPステータスは返す必要があります。