ISR 再インプット

ちょっと前に Next.js の v12.2 が出たが、そのときに出た On-Demand ISR の部分で自分の ISR の認識がちょっと怪しかったのでもう一度インプットすることにした。

ISR の話は SSG と切り離せず深い関係にあるので、上記の記事に書いてあるとおりのことを書くと

SSG はビルドの時点ですべてのパスの HTML を生成するよ
- 外部 API などを使っている場合はそこから取得するので、 HTML 手書きとは違うよ
fallback: false にすると、生成していないパスにアクセスが来たときは 404 を返すよ
fallback: true にすると、生成していないパスにアクセスが来たときにまずデータ取得部分が欠けている不完全な HTML が返されて、クライアントでデータフェッチが行われて HTML が再構成されて、かつサーバー側でも同様の処理が行われて HTML が生成されるよ
- これは初回アクセス時の挙動で、それ以降のアクセスではサーバー側で生成された HTML を返すので、対象のパスは fallback: false と同じような挙動になるよ
fallback: 'blocking' にすると、フォールバックをブロックするので、生成していないパスにアクセスが来たら、不完全な HTML を返すのではなくサーバー側でそのパスに必要なデータフェッチを行い、完全な状態の HTML になってからサーバーから HTML がクライアントに渡されるよ
- これは初回アクセス時の挙動で、それ以降のアクセスでは対象のパスは fallback: false と同じような挙動になるよ

という感じでした。

SSG では、ビルド時や初回リクエスト時に HTML を生成して、それ以降のアクセスではキャッシュを使い回すので、データフェッチするデータそのものの変更に弱い。

データが変更された場合は再ビルドしないと新しいデータを取得した HTML が返せないので、動的なデータへの対応が難しい。

ISR は、それを解決するための機構。

ISR の挙動は、

revalidate に設定している秒数の間は SSG と同様の挙動でキャッシュを返す
設定している秒数を過ぎたあとに初めてリクエストがあったときに、キャッシュを返しつつサーバーでデータフェッチして HTML を再構築し、次のリクエスト以降は再構築した HTML のキャッシュを返す
これを繰り返す

ということなので、 revalidate に指定する秒数によって HTML の再構築頻度も変わる(が、リクエストが来ないと再構築されない)ので、秒数の指定をどれくらいにするか考えるのが難しそう。

また、指定秒数後の最初のリクエストは最新のデータではない状態のキャッシュが使われるので、初回リクエストしたユーザーには古い情報が見えてしまう。

そして、 On-Demand ISR は HTML の再構築を任意のタイミングで行うことができるようになったので、コンテンツ更新時にその更新に hook して revalidate を発火させることで再構築ができる。

この認識で合っているはず……！