Chapter 8: Static Rendering と Dynamic Rendering
前章で構築したダッシュボードはデータ取得こそできるものの,ウォーターフォールや静的生成による更新遅延といった課題が残っていました。この章では静的・動的レンダリングの違いと使い分けを整理し,Next.js のキャッシング挙動を理解します。
この章で身につくこと
- Static Rendering / Dynamic Rendering の仕組みと特徴
- 動的レンダリングへ切り替える方法と注意点
- 遅延するデータ取得をシミュレーションし,挙動を確認する
前章で残っていた課題は次の 2 点でした。
- データ取得が意図せず ウォーターフォール になっている
- ダッシュボードが 静的 なため,データ更新が即座に反映されない
静的レンダリング(Static Rendering)とは?
静的レンダリングでは,データ取得とレンダリングがサーバーでビルド時(デプロイ時),または再検証(revalidate)のタイミングで行われます。
ユーザーがアプリを訪問すると,キャッシュ済みの結果が返されます。主な利点は次のとおりです。
- 高速化:Vercel のようなプラットフォームにデプロイすると,事前レンダリングされたコンテンツはキャッシュされ,グローバルに配信できます。世界中のユーザーがより速く安定してコンテンツにアクセスできます。
- サーバー負荷の軽減:コンテンツがキャッシュされるため,各リクエストで動的生成する必要がなく,計算コストを抑えられます。
- SEO:ページ読み込み時点でコンテンツが存在するため,検索エンジンのクロールやインデックスが容易になり,検索順位の改善につながります。
静的レンダリングは,データを持たないUIや,ユーザー間で共有される変化の少ないデータ(例:静的なブログ記事や商品ページ)に向いています。 一方,個人化されたデータが頻繁に更新されるダッシュボードには適していない場合があります。
静的レンダリングの対になる概念が動的レンダリングです。
動的レンダリング(Dynamic Rendering)とは?
動的レンダリングでは,ユーザーのリクエスト時(ユーザーがページを訪れるたび)に,サーバーでコンテンツをレンダリングします。主な利点は次のとおりです。
- リアルタイム性:頻繁に更新されるデータやリアルタイムデータを表示できます。
- ユーザーごとの出し分け:ダッシュボードやユーザープロフィールなど,個人化されたコンテンツを出し分けやすく,ユーザー操作に応じてデータを更新できます。
- リクエスト時にのみ分かる情報の利用:クッキーやURLの検索パラメータなど,リクエスト時にのみ取得できる情報に基づいたレンダリングが可能です。
遅いデータ取得のシミュレーション
このチュートリアルで作成しているダッシュボードは動的です。 しかし,前章で触れたようにもう一つ問題があります。もし他より極端に遅いデータ取得が1つでもあったら,どうなるでしょうか?
app/lib/data.ts の fetchRevenue() 内で,console.log と setTimeout のコメントを外し,意図的に遅延を入れてみましょう。
export async function fetchRevenue() {
try {
// デモ目的でレスポンスを意図的に遅らせます。
// 本番では絶対にやらないでください :)
console.log('Fetching revenue data...');
await new Promise((resolve) => setTimeout(resolve, 3000));
const data = await sql<Revenue[]>`SELECT * FROM revenue`;
console.log('Data fetch completed after 3 seconds.');
return data;
} catch (error) {
console.error('Database Error:', error);
throw new Error('Failed to fetch revenue data.');
}
}
新しいタブで http://localhost:3000/dashboard/ を開くと,ページの表示が遅くなったことが分かります。ターミナルには次のログが表示されるはずです。
ここでは,3秒の人工的な遅延を追加して遅いデータ取得を再現しました。結果として,データ取得の間,ページ全体のUI表示がブロックされます。これは開発者がよく直面する典型的な課題につながります。
動的レンダリングでは,アプリの速さは最も遅いデータ取得に依存します。