モダンNext.jsにおける構成、キャッシュ、アーキテクチャ

発表者は自己紹介後、Next.jsのApp Routerにおけるコンポジション、キャッシング、アーキテクチャのパターンについて説明すると述べます。まず、ウェブサイトのパフォーマンスとスケーラビリティを確保するための基本概念として、静的レンダリングと動的レンダリングの違いを解説します。静的レンダリングは事前レンダリングにより高速アクセス、サーバー負荷軽減、SEO向上に寄与し（例：Next.js Confサイト）、動的レンダリングはリアルタイムデータやパーソナライズされたコンテンツ（例：Vercelダッシュボード）を可能にします。`params`、`search params`、`cookies`、`headers`、`fetch`と`no-store`などのAPIが動的レンダリングを引き起こす具体的な例として挙げられます。

以前のNext.jsでは、ページ全体が静的か動的かのどちらかに強制され、一つの動的APIがページ全体を動的にしてしまう問題がありました。これにより、ほとんど静的なコンテンツに対してもサーバーで冗長な処理が発生し、パフォーマンスが低下していました。ReactサーバーコンポーネントとSuspenseは部分的な解決策でしたが、動的コンテンツのストリーミングには追加のスケルトンUI作成などが必要でした。この問題を解決するため、Next.js 16で`use cache`ディレクティブが導入され、ページが静的と動的の両方になり得ることが発表されました。`use cache`はコンポーザブルなキャッシングを可能にし、ページ、Reactコンポーネント、または関数をキャッシュ可能としてマークできます。

発表者は、eコマースプラットフォームを模したNext.jsアプリケーションのデモを開始します。このアプリには、ホームページ、製品閲覧ページ、製品詳細ページ、Aboutページ、ダッシュボードなどがあり、静的コンテンツとユーザーに依存する動的コンテンツが混在しています。現在のコードベースが抱える一般的な問題として、深いプロップドリリングによる保守・リファクタリングの困難さ、冗長なクライアントサイドJavaScriptと複数の責任を持つ大規模コンポーネント、そして静的レンダリングの欠如による追加のサーバーコストとパフォーマンス低下が挙げられます。デモの目標は、これらの問題を解決し、アプリをより高速でスケーラブル、かつ保守しやすいものにすることです。

最初の問題であるプロップドリリングに対処するため、発表者は`loggedIn`変数の渡し方を改善します。データフェッチをコンポーネントツリーのより深い位置に押し下げ、React CacheとContext Provider（`AuthProvider`と`useAuth`フック）を組み合わせることで、プロップドリリングを回避し、コンポーネントの再利用性を高めます。これにより、ウェルカムバナーのようなコンポーネントがホームページの依存関係から解放され、ブラウザページなど他の場所でも簡単に再利用できるようになります。このパターンは、優れたコンポーネントアーキテクチャを維持し、コンポーネントをより使いやすく、コンポーザブルにするための鍵となります。

次に、過剰なクライアントサイドJavaScriptと大規模コンポーネントの問題に取り組みます。発表者は「ドーナツパターン」を紹介し、インタラクティブなUIロジックをクライアントサイドのラッパーコンポーネント（例：`BannerContainer`）に抽出し、その中にサーバーレンダリングされたコンテンツをスロットインする方法を示します。これにより、ウェルカムバナーのようなコンポーネントをサーバーコンポーネントに変換し、データフェッチをサーバーサイドで行うことで、クライアントサイドJSを大幅に削減します。また、アニメーションライブラリ（Motion）の使用で発生する`use client`の強制も、同様のドーナツパターンで解決し、フッターの`ShowMore`機能やモーダルにもこのパターンを適用できることを示します。

アプリケーションのすべてのページが動的にレンダリングされている問題に対処します。これは、ルートレイアウト内のユーザープロフィールがクッキーを使用しているため、ページ全体が動的に強制されていることが原因です。従来の回避策（ルートグループ分割やプリコンピュートパターン）の複雑さを指摘し、より簡単な解決策として`next.config`で`cache components`を有効にすることを提案します。これにより、すべての非同期呼び出しがデフォルトで動的にオプトインされ、`use cache`ディレクティブを使ってページ、関数、コンポーネントをきめ細かくキャッシュできるようになります。ホームページのヒーロー、フィーチャーカテゴリ、フィーチャープロダクトに`use cache`を適用し、Suspense境界を削除することで、これらのセグメントが静的に事前レンダリングされたシェルに含まれることを実演します。

製品閲覧ページで、トップレベルのカテゴリフェッチがブロッキングルートとなりエラーが発生する問題に直面します。`use cache`がブロッキングルートの特定に役立つことを示し、データフェッチをコンポーネントに押し込み、`use cache`を適用することで解決します。これにより、製品リストの検索パラメーターも深く解決できるようになり、ページ全体の静的要素が増加します。最も重要な製品詳細ページでは、製品自体と製品詳細に`use cache`を適用しますが、動的API（「製品を保存」ボタン）の使用によりエラーが発生します。ここでもドーナツパターンを再利用し、動的セグメントをキャッシュセグメント内にスロットインすることで、問題を解決します。最後に、`params`による動的レンダリングに対して`generate static params`を使用し、一部のページを事前レンダリングし、残りをユーザー生成時にキャッシュすることで、すべてのエラーを解消します。

リファクタリング後のアプリケーションをVercelにデプロイし、意図的に遅延させたデータフェッチにもかかわらず、ホームページ、製品閲覧ページ、製品詳細ページが非常に高速にロードされることを実演します。`use cache`によってキャッシュされたセグメントが部分的な事前レンダリングで静的シェルに含まれ、Next.js 16のクライアントルーターのプリフェッチ機能と相まって、ナビゲーションが瞬時に感じられることを強調します。結論として、`use cache`により静的と動的の区別がなくなり、複雑な回避策が不要になることを述べます。最後に、データフェッチの最適化、ドーナツパターン、`use cache`の3つの主要なパターンをまとめ、これらが優れたアーキテクチャ、容易なコンポジション、最適なキャッシングに繋がり、高いLighthouseスコア（全ページ100点）を達成できることを示し、リポジトリへのリンクを提供して締めくくります。