Next.js 16、キャッシュコンポーネントと React コンパイラー: 実際に何が変わるのか

spinny:~/writing $ vim nextjs-16-cache-components.md

1~
2Next.js で長年悩まされてきた質問の 1 つは、「このページは静的ですか、それとも動的ですか?」というものでした。 `cookies()`、さまざまなオプションを備えた `fetch`、データベース クライアント、CMS、ショッピング カート、またはカスタム コンテンツへの呼び出しを追加するまでは、これは単純な質問のように思えます。
3~
4Next.js 16 は、この会話の謎を少なくしようとしている点で興味深いです。複雑さが解消されるわけではありませんが、メンタル モデルが変わります。ルートはデフォルトで動的であり、キャッシュは必要に応じて自身を宣言し、`Suspense` は新鮮なままの部分で高速シェルを構成する自然な方法になります。
5~
6理解すべき機能はキャッシュ コンポーネントです。安定した Turbopack、React Compiler、`proxy.ts`、および新しい無効化 API は重要ですが、それらは同じ問題、つまりフレームワークが舞台裏で何を決定したかを推測することなく高速アプリを構築することを中心に展開しています。
7~
8## このことは重要だから
9~
10実際のアプリには、「静的ページ」と「動的ページ」だけが存在するわけではありません。さまざまなニーズを持つさまざまな部品があります。
11~
12商品シートは一日に数回変更される場合がございます。価格はより頻繁に変更される可能性があります。可用性はほぼライブである必要があります。ユーザー名は個人的なものです。レビューはストリーミングできます。サイドバーを安定させることができます。カートにはありません。
13~
14すべてを 1 つの単位として扱うと、常に次の 2 つの極端などちらかになります。
15~
16- 積極的なキャッシュと古いデータが表示されるリスク。
17- あらゆる場所で動的レンダリングが行われ、必要以上にパフォーマンスが低下します。
18~
19キャッシュ コンポーネントは、まさにこの誤った選択を回避するために機能します。
20~
21## 実際のモデル
22~
23`cacheComponents: true` を使用すると、`"use cache"` を使用してキャッシュ可能なものを宣言できます。次に、期間とタグを `cacheLife()` および `cacheTag()` に関連付けることができます。動的部分は動的のままであり、`Suspense` を使用して分離できます。
24~
25```mermaid
26flowchart TD
27    Request[ユーザーリクエスト] --> Shell[キャッシュされたシェル]
28    Request --> Dynamic[ダイナミックセクション]
29    Shell --> FirstPaint[最初の簡単なコンテンツ]
30    Dynamic --> Stream[サスペンス内のストリーミング]
31    Stream --> Complete[全ページ]
32```
33~
34セットアップは小規模です:
35~
36```typescript
37// next.config.ts
38import type { NextConfig } from 'next';
39~
40const nextConfig: NextConfig = {
41  cacheComponents: true,
42};
43~
44export default nextConfig;
45```
46~
47大きな変更は設定にありません。それはコンポーネントの記述を開始する方法にあります。
48~
49```tsx
50// app/products/[slug]/page.tsx
51import { Suspense } from 'react';
52import { cacheLife, cacheTag } from 'next/cache';
53~
54async function getProduct(slug: string) {
55  'use cache';
56~
57  cacheLife('hours');
58  cacheTag(`product:${slug}`);
59~
60  return db.product.findUnique({ where: { slug } });
61}
62~
63async function ProductDetails({ slug }: { slug: string }) {
64  const product = await getProduct(slug);
65~
66  return (
67    <section>
68      <h1>{product.name}</h1>
69      <p>{product.description}</p>
70    </section>
71  );
72}
73~
74async function LiveInventory({ slug }: { slug: string }) {
75  const inventory = await db.inventory.findFirst({ where: { slug } });
76  return <p>{inventory.quantity} pezzi disponibili</p>;
77}
78~
79export default async function ProductPage({ params }: { params: Promise<{ slug: string }> }) {
80  const { slug } = await params;
81~
82  return (
83    <>
84      <ProductDetails slug={slug} />
85      <Suspense fallback={<p>Controllo disponibilità...</p>}>
86        <LiveInventory slug={slug} />
87      </Suspense>
88    </>
89  );
90}
91```
92~
93ページはすべてキャッシュされている必要も、すべてが動的である必要もありません。製品シートは迅速かつ再利用可能です。在庫は常に新鮮な状態を保つことができます。ユーザーは、最も遅い部分を待たずに、すぐに何かを確認できます。
94~
95## `use cache` は実行可能なドキュメントです
96~
97`"use cache"` について私が気に入っている点は、意図を明示的にするよう強制することです。関数を読むと、誰かが「このデータは再利用できる」と判断したことがすぐにわかります。
98~
99これは、`fetch` を使用していない場合に特に便利です。多くのアプリは、Prisma、Drizzle、内部 SDK、CMS クライアント、またはサービス機能からデータを読み取ります。このような場合、`fetch` オプションのみに基づく従来の推論では十分ではありませんでした。
100~
101経験則:
102~
103- カシェアの内容は比較的安定しています。
104- 詳細なタグを使用します。
105- 動的な権限、セッション、カート、通知、トランザクション状態を残します。
106- 遅い部分を `Suspense` 内に配置します。
107- 「パフォーマンスが向上した」と言う前に、測定してください。
108~
109## すべてを捨てずに無効化する
110~
111キャッシュは、正確に更新できる場合にのみ役立ちます。ここで、`cacheTag`、`revalidateTag`、`updateTag` が重要になります。
112~
113例:
114~
115```typescript
116'use server';
117~
118import { updateTag } from 'next/cache';
119~
120export async function updateProductName(productId: string, name: string) {
121  await db.product.update({
122    where: { id: productId },
123    data: { name },
124  });
125~
126  updateTag(`product:${productId}`);
127}
128```
129~
130重要なディテールはタグです。 `product:${productId}` は正確な境界を示します。 `products` は巨大なバケットを示します。巨大なバケツは最初は快適です。数か月後には、タイトルを変更するためにアプリの半分を無効にする理由になります。
131~
132## Stable Turbopack: 毎日耳にする部分
133~
134Next.js 16 では、開発とビルドの中心に Turbopack が組み込まれます。これは最も詩的な機能ではありませんが、作業中に感じるものです。サーバーの起動が早くなり、リフレッシュが速くなり、強制的なコーヒー ブレークのように感じなくなるビルドです。
135~
136とはいえ、カスタム プラグインが満載のコードベースを目をつぶって移行するつもりはありません。私ならチェックします:
137~
138- ローカルビルド。
139- 非標準輸入。
140- MDX、SVG、CSS。
141- Webpack プラグインは残っています。
142- 重要なページ。
143- ビルド時間の違い。
144~
145新しいプロジェクトの場合は、デフォルトから開始します。成熟したものについては、慎重な移行を行うと思います。
146~
147## React Compiler: 思考ではなくノイズを除去する
148~
149React Compiler 1.0 は安定しており、Next.js 16 は `reactCompiler` でそれをサポートしています。約束は、手動によるメモ化を大幅に減らすことです。つまり、「安全のため」に使用される `memo`、`useMemo`、`useCallback` が減ります。
150~
151```typescript
152// next.config.ts
153import type { NextConfig } from 'next';
154~
155const nextConfig: NextConfig = {
156  reactCompiler: true,
157};
158~
159export default nextConfig;
160```
161~
162私はそれを魔法の粉のように扱うつもりはありません。コンパイラは、コードが React ルールに適切に準拠している場合に役立ちます。コンポーネントに奇妙な副作用、隠れた突然変異、不適切に使用されたフックがある場合は、まずそれを修正する必要があります。
163~
164健康的に試してみる方法:
165~
1661. `eslint-plugin-react-hooks` を更新します。
1672. 実際の違反を修正する。
1683. 管理されたエリアでそれを有効にします。
1694. ビルド時間と動作を測定します。
1705. 手動メモ化は、不要になった場合にのみ削除してください。
171~
172目標は、すべての `useMemo` を消去することではありません。目標は、レンダリングが怖いという理由で予防的なメモ化を書くのをやめることです。
173~
174## `proxy.ts` とネットワーク境界
175~
176古い `middleware.ts` は `proxy.ts` になります。これは名前の変更ですが、これには意味があります。そのファイルはリクエスト境界に位置し、従来のバックエンド スタイルの汎用ミドルウェアではありません。
177~
178```typescript
179// proxy.ts
180import { NextRequest, NextResponse } from 'next/server';
181~
182export default function proxy(request: NextRequest) {
183  const isLoggedIn = Boolean(request.cookies.get('session'));
184~
185  if (!isLoggedIn && request.nextUrl.pathname.startsWith('/dashboard')) {
186    return NextResponse.redirect(new URL('/login', request.url));
187  }
188~
189  return NextResponse.next();
190}
191```
192~
193ここでのルールは単純です。小さく保つことです。リダイレクト、認証ルーティング、ヘッダー、重要な書き換え。 2 つ目のバックエンドのように感じ始めたら、おそらくやりすぎです。
194~
195## 実際にどうやって移住するか
196~
197すべての機能を一度にオンにすることはありません。私だったらこうします:
198~
1991. Next、React、React DOM を更新します。
2002. 公式 codemod を起動します。
2013. `params`、`searchParams`、`cookies()`、`headers()`、`draftMode()` の重大な変更を修正しました。
2024. `middleware.ts` を `proxy.ts` に移行します。
2035. 私はビルドと重要なページをチェックします。
2046. 現在キャッシュによって摩擦が生じているセクションでキャッシュ コンポーネントを有効にします。
2057. 私はタグと無効化の規則を定義します。
2068. React Compiler を個別に試してみます。
2079. 前後のメトリクスの比較。
208~
209優れた移行とは、すべての新機能を使用するものではありません。これにより、アプリの動作が読みやすくなります。
210~
211## 考え方で何が変わるのか
212~
213Next.js 16 の最も便利な点は、インテンションに適切な名前を付けられることです。機能は単に「データベースから商品を取得する」だけではありません。それは、「商品を入手し、何時間でもキャッシュできます。このタグで無効にします」です。コンポーネントは単に「ページをレンダリングする」だけではありません。それは、「これは高速シェルであり、この作品は個人的なものであり、これはストリーミングで提供されます。」です。
214~
215最初はもっと仕事が必要なように思えます。そうすれば、それは穏やかな形になります。パフォーマンスの決定は、デフォルト、ヒューリスティック、および部族の記憶の組み合わせに隠れることはなくなりました。それらはコードの中にあります。
216~
217## 役立つ情報源
218~
219- [Next.js 16 リリースノート](https://nextjs.org/blog/next-16)
220- [キャッシュ コンポーネント - Next.js ドキュメント](https://nextjs.org/docs/app/getting-started/cache-components)
221- [キャッシュを使用する - Next.js ドキュメント](https://nextjs.org/docs/app/api-reference/directives/use-cache)
222- [反応コンパイラ v1.0](https://react.dev/blog/2025/10/07/react-compiler-1)
223~

NORMAL · nextjs-16-cache-components.md [readonly]223 lines · :q to close

2Next.js で長年悩まされてきた質問の 1 つは、「このページは静的ですか、それとも動的ですか?」というものでした。 `cookies()`、さまざまなオプションを備えた `fetch`、データベースクライアント、CMS、ショッピングカート、またはカスタムコンテンツへの呼び出しを追加するまでは、これは単純な質問のように思えます。

4Next.js 16 は、この会話の謎を少なくしようとしている点で興味深いです。複雑さが解消されるわけではありませんが、メンタルモデルが変わります。ルートはデフォルトで動的であり、キャッシュは必要に応じて自身を宣言し、`Suspense` は新鮮なままの部分で高速シェルを構成する自然な方法になります。

6理解すべき機能はキャッシュコンポーネントです。安定した Turbopack、React Compiler、`proxy.ts`、および新しい無効化 API は重要ですが、それらは同じ問題、つまりフレームワークが舞台裏で何を決定したかを推測することなく高速アプリを構築することを中心に展開しています。

8## このことは重要だから

10実際のアプリには、「静的ページ」と「動的ページ」だけが存在するわけではありません。さまざまなニーズを持つさまざまな部品があります。

11~

12商品シートは一日に数回変更される場合がございます。価格はより頻繁に変更される可能性があります。可用性はほぼライブである必要があります。ユーザー名は個人的なものです。レビューはストリーミングできます。サイドバーを安定させることができます。カートにはありません。

13~

14すべてを 1 つの単位として扱うと、常に次の 2 つの極端などちらかになります。

15~

16- 積極的なキャッシュと古いデータが表示されるリスク。

17- あらゆる場所で動的レンダリングが行われ、必要以上にパフォーマンスが低下します。

18~

19キャッシュコンポーネントは、まさにこの誤った選択を回避するために機能します。

20~

21## 実際のモデル

22~

23`cacheComponents: true` を使用すると、`"use cache"` を使用してキャッシュ可能なものを宣言できます。次に、期間とタグを `cacheLife()` および `cacheTag()` に関連付けることができます。動的部分は動的のままであり、`Suspense` を使用して分離できます。

24~

25```mermaid

26flowchart TD

27 Request[ユーザーリクエスト] --> Shell[キャッシュされたシェル]

28 Request --> Dynamic[ダイナミックセクション]

29 Shell --> FirstPaint[最初の簡単なコンテンツ]

30 Dynamic --> Stream[サスペンス内のストリーミング]

31 Stream --> Complete[全ページ]

32```

33~

34セットアップは小規模です:

35~

36```typescript

37// next.config.ts

38import type { NextConfig } from 'next';

39~

40const nextConfig: NextConfig = {

41 cacheComponents: true,

42};

43~

44export default nextConfig;

45```

46~

47大きな変更は設定にありません。それはコンポーネントの記述を開始する方法にあります。

48~

49```tsx

50// app/products/[slug]/page.tsx

51import { Suspense } from 'react';

52import { cacheLife, cacheTag } from 'next/cache';

53~

54async function getProduct(slug: string) {

55 'use cache';

56~

57 cacheLife('hours');

58 cacheTag(`product:${slug}`);

59~

60 return db.product.findUnique({ where: { slug } });

61}

62~

63async function ProductDetails({ slug }: { slug: string }) {

64 const product = await getProduct(slug);

65~

66 return (

67 <section>

68 <h1>{product.name}</h1>

69 <p>{product.description}</p>

70 </section>

71 );

72}

73~

74async function LiveInventory({ slug }: { slug: string }) {

75 const inventory = await db.inventory.findFirst({ where: { slug } });

76 return <p>{inventory.quantity} pezzi disponibili</p>;

77}

78~

79export default async function ProductPage({ params }: { params: Promise<{ slug: string }> }) {

80 const { slug } = await params;

81~

82 return (

83 <>

84 <ProductDetails slug={slug} />

85 <Suspense fallback={<p>Controllo disponibilità...</p>}>

86 <LiveInventory slug={slug} />

87 </Suspense>

88 </>

89 );

90}

91```

92~

93ページはすべてキャッシュされている必要も、すべてが動的である必要もありません。製品シートは迅速かつ再利用可能です。在庫は常に新鮮な状態を保つことができます。ユーザーは、最も遅い部分を待たずに、すぐに何かを確認できます。

94~

95## `use cache` は実行可能なドキュメントです

96~

97`"use cache"` について私が気に入っている点は、意図を明示的にするよう強制することです。関数を読むと、誰かが「このデータは再利用できる」と判断したことがすぐにわかります。

98~

99これは、`fetch` を使用していない場合に特に便利です。多くのアプリは、Prisma、Drizzle、内部 SDK、CMS クライアント、またはサービス機能からデータを読み取ります。このような場合、`fetch` オプションのみに基づく従来の推論では十分ではありませんでした。

100~

101経験則:

102~

103- カシェアの内容は比較的安定しています。

104- 詳細なタグを使用します。

105- 動的な権限、セッション、カート、通知、トランザクション状態を残します。

106- 遅い部分を `Suspense` 内に配置します。

107- 「パフォーマンスが向上した」と言う前に、測定してください。

108~

109## すべてを捨てずに無効化する

110~

111キャッシュは、正確に更新できる場合にのみ役立ちます。ここで、`cacheTag`、`revalidateTag`、`updateTag` が重要になります。

112~

113例:

114~

115```typescript

116'use server';

117~

118import { updateTag } from 'next/cache';

119~

120export async function updateProductName(productId: string, name: string) {

121 await db.product.update({

122 where: { id: productId },

123 data: { name },

124 });

125~

126 updateTag(`product:${productId}`);

127}

128```

129~

130重要なディテールはタグです。 `product:${productId}` は正確な境界を示します。 `products` は巨大なバケットを示します。巨大なバケツは最初は快適です。数か月後には、タイトルを変更するためにアプリの半分を無効にする理由になります。

131~

132## Stable Turbopack: 毎日耳にする部分

133~

134Next.js 16 では、開発とビルドの中心に Turbopack が組み込まれます。これは最も詩的な機能ではありませんが、作業中に感じるものです。サーバーの起動が早くなり、リフレッシュが速くなり、強制的なコーヒーブレークのように感じなくなるビルドです。

135~

136とはいえ、カスタムプラグインが満載のコードベースを目をつぶって移行するつもりはありません。私ならチェックします:

137~

138- ローカルビルド。

139- 非標準輸入。

140- MDX、SVG、CSS。

141- Webpack プラグインは残っています。

142- 重要なページ。

143- ビルド時間の違い。

144~

145新しいプロジェクトの場合は、デフォルトから開始します。成熟したものについては、慎重な移行を行うと思います。

146~

147## React Compiler: 思考ではなくノイズを除去する

148~

149React Compiler 1.0 は安定しており、Next.js 16 は `reactCompiler` でそれをサポートしています。約束は、手動によるメモ化を大幅に減らすことです。つまり、「安全のため」に使用される `memo`、`useMemo`、`useCallback` が減ります。

150~

151```typescript

152// next.config.ts

153import type { NextConfig } from 'next';

154~

155const nextConfig: NextConfig = {

156 reactCompiler: true,

157};

158~

159export default nextConfig;

160```

161~

162私はそれを魔法の粉のように扱うつもりはありません。コンパイラは、コードが React ルールに適切に準拠している場合に役立ちます。コンポーネントに奇妙な副作用、隠れた突然変異、不適切に使用されたフックがある場合は、まずそれを修正する必要があります。

163~

164健康的に試してみる方法:

165~

1661. `eslint-plugin-react-hooks` を更新します。

1672. 実際の違反を修正する。

1683. 管理されたエリアでそれを有効にします。

1694. ビルド時間と動作を測定します。

1705. 手動メモ化は、不要になった場合にのみ削除してください。

171~

172目標は、すべての `useMemo` を消去することではありません。目標は、レンダリングが怖いという理由で予防的なメモ化を書くのをやめることです。

173~

174## `proxy.ts` とネットワーク境界

175~

176古い `middleware.ts` は `proxy.ts` になります。これは名前の変更ですが、これには意味があります。そのファイルはリクエスト境界に位置し、従来のバックエンドスタイルの汎用ミドルウェアではありません。

177~

178```typescript

179// proxy.ts

180import { NextRequest, NextResponse } from 'next/server';

181~

182export default function proxy(request: NextRequest) {

183 const isLoggedIn = Boolean(request.cookies.get('session'));

184~

185 if (!isLoggedIn && request.nextUrl.pathname.startsWith('/dashboard')) {

186 return NextResponse.redirect(new URL('/login', request.url));

187 }

188~

189 return NextResponse.next();

190}

191```

192~

193ここでのルールは単純です。小さく保つことです。リダイレクト、認証ルーティング、ヘッダー、重要な書き換え。 2 つ目のバックエンドのように感じ始めたら、おそらくやりすぎです。

194~

195## 実際にどうやって移住するか

196~

197すべての機能を一度にオンにすることはありません。私だったらこうします:

198~

1991. Next、React、React DOM を更新します。

2002. 公式 codemod を起動します。

2013. `params`、`searchParams`、`cookies()`、`headers()`、`draftMode()` の重大な変更を修正しました。

2024. `middleware.ts` を `proxy.ts` に移行します。

2035. 私はビルドと重要なページをチェックします。

2046. 現在キャッシュによって摩擦が生じているセクションでキャッシュコンポーネントを有効にします。

2057. 私はタグと無効化の規則を定義します。

2068. React Compiler を個別に試してみます。

2079. 前後のメトリクスの比較。

208~

209優れた移行とは、すべての新機能を使用するものではありません。これにより、アプリの動作が読みやすくなります。

210~

211## 考え方で何が変わるのか

212~

213Next.js 16 の最も便利な点は、インテンションに適切な名前を付けられることです。機能は単に「データベースから商品を取得する」だけではありません。それは、「商品を入手し、何時間でもキャッシュできます。このタグで無効にします」です。コンポーネントは単に「ページをレンダリングする」だけではありません。それは、「これは高速シェルであり、この作品は個人的なものであり、これはストリーミングで提供されます。」です。

214~

215最初はもっと仕事が必要なように思えます。そうすれば、それは穏やかな形になります。パフォーマンスの決定は、デフォルト、ヒューリスティック、および部族の記憶の組み合わせに隠れることはなくなりました。それらはコードの中にあります。

216~

217## 役立つ情報源

218~

219- [Next.js 16 リリースノート](https://nextjs.org/blog/next-16)

220- [キャッシュコンポーネント - Next.js ドキュメント](https://nextjs.org/docs/app/getting-started/cache-components)

221- [キャッシュを使用する - Next.js ドキュメント](https://nextjs.org/docs/app/api-reference/directives/use-cache)

222- [反応コンパイラ v1.0](https://react.dev/blog/2025/10/07/react-compiler-1)

223~