レンダリング
レンダリング方式は、更新頻度、公開範囲、SEO、認証、ホスティング環境から選びます。特定の方式をサイト全体へ一律に適用しません。
選択基準
内容がビルド時に確定する公開ページは、Static GenerationまたはStatic Exportを最初に検討します。リクエストごとに内容が変わる公開ページやSEO対象は、Server Renderingを検討します。
認証後の業務画面はSPAを基本とし、必要な箇所だけサーバーレンダリングを組み合わせます。一定の更新間隔を許容できる公開コンテンツは、ホスティング要件を確認してキャッシュや再検証を選びます。
静的サイトだからすべてをClient Componentにする、認証画面だからすべてをSPAにする、といった決め方はしません。ページや機能の境界ごとに判断します。
Server ComponentとClient Component
Next.jsを採用するプロジェクトではServer Componentを基本とし、操作、ブラウザAPI、クライアント側stateが必要な境界だけをClient Componentにします。"use client"をページ全体へ広げず、対話部分を小さく切り出します。
SSRを使う画面では、初期表示に必要なデータをサーバーで取得できるか先に検討します。SPAでは認証後にAPIから取得し、再取得、キャッシュ、楽観的更新をプロジェクトで採用しているデータ取得ライブラリへ任せます。
Next.jsのStatic Export
このサイトのように、公開内容と経路をビルド時に確定できる場合はNext.jsのoutput: "export"を使います。リクエスト時のCookieやHeader、Server Actions、ISRなど、サーバー処理を必要とする要件がある場合は選びません。対応機能の一覧は利用中のバージョンの公式資料を正本とします。
必要なレスポンスヘッダーやキャッシュは、静的ファイルを配信するホストまたはアダプター側で設定します。フレームワークの設定例を流用せず、実際に配信されたレスポンスを確認します。
TanStack StartのSPA mode
弊社の社内プロダクトであるHIRACTでは、TanStack StartのSPA modeを有効にし、個別経路のprerenderは行いません。検索エンジン向けのHTMLより、認証後の操作、クライアント側routing、サーバーデータの再取得を重視する業務画面に適用します。
SPA modeでも、API、server function、server routeなどのサーバー機能は利用できます。画面の到達制御だけを認可の根拠にせず、APIとApplicationで読み書きを拒否します。配信時は静的assetを優先し、未知の画面経路をSPA shellへrewriteできることを実環境で確認します。
Hydration
サーバーと最初のクライアントレンダーは、同じ入力から同じHTMLを生成します。時刻、乱数、ブラウザストレージ、画面サイズなどに依存する処理は、安定した初期値を用意したうえで、利用者の操作ならイベント、外部システムとの同期ならEffect、外部storeの購読ならuseSyncExternalStoreで扱います。
Hydration warningを非表示にして差異を放置しません。避けられない局所的な差異だけに抑制を限定し、なぜ安全かを明らかにします。
キャッシュ
RSCや認証情報を含む応答は、経路、Cookie、Header、Vary、CDN設定を含めて確認します。開発サーバーの挙動だけで判断せず、デプロイ先から新しいレスポンスを取得してキャッシュキーと公開範囲を検証します。