Nuxtはprerenderの設定も必要
Nuxtのレンダリング設定というと、多くの人がまず思い浮かべるのは
ssr: true(SSR)ssr: false(CSR)
の2択だと思います。
しかし実際には、Nuxtにはもう1つ重要な選択肢があります。それがprerender(事前レンダリング)です。
この記事では、なぜSSR/CSRの2択だけでは不十分なのか、prerenderがどう解決するのかを解説しています。
SSRとCSRだけでは足りない理由
SSR(ssr: true)にはアクセスのたびにサーバーがレンダリングするという弱点があります。
SSRは初回表示が速く、SEOにも強いというメリットがありますが、リクエストが来るたびにサーバー側でVueコンポーネントをレンダリングし直すという仕組みです。
/about のような、いつ誰がアクセスしても内容が変わらない静的なページであっても、SSRの設定のままだと毎回サーバーがレンダリング処理を行います。
そのため、すべてのページがSSRだと以下のデメリットがあります。
- サーバーの負荷が増える
- レスポンスタイムが遅くなる
- サーバーが落ちていたら表示すらできない
SSRではなくCSRを使用するデメリット
一方でCSR(ssr: false)は、サーバー側の負荷は下がりますが、SEOに弱く、ブラウザがJavaScriptの読み終了まで画面が見えないというデメリットがあります。
/about のような静的なページをCSRにしてしまうとSEOで不利になったり、初回表示が遅く感じられたりします。
prerender: trueで解決できる
/about ページのように内容が変わらない静的ページに最適なのがprerender: trueの設定です。
prerenderはビルド時にそのページのHTMLをあらかじめ生成しておき、静的ファイルとしてサーバーに配置しておく仕組みです。
export default defineNuxtConfig({
routeRules: {
'/about': { prerender: true }
}
})こうしておくと、nuxt buildの時点で/aboutのHTMLが生成され、以降はリクエストのたびにVueコンポーネントをレンダリングし直す必要がなくなります。
サーバーは単に生成済みの静的HTMLファイルを返すだけになるため、
- サーバーの負荷がほぼゼロになる
- レスポンスが極めて高速になる
- SEO用のHTMLも最初から完成した状態で配信される
という、SSRとCSRのどちらの弱点も踏まえた形で解決されます。
SSR・CSR・prerenderの使い分け
NuxtのrouteRulesを使うとページ単位でレンダリング方式を切り替えられます。
これは「ハイブリッドレンダリング」と呼ばれる考え方です。
下記のように、ページの性質に応じて最適なレンダリング方式を個別に選べるのがNuxtの強みです。
export default defineNuxtConfig({
routeRules: {
// 高頻度で更新されるトップページはSSR
'/top': { ssr: true },
// 管理画面はSEO不要なのでCSRのみでOK
'/admin/**': { ssr: false },
// 内容が変わらない静的ページはビルド時に生成
'/about': { prerender: true },
'/terms': { prerender: true },
'/blog/**': { prerender: true },
}
})※ { ssr: true } を /top に設定していますが、デフォルトは { ssr: true } なので省略可能です。
「SSRにするかCSRにするか」という2択だけで考えるのではなく、「このページはprerenderにする」という判断も重要になります。
どのページをprerender: trueにすべきか
以下のような更新頻度の低いページはprerender: trueが適しています。
- 会社概要
- 利用規約
- プライバシーポリシー
- ランディングページ
- ブログ記事
まとめ
- SSRは毎回サーバーでレンダリングするため、静的なページに使うと無駄が多い
- prerenderを使えばビルド時にHTMLを生成しておき、リクエスト時の負荷をなくせる
- NuxtのrouteRulesを使えば、ページごとにSSR・CSR・prerender・ISRなどを自由に組み合わせられる
- 「SSRかCSRか」ではなく、「このページの性質に合ったレンダリング方式は何か」という判断が重要



