増分静的再生 (ISR) の秘められた可能性

1. ISRとは何ですか?

ISR (増分静的再生成) は、Next.js によって導入されたレンダリング戦略です。これにより、静的ページを構築し、実行時に段階的に更新できるようになります。このアプローチは、両方の長所を組み合わせたものです:

• 静的サイト生成 (SSG) の 速度と SEO の利点
• コンテンツを自動的に更新するための サーバーサイド レンダリング (SSR) の柔軟性。

ISR では、HTML は ビルド時に事前にレンダリングされますが、設定された再検証間隔の後、完全な再デプロイメントを必要とせずに、後続のリクエストでページを再生成できます。

2. ISR をいつ使用するか?

ISR は、次のようなページに最適です。

• パフォーマンスと SEO が優先事項です。
• コンテンツは定期的に変更されますが、リアルタイムの更新は重要ではありません。
• 頻繁な再デプロイメントは現実的ではありません。

例:

• ブログ: 検索エンジンに投稿のインデックスを作成させたいが、リアルタイムの更新は必要ありません。
• 製品リスト: 製品は数時間ごとに変更されますが、すぐに更新する必要はありません。
• ドキュメント: コンテンツは数日または数週間ごとに更新されます。

3. ISR はどのように機能しますか?

ISR を使用すると、ページは 展開中に 1 回だけ (SSG と同様) 構築されます。最初の生成後、ユーザー トラフィックと再検証間隔に基づいて、実行時にページをバックグラウンドで再生成できます。

ISR フローの概要:

1. ユーザーがページ (/blog など) をリクエストします。
   • ページが存在し、有効期限が切れていない場合、キャッシュされたバージョンが提供されます。
2. ページが期限切れまたは欠落している場合 (再検証時間に基づいて)、サーバーはバックグラウンド再生成をトリガーします。
3. 新しいバージョンの準備ができるまで、後続のユーザーは既存のページを受け取ります。
4. 再生成されると、新しいコンテンツが古いバージョンを置き換えます。

4. ISR を使用する理由

ISR の利点:

• パフォーマンス: 静的ページと同様、ISR ページはエッジまたはキャッシュから提供されるため、すぐに読み込まれます。
• SEO の最適化: 事前にレンダリングされたページにより、優れたインデックス作成と SEO パフォーマンスが保証されます。
• スケーラビリティ: ビルドごとにすべてのページを再生成する必要がないため、デプロイメント時間が短縮されます。
• 再デプロイは必要ありません: 再デプロイをトリガーせずにコンテンツが更新されます。

5. ISR を使用するためのベスト プラクティス

1. 適切な再検証間隔を選択します:
   • 適度に動的なコンテンツの場合は、間隔を短くします (60 秒など)。
   • めったに変更されないコンテンツの場合は、より長い間隔 (例: 24 時間)。
2. ISR とクライアント側の取得を組み合わせる:
   • ユーザー固有のデータなどの動的コンテンツには クライアント側の取得 (useEffect など) を使用し、静的 ISR ページ は SEO に適したコンテンツを処理します。
3. キャッシュ戦略を活用する:
   • リージョン間でのページ配信を最適化するには、エッジ キャッシュ または CDN 統合 を確認してください。
4. フォールバック状態を適切に処理します:
   • フォールバックを使用する: true または フォールバック: 再生成中に欠落したコンテンツを管理する方法に応じてブロックします。

6.例: Next.js での ISR の実装

Next.js を使用してブログ リスト ページで ISR を使用する方法は次のとおりです。

コード例: ISR を使用したブログ リスト

import { GetStaticProps } from 'next';

export async function getStaticProps() {
  const res = await fetch('https://api.example.com/posts');
  const posts = await res.json();

  return {
    props: { posts },
    revalidate: 60, // Revalidate the page every 60 seconds
  };
}

