SSG(Static Site Generation)

ビルド時にAPIの情報などを取得して静的ファイルを作る。アクセス時はその静的ファイルを取得してページを表示。

• https://nextjs.org/docs/pages/building-your-application/rendering#pre-rendering

📖ページ表示方法

1. あらかじめ静的ファイルにビルドしておく
   • API先のデータなどはビルド時に取得し、埋め込まれる（図でいう①APIリクエスト, ②レスポンス（JSON））
2. ユーザーはアクセス時、ビルドされた静的ファイルを取得しWebサイトを表現

💭実装イメージ

• Next.jsではgetStaticPropsなどを読んでビルドする
  • https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation
• https://learn.svelte.jp/tutorial/prerender

➕メリット

• アクセス時は静的ファイルが返るだけなので、レスポンスが非常に早い
• 作成済のHTMLを返すのでSEOに強い

➖デメリット

• ビルド時に全ての情報を取得してビルドするので、コンテンツ量が増えるとビルド時間も増える
• 頻繁に情報が更新されるサイトでは使うことが困難
  • APIが持ってこれるのはあくまでビルド時の状態

✨有名なSSG対応フレームワーク

• React向け:
  • https://nextjs.org/
  • https://www.gatsbyjs.com/
• Vue.js向け: https://nuxt.com/
• Svelte向け: Sveltekit
• https://astro.build/

ISR(Incremental Static Regeneration)

SSGはレスポンスが速いが、ページデータを更新し直すことができない。そこで出てきたのがSSGとSSRの合いの子的な方法。

アクセスされた時にSSGのビルドが実行される。これは一定時間は使い回され、時間経過後は再度ビルドが実行される。

1. ユーザーがページにアクセスする
2. SSGのビルドが走る
3. 生成結果をユーザーに返す
4. 二回目以降はキャッシュされたビルド結果のHTMLが返される
5. キャッシュが古くなったと見なされた場合、裏側でビルドが走り、最新のページになるようにアップデートする

➕メリット

• SSGのレスポンス速度を得つつ、データ更新が可能
• アクセスしたページしかリビルドされないため、全ページリビルドする時間を考えなくて良い

➖デメリット

• ページ更新タイミングがキャッシュに左右されるため、更新タイミングが予測しづらい
• 複数台のサーバがある場合、キャッシュ共有の仕組みが必要

Partial Prerendering

部分的に動的なコンテンツと静的なコンテンツを使い分ける。

• 動的なコンテンツはspinnerとかにしておいて、ロード終わったら表示

Next.jsはすぐアップデートされるので、頭に入れておくと良さそう。

• https://nextjs.org/learn/dashboard-app/partial-prerendering#what-is-partial-prerendering
• https://zenn.dev/akfm/articles/nextjs-partial-pre-rendering

以上の話を元に、歴史について少し。