こんにちは、シンハラです。
普段はmicroCMSでテクニカルセールスとカスタマーサポートを行なっております。

microCMSは単体では活用できないサービスとなるので、フロントエンドのフレームワークを組み合わせて構築を行う必要があります。私が参加しているセールスの打ち合わせでも、当然利用するフレームワークのお話が出てくるのですが、最近はNext.jsの利用を検討されるケースが増えていると感じます。

Next.jsはVercel社が開発しているReactベースの高機能フロントエンドフレームワークで、OSSとして公開されています。

Next.jsは高機能で使いやすい一方で、慣れるまでは全体像が掴みづらいという部分があります。特に、静的サイトジェネレーターとしても動作するし、バックエンドのプログラムとしても動作するという点が、初めて利用するユーザーにとっては非常に混乱を招く点となっております。

今回はNext.jsの2つのページレンダリング機能に焦点をあてて、ご紹介したいと思います。

ページレンダリングの2つの方法

SG(Static Generation)とは？

SSG(Static Site Generation)、静的サイトジェネレートと呼ばれることもあります。いわゆるJamstackとよばれる作り方に関しても、こちらのSGが該当します。

こちらの手法は、ビルド時にヘッドレスCMS等のAPIにリクエストを送り、受け取ったデータから事前にページを生成する方法です。特徴はスタティック（静的）なページとして生成されるため、CDNに配置することができ、ページ表示にあたって高いパフォーマンスを発揮します。Next.jsのドキュメントにおいても、基本的にはこちらのレンダリング手法が推奨されています。

一方でデメリットもあります。大量のページがある際には、ビルドに時間を要すため、データの更新から反映までに、タイムラグが発生してしまいます。またデータの内容が動的に変化していく場合だと、ページのアクセスごとにレスポンスを作り直す必要があるので、不向きになります。

SSR(Server Side Rendering)とは？

SGの対になる方法がSSRです。SSRは、アクセスのたびにデータフェッチを行い、ページを生成する手法になります。WordPressのようなバックエンドで動作するプログラムと同じような動きとなります。

こちらの手法の場合は、コンテンツ更新するたびにビルドを行う必要がありませんので、大量のコンテンツを管理する場合に向いています。またヘッドレスCMSでデータ更新を行なった際に、即時にページにもデータを反映させることができるので、速報性が重視されるコンテンツにも活用できます。

デメリットとしては、アクセスのたびに処理を行うため、アクセス数に応じて、サーバへの負荷が上昇します。そのため、負荷分散の仕組みを構築するか、サーバレスなアーキテクチャで動作させるなどの工夫が必要となります。またパフォーマンス面においては、SGには劣ってしまいます。

このようにSG/SSRには、メリット/デメリットが存在しているため、利用用途に応じて適切に使い分ける必要があります。

実際にSGとSSRを動かしてみよう

それでは実際にSGとSSRを利用するコードを書いてみましょう。
Next.jsの大きな特徴として、一つのプロジェクトの中で、SGとSSRを混在して利用することができる、という点があります。今回は実際に、1ページずつSGとSSRで作成してみたいと思います。

以下にサンプルのソースコードを配置しております。
https://github.com/Sinhalite/sg-ssr-demo

今回は/sgと/ssrというページを作成し、それぞれ以下のように記載しております。（一部コードのみ抜粋）

SG

// pages/sg.js
export async function getStaticProps() {
  const random = Math.floor( Math.random() * 100 );
  return {
    props: {
      random,
    },
  }
}

SSR

// pages/ssr.js
export async function getServerSideProps() {
  const random = Math.floor( Math.random() * 100 );
  return {
    props: {
      random,
    },
  }
}

内容としては、0〜99の乱数を作成し、ページのPropsとして渡しています。異なっているのは、関数名のみです。
getStaticPropsを利用した場合はSG、getServerSidePropsを利用した場合はSSRでレンダリングされるようになっています。

実際にVercelにプログラムをデプロイしているので、そちらで動作を確認してみましょう。

まずSGで動作しているのが以下のURLです。
https://sg-ssr-demo.vercel.app/sg


静的に生成されているため、乱数はビルド時に生成された数字が固定して表示されます。今回の場合は、48が表示されてますね。これはページをリロードしても、必ず同じ数字が表示されます。

一方SSRで動作しているのが以下のURLです。
https://sg-ssr-demo.vercel.app/ssr


こちらはアクセスのたびに、乱数を生成する処理が行われるため、人によって異なる数字が表示されます。ページをリロードするとまた新しい数字が表示されます。

今回は乱数を表示させる簡単なプログラムでしたが、なんとなく動作のイメージはつかめましたでしょうか？
SGの方がSSRより表示スピードが速いという点も、こちらのデモで確認いただけると思います。

実際の案件で考えると、例えばユーザーの認証状態によって出しわけが必要なページはSSR、共通のお知らせページはSGといった使い方ができそうですね！

補足

開発用サーバーを起動するコマンド(next dev)を利用した場合は、getStaticPropsを利用した場合についても、SSRの動作となります(表示のたびに数字が変わる)。この仕様は開発のタイミングで、ソースコード変更のたびにビルドを実行していると、開発効率が悪いためと推測されます。今回のチュートリアルをローカルで動作確認する際は、next build→next startの手順で実行しましょう。

おわりに

以上、Next.jsのSGとSSRの違いについての記事でした。SSRを使ってNext.jsを利用しているケースはまだまだ少ない気がします。もしmicroCMSとNext.jsのSSRを活用して、大規模なウェブサイトを運用されている事例がありましたら、ぜひ参考にできればと思いますので、お声がけいただけると嬉しいです🙌

-----

microCMSは日々改善を進めています。
ご意見・ご要望は管理画面右下のチャット、公式Twitter、お問い合わせからお気軽にご連絡ください！
引き続きmicroCMSをよろしくお願いいたします！