デイトラモダン開発編　DAY31 「SSR」「SSG」「ISR」の動きを確認しよう

比較

fetchが動くタイミングが違う！

SSR：常に最新の状態

標準の仕様。（毎回feachする）

メリット	デメリット
常に最新の情報を取得ができる （管理画面の投稿を変えると即反映）	ページスピードが遅くなる可能性がある

SSG：build時にページの表示（形）が決まる

build時のページが表示。
以下のコードを追加したページがSSGになる（他のページはSSRのまま）。

export const dynamic = "force-static"; //一番上に記述

※記述場所の例：/news/id/page.tsx（お知らせの記事ページ）

メリット	デメリット
表示スピードが早い （毎回フェッチの取得がないため）	最新の更新内容を受け取れない

「buildすれば更新される」ため、WordPress更新のタイミングに合わせて、buildを動かす仕組みにすれば、WordPressの更新に近いタイミングで、Next.jsのサイトもWordPressのサイトの内容を反映できるようになる。

ISR：秒数が経過したら最新のページが表示

SSRとSSGの間。
一度フェッチしたら「何秒間」はキャッシュが残る。
キャッシュの時間がすぎたら、またフェッチしに行く仕組み。（秒数は自分で決められる）

「何秒間」かはWordPressの更新が反映されない。

メリット	デメリット
・SSRに比べると、サーバーの負荷が減り、APIの利用回数が減る ・キャッシュしている間はSSGのようになるので、表示スピードも早くなる	・キャッシュの期間はWordPressが更新されない

WordPressの更新頻度に合わせて秒数を設定するのがおすすめ！

SSGもWordPress記事更新のタイミングでページ反映可能

プラグイン：Webhookを使用すれば可能。

Webhookの仕組みを使うと、WordPressを更新→Vercelに通知→Vercelがbuildとdeployを行う
=投稿の記事を更新すると、buildとdeployが動くようになる！

【結果】記事を更新すると、サイトにWordPressの更新内容が反映される！

多くのホスティングサービスでは、buildの時間や回数で料金が決まる。
更新によってどれくらいbuildが発生するか？発生したbuildの時間や回数によってどういった料金になるか？を検討する必要がある。

buildの回数が増えるのはデメリットだが、サイトの表示スピードは早くなる利点もある。

以上が、webhoockを使ったCMS連携方法でした。