Next.jsをデプロイするとき、静的ホスティングかSSRかを決める基準

Next.jsで作成したアプリケーションをデプロイするとき、デプロイの方法として以下の2つがあります。

(A) 静的ファイルを出力し（next export）、静的ホスティングする
(B) SSRできる環境へデプロイ（next build && next start）

この2つのうち、どちらのデプロイ方法を採用するべきか、毎回悩んでいるような気がしたので、一度まとめておきます。

静的ホスティングかSSRかを決める基準

結論から言うと、基準は 動的な公開ページがあるかどうか です。

動的な公開ページがある場合は、(B) のデプロイ方法（SSR）を採用します。
それ以外は、(A) のデプロイ方法（静的ホスティング）で良いです。

ちなみに、ここでの「動的な公開ページ」というのは、「認証なしで誰でもアクセスでき、コンテンツがアクセスの度に更新されている可能性のあるページ」のことを指します。

動的な公開ページがある場合は、SEOやOGPの観点から、SSRが必要になります。
（厳密に言うと、コンテンツ元データの更新を自動検知して、その度にビルドして静的ホスティングすればSSRは必要ないのですが、ここでは取り上げません。）

動的な公開ページは一般的に、Google検索に表示させたり、SNS上でOGPを表示する必要がある ので、SSRでレスポンス自体にOGPタグやコンテンツを入れておく必要があります。

一応、Googleのボットなどは、jsを実行した結果をクローリングしているらしいですが、どこまで本当なのかは正直分からないので、個人的にはSSRで対応した方が良いのではと思っています。

ちなみに、このSEO/OGPの対策として、「静的ホスティングをした上で、その前にサーバなどの処理をはさみ、そこで『特定のユーザーエージェントの場合は動的にページを生成してレスポンスを返す』」という対策も、できないことはないのですが、各SNSごとのユーザーエージェントを調査・管理する必要があるため、個人的にはあまり好きではありません。

管理画面などの、一部のユーザーのみが使用できるページに関しては、SEOやOGPを考慮する必要はありませんので、SSRする必要はなく、静的ホスティングをするのが良いかと思います。

まとめ

ということで、動的な公開ページがある場合にはSSR、そうでない場合には静的ホスティングという切り分けが、個人的には良いかと思っています。

次回は、SSRと静的ホスティングで個人的によく使うデプロイ先をまとめたいと思います。