Incremental Static Regenerationとは？静的ページを更新する仕組み

Incremental static regeneration（ISR）は、公開済みの静的サイトが、すべてをrebuildする代わりに、スケジュールまたはオンデマンドで個々のページを再構築できるようにします。

静的生成は高速ですが、次のフルbuildまで古いままになり、大規模サイトでは厄介です。ISRはその中間です。ページは静的に配信されますが、設定した間隔の後にリクエストされると、プラットフォームが単一のページをバックグラウンドで再生成できます。静的な速度を保ちながら、より新鮮なコンテンツとはるかに安価なrebuildが得られます。

ISRの仕組み

各ページは再検証（revalidation）のウィンドウを宣言できます。そのウィンドウが過ぎると、次のリクエストは依然としてcacheされたページを即座に受け取りつつ、プラットフォームは新しいバージョンをバックグラウンドで再生成し、以降の訪問者に対して差し替えます。

オンデマンド再生成

時間ベースの再検証に加えて、多くのプラットフォームは、CMSの更新後など、基となるデータが変化したときに特定のページを再生成するためのhookを提供します。これにより、コンテンツの編集がフルdeployなしで影響を受けたページだけを更新できます。

なぜ存在するのか

大規模サイトのフルrebuildは遅く、コストがかかります。
静的配信はリクエストごとのSSRよりはるかに安価です。
コンテンツはまるごと新しいdeployなしでも更新する必要があります。

runtimeの要件

純粋なSSGとは異なり、ISRはdeploy後に再生成を実行できるプラットフォームを必要とするため、真に静的なホスティングではありません。ホスティングプロバイダがこのモデルをサポートしているかどうかに依存し、ある程度そのプラットフォームに縛られることになります。

CI/CDにおけるISR

CIのbuildは依然として初期の静的ページと再生成の設定を生成しますが、鮮度はpipelineではなくhost上のruntimeで処理されます。これにより、すべてのページを各deployで再構築する必要がなくなるため、大規模サイトのbuild時間が短縮されます。

重要なポイント

ISRはdeploy後に個々の静的ページを、スケジュールまたはオンデマンドで再生成します。
静的配信の速度と、より新鮮なコンテンツ、そして安価なrebuildを組み合わせます。
再生成をサポートするruntimeが必要なため、純粋な静的ホスティングではありません。