export default function BlogList({ posts }) {
  return (
    <div>
      <h1>Blog Posts</h1>
      <ul>
        {posts.map((post) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </div>
  );
}

説明:

• revalidate: 60 を指定すると、ページがバックグラウンドで 60 秒ごとに再生成され、再デプロイメントを必要とせずにリストが最新の状態に保たれます。

7. ISR のリスクと潜在的な問題

1. 古いデータ:
   • ユーザーに古いコンテンツが表示される可能性がある短い時間枠が常に存在します。これは、再検証間隔とトラフィック パターンによって異なります。
2. 再生遅延:
   • ページはオンデマンドで再生成されるため、トラフィックが少ない場合は、コンテンツの更新に時間がかかる可能性があります。
3. 複雑なフォールバック処理:
   • fallback: true を使用すると、ページの構築中にユーザーに 状態の読み込みが発生する可能性があり、ユーザー エクスペリエンスに影響を与える可能性があります。
4. 再検証中のエラー処理:
   • 再生成中にエラーが発生した場合、古いページが提供されるか、クライアント側の取得にフォールバックする可能性があります。

リスクを軽減する方法:

• 時間に敏感なページでは、短いを使用して間隔を再検証します。
• エラー ログを監視し、再検証中のエラーに対してフォールバック メカニズムを導入します。
• ユーザーエクスペリエンスを向上させるために、フォールバックページのスケルトンの読み込みを確認してください。

8.比較: ISR vs. SSG vs. SSR vs. CSR

Rendering Strategy	Best Use Case	Performance	SEO	Content Freshness
SSG	Rarely changing content	Very Fast	Great	Stale until redeployed
ISR	Periodically changing content	Fast	Great	Fresh within interval
SSR	Frequently changing content	Slower	Good	Always fresh
CSR	User-specific content	Fast on load	Poor	Always fresh

レンダリング戦略 ベストユースケース パフォーマンス SEO コンテンツの鮮度 SSG コンテンツがほとんど変更されない 非常に速い 素晴らしい 再デプロイするまで無効になります ISR コンテンツを定期的に変更する 速い 素晴らしい 間隔内で更新 SSR 頻繁に変更されるコンテンツ 遅い 良い 常に新鮮 CSR ユーザー固有のコンテンツ 読み込みが速い 悪い 常に新鮮 テーブル>

9. ISR を使用すべきではない場合

• 非常に動的なコンテンツ: データが毎秒変更される場合、リアルタイム コンテンツを保証するには SSR が適しています。
• 機密コンテンツ: ユーザー固有のページ (ダッシュボードやプロフィールなど) には、事前レンダリングされたコンテンツが十分に動的ではないため、ISR は適していません。
• トラフィックの少ないページ: ページのトラフィックが少ない場合、ISR が適時に更新をトリガーしない可能性があります。

10.実際の状況を交えて説明する増分静的再生

シナリオ 1: E コマースの商品ページ

衣料品を販売するオンライン ストアを運営しており、商品リスト用の個別ページ (/product/t-shirt など) を作成したいとします。これらのページには次のものが含まれます:

• 製品名、説明、価格、画像
• 検索エンジンのインデックス作成を改善するための SEO に適したタイトルと説明

チャレンジ:

• あなたは、これらのページを顧客に迅速に提供したいと考えています (したがって、SSR は理想的ではありません)。
• ただし、製品の価格や在庫状況は数時間ごとに変更される可能性があります。製品が更新されるたびにサイト全体を再デプロイする (SSG) 現実的ではありません。

ISR がこれを解決する方法:

• ISR を使用すると、製品ページはビルド時に静的に事前生成されます。そのため、ユーザーが初めてページにアクセスすると、超高速で SEO に最適化された商品ページが表示されます。
• 再検証間隔を 60 分に設定したとします。これは次のことを意味します:
• 次の 60 分間、/product/t-shirt にアクセスするすべてのユーザーは、キャッシュから提供される同じ静的バージョンを取得します。
• 60 分後、ユーザーがページにアクセスすると、システムはデータベースまたは API からの最新の商品データ (新しい価格、在庫状況など) を使用して バックグラウンド再生成をトリガーします。
• 新しいページの準備ができたら、古いページを置き換えます。誰かが再生成中にページをリクエストした場合でも、遅延を避けるために キャッシュされたバージョン を取得します。

商品ページの ISR の流れ:

1. 最初のリクエスト:
   • ユーザーが /product/t-shirt にアクセスします。
   • 事前に生成された静的バージョンはすぐに提供されます。
2. 製品アップデート:
   • あなたのチームはバックエンドで T シャツの 価格を変更します。

3. 60 分の枠内:

   • キャッシュされたページが提供されるため、ユーザーには引き続き 古い価格が表示されます。

4. 60 分後:

• 60 分後の最初のリクエストは、更新された価格でバックグラウンド再生をトリガーします。
• 次のリクエスト:
  • 更新されたページは、次の再検証間隔まで誰でも利用できるようになりました。

ISR がここでうまく機能する理由:

• 高速ページ: 静的ページがキャッシュされるため、ユーザーはページを素早く読み込むことができます。
• コンテンツの自動更新: 製品ページは、完全な再展開を必要とせずに定期的に更新されます。
• SEO の最適化: 事前にレンダリングされたページは、SSG と同様に検索エンジンに適しています。
• スケーラブル: 製品が変更されるたびに手動で再構築または再デプロイする必要はありません。

シナリオ 2: ISR を使用したニュース Web サイト

あなたが、1 日中記事を公開する ニュース Web サイトを運営しているとします。記事は 1 日のほとんどの期間有効ですが、新しい開発や修正を反映するために時折更新されます。

チャレンジ:

• 読者、特に SEO のために、記事が すぐに読み込まれるようにしたいと考えています。
• ただし、記事は 1 日を通して 更新または修正を受ける場合があります。毎回サイトを再デプロイするのは面倒です。

ISR がどのように役立つか:

• ISR を使用してビルド時に静的にニュース記事を生成しますが、再検証間隔を 10 分に設定します。これにより、次のことが保証されます。
• ニュース記事は静的ページであるため、読者にとって高速に読み込まれます。
• ジャーナリストが記事を更新すると、更新されたバージョンは 10 分以内に自動的に利用可能になります。サイト全体を再デプロイしたり再構築したりする必要はありません。

ニュース Web サイトの ISR フロー:

1. ユーザーは午前 9 時に /news/article-123 にアクセスします。ページは午前 8 時に生成された静的バージョンですぐに読み込まれます。
2. ジャーナリストが午前 9 時 15 分に記事を更新します。
3. 次の 10 分以内、古い記事はユーザーに表示されたままになります (古い記事ですが、依然として関連性はあります)。
4. 午前 9 時 20 分に、新しいユーザーが記事にアクセスします – ISR がバックグラウンドで再生成をトリガーします。
5. 更新されると、 今後のすべてのユーザーは最新バージョンを取得します。

ベストプラクティス:

• ニュース Web サイトの場合は、更新間隔を短く設定 (例: 5 ～ 10 分) して、タイムリーな更新を確保します。
• ニュース速報バナーやライブスコアなどのリアルタイム更新には、クライアント側の取得を使用します。

シナリオ 3: ドキュメント Web サイト

開発者ドキュメント Web サイト (Next.js ドキュメントなど) を管理しているとします。コンテンツは、数日ごと、新しい API または機能で更新されます。

チャレンジ:

• ユーザーはドキュメントを読むために高速なページ読み込みを望んでいます。
• 検索エンジンは、SEO のためにページのインデックスを作成する必要があります。
• 更新を頻繁に行うと、小さな変更を加えるたびにサイト全体を再構築する必要があり、時間がかかります。

ドキュメント サイトでの ISR の仕組み:

• ビルド時に 静的ページを事前生成できます。
• ドキュメントの変更は頻繁に行われないため、再検証間隔を 24 時間に設定します。
• 翌日の最初のリクエストの後、ISR は バックグラウンド再生成をトリガーしてページを更新します。
• 変更をすぐに公開する必要がある場合は、Webhook または管理ダッシュボードを使用して手動ページの再検証をトリガーできます。

11.最終的な考え

増分静的再生成は、SEO の利点を維持しながら、サイトのパフォーマンスとスケーラビリティを大幅に強化できる強力な機能です。 ISR は、静的生成とランタイム更新のバランスをとることにより、SSG と SSR の両方の長所をもたらします。ただし、コンテンツが古くならないようにするには、制限を理解し、再検証間隔を慎重に計画することが重要です。

以上が増分静的再生 (ISR) の秘められた可能性の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。