静的レンダリングと動的レンダリング

前章では、ダッシュボードの概要ページ用にデータを取得しました。しかし現在の設定には2つの制限があります：

1. データリクエストが意図しないウォーターフォールを引き起こしている
2. ダッシュボードが静的であるため、データ更新がアプリケーションに反映されない

静的レンダリングとは

静的レンダリングでは、データ取得とレンダリングがビルド時（デプロイ時）またはデータの再検証時にサーバー側で行われます。

ユーザーがアプリケーションにアクセスするたびに、キャッシュされた結果が提供されます。静的レンダリングにはいくつかの利点があります：

• 高速なウェブサイト - 事前レンダリングされたコンテンツはキャッシュ可能で、Vercelなどのプラットフォームにデプロイするとグローバルに配布されます。これにより世界中のユーザーが迅速かつ確実にコンテンツにアクセスできます。
• サーバー負荷の軽減 - コンテンツがキャッシュされるため、サーバーはユーザーリクエストごとに動的にコンテンツを生成する必要がありません。これによりコンピュートコストを削減できます。
• SEO対策 - 事前レンダリングされたコンテンツは、ページ読み込み時に既に利用可能なため、検索エンジンのクローラーがインデックスを作成しやすくなります。これにより検索順位の向上が期待できます。

静的レンダリングは、データがないUIやユーザー間で共有されるデータ（静的ブログ記事や商品ページなど）に適しています。ただし、定期的に更新されるパーソナライズされたデータを含むダッシュボードには向いていないかもしれません。

静的レンダリングの反対が動的レンダリングです。

動的レンダリングとは

動的レンダリングでは、コンテンツが各ユーザーごとにリクエスト時（ユーザーがページを訪問した時点）にサーバー側でレンダリングされます。動的レンダリングには以下の利点があります：

• リアルタイムデータ - 動的レンダリングにより、アプリケーションはリアルタイムまたは頻繁に更新されるデータを表示できます。データが頻繁に変更されるアプリケーションに最適です。
• ユーザー固有のコンテンツ - ダッシュボードやユーザープロファイルなどのパーソナライズされたコンテンツを提供し、ユーザー操作に基づいてデータを更新するのが容易になります。
• リクエスト時情報 - 動的レンダリングでは、クッキーやURL検索パラメータなど、リクエスト時点でしか知り得ない情報にアクセスできます。

低速なデータ取得のシミュレーション

私たちが構築しているダッシュボードアプリケーションは動的です。

しかし前章で触れた問題がまだ1つ残っています。もし1つのデータリクエストが他のすべてよりも遅い場合、どうなるでしょうか？

低速なデータ取得をシミュレートしてみましょう。app/lib/data.tsで、fetchRevenue()内のconsole.logとsetTimeoutのコメントを解除します：

export async function fetchRevenue() {
  try {
    // デモ用に意図的に遅延させています
    // 本番環境ではこのような実装は避けてください :)
    console.log('収益データを取得中...');
    await new Promise((resolve) => setTimeout(resolve, 3000));
 
    const data = await sql<Revenue[]>`SELECT * FROM revenue`;
 
    console.log('3秒後にデータ取得が完了しました');
 
    return data;
  } catch (error) {
    console.error('データベースエラー:', error);
    throw new Error('収益データの取得に失敗しました');
  }
}

新しいタブでhttp://localhost:3000/dashboard/を開き、ページの読み込みに時間がかかることを確認してください。ターミナルには以下のメッセージが表示されるはずです：

収益データを取得中...
3秒後にデータ取得が完了しました

ここでは、低速なデータ取得をシミュレートするために意図的に3秒の遅延を追加しました。その結果、データ取得中は訪問者にUIを表示するためのページ全体がブロックされてしまいます。これは開発者が解決しなければならない一般的な課題です：

動的レンダリングでは、アプリケーションの速度は最も遅いデータ取得の速度に依存します。