From 8d0c14ff316a01795031d75bba5046d4d57b00eb Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Thu, 21 Nov 2024 02:30:15 +0000 Subject: [PATCH] sync docs@697aff9 --- .github/ISSUE_TEMPLATE/bug_report.md | 18 +- .github/ISSUE_TEMPLATE/issue_template.md | 1 - .../01-routing/07-redirecting.mdx | 262 +++++------ .../04-caching/index.mdx | 439 +++++++++--------- .../06-optimizing/02-videos.mdx | 195 ++++---- .../07-configuring/05-mdx.mdx | 212 +++++---- .../07-configuring/10-custom-server.mdx | 63 +-- .../16-progressive-web-apps.mdx | 237 +++++----- .../11-upgrading/01-codemods.mdx | 135 +++--- .../01-metadata/sitemap.mdx | 70 +-- kj-diff.json | 13 +- next.js | 2 +- 12 files changed, 837 insertions(+), 810 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index dd84ea78..b5c68e55 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -4,7 +4,6 @@ about: Create a report to help us improve title: '' labels: '' assignees: '' - --- **Describe the bug** @@ -12,6 +11,7 @@ A clear and concise description of what the bug is. **To Reproduce** Steps to reproduce the behavior: + 1. Go to '...' 2. Click on '....' 3. Scroll down to '....' @@ -24,15 +24,17 @@ A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. **Desktop (please complete the following information):** - - OS: [e.g. iOS] - - Browser [e.g. chrome, safari] - - Version [e.g. 22] + +- OS: [e.g. iOS] +- Browser [e.g. chrome, safari] +- Version [e.g. 22] **Smartphone (please complete the following information):** - - Device: [e.g. iPhone6] - - OS: [e.g. iOS8.1] - - Browser [e.g. stock browser, safari] - - Version [e.g. 22] + +- Device: [e.g. iPhone6] +- OS: [e.g. iOS8.1] +- Browser [e.g. stock browser, safari] +- Version [e.g. 22] **Additional context** Add any other context about the problem here. diff --git a/.github/ISSUE_TEMPLATE/issue_template.md b/.github/ISSUE_TEMPLATE/issue_template.md index 4be775cb..e04efde8 100644 --- a/.github/ISSUE_TEMPLATE/issue_template.md +++ b/.github/ISSUE_TEMPLATE/issue_template.md @@ -4,7 +4,6 @@ about: Standard issue template for Nextjs-docs-ja title: '' labels: '' assignees: '' - --- #### Description diff --git a/docs/01-app/02-building-your-application/01-routing/07-redirecting.mdx b/docs/01-app/02-building-your-application/01-routing/07-redirecting.mdx index 8fe84611..e6e494b5 100644 --- a/docs/01-app/02-building-your-application/01-routing/07-redirecting.mdx +++ b/docs/01-app/02-building-your-application/01-routing/07-redirecting.mdx @@ -1,6 +1,6 @@ --- title: 'リダイレクト' -description: 'Next.jsでリダイレクトを処理するさまざまな方法を学びます。' +description: 'Next.jsでリダイレクトを処理するさまざまな方法について学びましょう。' related: links: - 'app/api-reference/functions/redirect' @@ -9,27 +9,27 @@ related: - 'app/api-reference/config/next-config-js/redirects' --- -Next.jsでリダイレクトを処理する方法はいくつかあります。このページでは、利用可能な各オプション、ユースケース、および大量のリダイレクトを管理する方法について説明します。 +Next.js では、リダイレクトを処理する方法がいくつかあります。このページでは、利用可能な各オプション、ユースケース、および大量のリダイレクトを管理する方法について説明します。 -| API | 目的 | 使用場所 | ステータスコード | -| -------------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------- | ----------------------------------- | -| [`redirect`](#redirect-function) | ミューテーションまたはイベント後にユーザーをリダイレクトする | Server Components、Server Actions、Route Handlers | 307（仮）または303（Server Action） | -| [`permanentRedirect`](#permanentredirect-function) | ミューテーションまたはイベント後にユーザーをリダイレクトする | Server Components、Server Actions、Route Handlers | 308（永続） | -| [`useRouter`](#userouter-hook) | クライアントサイドのナビゲーションを実行する | Client Componentsのイベントハンドラーで | 該当なし | -| [`next.config.js`内の`redirects`](#redirects-in-nextconfigjs) | パスに基づいて受信リクエストをリダイレクトする | `next.config.js`ファイル | 307（仮）または308（永続） | -| [`NextResponse.redirect`](#nextresponseredirect-in-middleware) | 条件に基づいて受信リクエストをリダイレクトする | ミドルウェア | 任意 | +| API | 目的 | 場所 | ステータスコード | +| -------------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------- | --------------------------------------- | +| [`redirect`](#redirect-function) | ミューテーションまたはイベント後にユーザーをリダイレクトする | Server Components, Server Actions, Route Handlers | 307 (一時的) または 303 (Server Action) | +| [`permanentRedirect`](#permanentredirect-function) | ミューテーションまたはイベント後にユーザーをリダイレクトする | Server Components, Server Actions, Route Handlers | 308 (Permanent) | +| [`useRouter`](#userouter-hook) | クライアントサイドのナビゲーションを実行する | Client Components のイベントハンドラとで使用 | N/A | +| [`redirects` in `next.config.js`](#redirects-in-nextconfigjs) | パスに基づいてリクエストをリダイレクトする | `next.config.js` ファイル | 307 (一時的) または 308 (Permanent) | +| [`NextResponse.redirect`](#nextresponseredirect-in-middleware) | 条件に基づいて受信リクエストをリダイレクトする | Middleware | 任意 | -| API | 目的 | 使用場所 | ステータスコード | -| -------------------------------------------------------------- | ---------------------------------------------- | ------------------------ | -------------------------- | -| [`useRouter`](#userouter-hook) | クライアントサイドのナビゲーションを実行する | コンポーネント | 該当なし | -| [`next.config.js`内の`redirects`](#redirects-in-nextconfigjs) | パスに基づいて受信リクエストをリダイレクトする | `next.config.js`ファイル | 307（仮）または308（永続） | -| [`NextResponse.redirect`](#nextresponseredirect-in-middleware) | 条件に基づいて受信リクエストをリダイレクトする | ミドルウェア | 任意 | +| API | 目的 | 場所 | ステータスコード | +| -------------------------------------------------------------- | ---------------------------------------------- | ------------------------- | ----------------------------------- | +| [`useRouter`](#userouter-hook) | クライアントサイドのナビゲーションを実行する | Components | N/A | +| [`redirects` in `next.config.js`](#redirects-in-nextconfigjs) | パスに基づいてリクエストをリダイレクトする | `next.config.js` ファイル | 307 (一時的) または 308 (Permanent) | +| [`NextResponse.redirect`](#nextresponseredirect-in-middleware) | 条件に基づいて受信リクエストをリダイレクトする | Middleware | 任意 | @@ -37,14 +37,14 @@ Next.jsでリダイレクトを処理する方法はいくつかあります。 ## `redirect` 関数 {#redirect-function} -`redirect` 関数を使用すると、ユーザーを別のURLにリダイレクトすることができます。`redirect`を[Server Components](/docs/app/building-your-application/rendering/server-components)、[Route Handlers](/docs/app/building-your-application/routing/route-handlers)、および[Server Actions](/docs/app/building-your-application/data-fetching/server-actions-and-mutations)で呼び出すことができます。 +`redirect` 関数を使用すると、ユーザーを別のURLにリダイレクトできます。`redirect` を [Server Components](/docs/app/building-your-application/rendering/server-components)、[Route Handlers](/docs/app/building-your-application/routing/route-handlers)、および [Server Actions](/docs/app/building-your-application/data-fetching/server-actions-and-mutations) にて呼び出すことができます。 -`redirect`は、ミューテーションまたはイベントの後によく使用されます。たとえば、投稿を作成する場合です： +`redirect` は、ミューテーションやイベントの後によく使用されます。たとえば、投稿を作成する場合： - + -```tsx title="app/actions.tsx" switcher +```ts title="app/actions.ts" switcher 'use server' import { redirect } from 'next/navigation' @@ -63,9 +63,9 @@ export async function createPost(id: string) { ``` - + -```jsx title="app/actions.js" switcher +```js title="app/actions.js" switcher 'use server' import { redirect } from 'next/navigation' @@ -86,26 +86,26 @@ export async function createPost(id) { -> **参考情報**： +> **Good to know**： > -> - `redirect`はデフォルトで307（Temporary Redirect）ステータスコードを返します。Server Actionで使用されるとき、通常はPOSTリクエストの結果として成功ページにリダイレクトするために使用される303（See Other）を返します。 -> - `redirect`は内部でエラーをスローするため、`try/catch`ブロックの外で呼び出す必要があります。 -> - `redirect`はクライアントコンポーネントのレンダリングプロセス中に呼び出すことができますが、イベントハンドラーでは呼び出せません。[`useRouter`フック](#userouter-hook)を代わりに使用できます。 -> - `redirect`は絶対URLも受け入れ、外部リンクにリダイレクトするために使用できます。 -> - レンダープロセスの前にリダイレクトしたい場合は、[`next.config.js`](#redirects-in-nextconfigjs)または[Middleware](#nextresponseredirect-in-middleware)を使用してください。 +> - `redirect` はデフォルトで 307（一時的リダイレクト）ステータスコードを返します。Server Action で使用する場合、POST リクエストの結果として成功ページにリダイレクトするためによく使用される 303（See Other）を返します。 +> - `redirect` は内部でエラーをスローするため、`try/catch` ブロックの外側で呼び出す必要があります。 +> - `redirect` はクライアントコンポーネントの描画プロセス中に呼び出すことができますが、イベントハンドラ内では呼び出すことができません。その代わり、[`useRouter` フック](#userouter-hook)を使用できます。 +> - `redirect` は絶対 URL も受け入れ、外部リンクにリダイレクトするために使用できます。 +> - レンダープロセスの前にリダイレクトしたい場合は、[`next.config.js`](#redirects-in-nextconfigjs) または [Middleware](#nextresponseredirect-in-middleware) を使用してください。 -[`redirect` APIリファレンス](/docs/app/api-reference/functions/redirect)を参照して、さらに情報をご覧ください。 +[`redirect` API リファレンス](/docs/app/api-reference/functions/redirect) を参照して、詳細情報を確認してください。 ## `permanentRedirect` 関数 {#permanentredirect-function} -`permanentRedirect` 関数は、ユーザーを別のURLに**永久に**リダイレクトすることができます。`permanentRedirect`を[Server Components](/docs/app/building-your-application/rendering/server-components)、[Route Handlers](/docs/app/building-your-application/routing/route-handlers)、および[Server Actions](/docs/app/building-your-application/data-fetching/server-actions-and-mutations)で呼び出すことができます。 +`permanentRedirect` 関数を使用すると、ユーザーを**永続的に**別の URL にリダイレクトできるようになります。[Server Components](/docs/app/building-your-application/rendering/server-components)、[Route Handlers](/docs/app/building-your-application/routing/route-handlers)、および [Server Actions](/docs/app/building-your-application/data-fetching/server-actions-and-mutations) で `permanentRedirect` を呼び出すことができます。 -`permanentRedirect`は、エンティティの正規URLが変更されるミューテーションまたはイベントの後によく使用されます。たとえば、ユーザーがユーザー名を変更した後にプロフィールURLを更新する場合です： +`permanentRedirect` は、エンティティの規格 URL を変更するようなミューテーションまたはイベントの後によく使用されます。 たとえば、ユーザー名を変更した後にユーザーのプロファイル URL を更新する場合： - + -```tsx title="app/actions.ts" switcher +```ts title="app/actions.ts" switcher 'use server' import { permanentRedirect } from 'next/navigation' @@ -118,15 +118,15 @@ export async function updateUsername(username: string, formData: FormData) { // エラーを処理する } - revalidateTag('username') // ユーザー名のすべての参照を更新する - permanentRedirect(`/profile/${username}`) // 新しいユーザープロフィールに移動する + revalidateTag('username') // ユーザー名へのすべての参照を更新する + permanentRedirect(`/profile/${username}`) // 新しいユーザープロファイルに移動する } ``` - + -```jsx title="app/actions.js" switcher +```js title="app/actions.js" switcher 'use server' import { permanentRedirect } from 'next/navigation' @@ -139,21 +139,21 @@ export async function updateUsername(username, formData) { // エラーを処理する } - revalidateTag('username') // ユーザー名のすべての参照を更新する - permanentRedirect(`/profile/${username}`) // 新しいユーザープロフィールに移動する + revalidateTag('username') // ユーザー名へのすべての参照を更新する + permanentRedirect(`/profile/${username}`) // 新しいユーザープロファイルに移動する } ``` -> **参考情報**： +> **Good to know**： > -> - `permanentRedirect`はデフォルトで308（恒久的リダイレクト）ステータスコードを返します； -> - `permanentRedirect`は絶対URLも受け入れ、外部リンクにリダイレクトするために使用できます； -> - レンダープロセスの前にリダイレクトしたい場合は、[`next.config.js`](#redirects-in-nextconfigjs)または[Middleware](#nextresponseredirect-in-middleware)を使用してください； +> - `permanentRedirect` はデフォルトで 308（永続的なリダイレクト）ステータスコードを返します。 +> - `permanentRedirect` も絶対 URL を受け入れ、外部リンクにリダイレクトするために使用できます。 +> - レンダープロセスの前にリダイレクトしたい場合は、[`next.config.js`](#redirects-in-nextconfigjs) または [Middleware](#nextresponseredirect-in-middleware) を使用してください。 -[`permanentRedirect` APIリファレンス](/docs/app/api-reference/functions/permanentRedirect)を参照して、さらに情報をご覧ください。 +[`permanentRedirect` API リファレンス](/docs/app/api-reference/functions/permanentRedirect) を参照して、詳細情報を確認してください。 @@ -161,7 +161,7 @@ export async function updateUsername(username, formData) { -クライアントコンポーネントのイベントハンドラー内でリダイレクトが必要な場合、`useRouter`フックの`push`メソッドを使用できます。例えば： +クライアントコンポーネントのイベントハンドラ内でリダイレクトが必要な場合は、`useRouter` フックの `push` メソッドを使用できます。例えば： @@ -208,7 +208,7 @@ export default function Page() { -コンポーネント内でリダイレクトする必要がある場合、`useRouter`フックの`push`メソッドを使用できます。例えば： +コンポーネント内でリダイレクトが必要な場合は、`useRouter` フックの `push` メソッドを使用できます。例えば： @@ -249,29 +249,29 @@ export default function Page() { -> **参考情報**： +> **Good to know**： > -> - プログラムでユーザーをナビゲートする必要がない場合は、[``](/docs/app/api-reference/components/link)コンポーネントを使用するべきです。 +> - プログラムでユーザーをナビゲートする必要がない場合は、[``](/docs/app/api-reference/components/link) コンポーネントを使用するべきです。 -[`useRouter` APIリファレンス](/docs/app/api-reference/functions/use-router)を参照して、さらに情報をご覧ください。 +[`useRouter` API リファレンス](/docs/app/api-reference/functions/use-router) を参照して、詳細情報を確認してください。 -[`useRouter` APIリファレンス](https://nextjs.org/docs/canary/pages/api-reference/functions/use-router)を参照して、さらに情報をご覧ください。 +[`useRouter` API リファレンス](https://nextjs.org/docs/canary/pages/api-reference/functions/use-router) を参照して、詳細情報を確認してください。 -## `next.config.js`内の`redirects` {#redirects-in-next-config-js} +## `next.config.js` における `redirects` {#redirects-in-next-config-js} -`next.config.js`ファイル内の`redirects`オプションを使用すると、受信リクエストのパスを別の宛先パスにリダイレクトできます。これは、ページのURL構造を変更した場合や、事前に既知のリダイレクトのリストがある場合に便利です。 +`next.config.js` ファイルの `redirects` オプションを使用すると、受信リクエストパスを別の宛先パスにリダイレクトできます。これは、ページの URL 構造を変更したり、事前に既知のリダイレクトリストを持っている場合に便利です。 -`redirects`は、[パス](/docs/app/api-reference/config/next-config-js/redirects#path-matching)、[ヘッダー、cookie、クエリのマッチング](/docs/app/api-reference/config/next-config-js/redirects#header-cookie-and-query-matching)をサポートし、受信リクエストに基づいてユーザーをリダイレクトする柔軟性を提供します。 +`redirects` は、[パス](/docs/app/api-reference/config/next-config-js/redirects#path-matching)、[ヘッダー、cookie、およびクエリの一致](/docs/app/api-reference/config/next-config-js/redirects#header-cookie-and-query-matching) をサポートしており、受信リクエストに基づいてユーザーをリダイレクトする柔軟性を提供します。 -`redirects`を使用するには、`next.config.js`ファイルにオプションを追加します： +`redirects` を使用するには、`next.config.js` ファイルに次のようにオプションを追加します： ```js title="next.config.js" module.exports = { @@ -283,7 +283,7 @@ module.exports = { destination: '/', permanent: true, }, - // ワイルドカードパスマッチング + // ワイルドカードパスの一致 { source: '/blog/:slug', destination: '/news/:slug', @@ -294,36 +294,36 @@ module.exports = { } ``` -[`redirects` APIリファレンス](/docs/app/api-reference/config/next-config-js/redirects)を参照して、さらに情報をご覧ください。 +[`redirects` API リファレンス](/docs/app/api-reference/config/next-config-js/redirects) を参照して、詳細情報を確認してください。 -> **参考情報**： +> **Good to know**： > -> - `redirects`は、`permanent`オプションを使用して307（Temporary Redirect）または308（Permanent Redirect）ステータスコードを返すことができます； -> - プラットフォームによっては、`redirects`に制限がある場合があります。たとえば、Vercelでは1,024件のリダイレクトの制限があります。大量のリダイレクト（1000件以上）を管理するには、[Middleware](/docs/app/building-your-application/routing/middleware)を使用したカスタムソリューションを作成することを検討してください。規模に応じたリダイレクト管理については、[managing redirects at scale](#managing-redirects-at-scale-advanced)を参照してください； -> - `redirects`はミドルウェアの**前に**実行されます； +> - `redirects` は、`permanent` オプションを使用すると、307（一時的リダイレクト）または 308（永続的リダイレクト）ステータスコードを返すことができます。 +> - `redirects` にはプラットフォームによって制限がある場合があります。 たとえば、Vercel では 1,024 のリダイレクト制限があります。 大量のリダイレクト（1000 以上）を管理するには、[Middleware](/docs/app/building-your-application/routing/middleware) を使用してカスタムソリューションを作成することを検討してください。規模に応じたリダイレクトの管理について詳しくは、[規模に応じたリダイレクトの管理](#managing-redirects-at-scale-advanced) をご覧ください。 +> - `redirects` は、Middleware の**前に**実行されます。 -## `NextResponse.redirect` in Middleware {#nextresponse-redirect-in-middleware} +## ミドルウェアにおける `NextResponse.redirect` {#nextresponse-redirect-in-middleware} -ミドルウェアを使用すると、リクエストが完了する前にコードを実行できます。そして、受信リクエストに基づいて`NextResponse.redirect`を使用して別のURLにリダイレクトします。これは、条件（例：認証、セッション管理など）に基づいてユーザーをリダイレクトする場合や、大量のリダイレクトがあります： +Middleware を使用すると、リクエストが完了する前にコードを実行できます。その後、受信リクエストに基づいて、`NextResponse.redirect` を使用して別の URL にリダイレクトできます。これは、条件（例：認証、セッション管理など）に基づいてユーザーをリダイレクトしたい場合、または[大量のリダイレクト](#managing-redirects-at-scale-advanced) がある場合に便利です。 -たとえば、ユーザーが認証されていない場合に`/login`ページにリダイレクトするには： +たとえば、認証されていないユーザーを`/login`ページにリダイレクトするには： - + -```tsx title="middleware.ts" switcher +```ts title="middleware.ts" switcher import { NextResponse, NextRequest } from 'next/server' import { authenticate } from 'auth-provider' export function middleware(request: NextRequest) { const isAuthenticated = authenticate(request) - // ユーザーが認証されている場合は、通常通り続行します + // ユーザーが認証されている場合は、通常どおり続行 if (isAuthenticated) { return NextResponse.next() } - // 認証されていない場合は、ログインページにリダイレクトします + // 認証されていない場合、ログインページにリダイレクト return NextResponse.redirect(new URL('/login', request.url)) } @@ -342,12 +342,12 @@ import { authenticate } from 'auth-provider' export function middleware(request) { const isAuthenticated = authenticate(request) - // ユーザーが認証されている場合は、通常通り続行します + // ユーザーが認証されている場合は、通常どおり続行 if (isAuthenticated) { return NextResponse.next() } - // 認証されていない場合は、ログインページにリダイレクトします + // 認証されていない場合、ログインページにリダイレクト return NextResponse.redirect(new URL('/login', request.url)) } @@ -359,28 +359,28 @@ export const config = { -> **参考情報**： +> **Good to know**： > -> - ミドルウェアは、`next.config.js`の`redirects`**後に**実行され、レンダリングの**前に**実行されます； +> - Middleware は `next.config.js` の `redirects` の**後に**、レンダリングの**前に**実行されます。 -[Middleware](/docs/app/building-your-application/routing/middleware)のドキュメントを参照して、さらに情報をご覧ください。 +[Middleware](/docs/app/building-your-application/routing/middleware) のドキュメントを参照して、詳細情報を確認してください。 -## 規模に応じたリダイレクト管理（高度） {#managing-redirects-at-scale-advanced} +## 規模に応じたリダイレクトの管理（高度）{#managing-redirects-at-scale-advanced} -大量のリダイレクト（1000件以上）を管理するために、ミドルウェアを使用してカスタムソリューションを作成することを検討してください。これにより、アプリケーションを再デプロイすることなく、プログラムでリダイレクトを処理できます。 +大量のリダイレクト（1000 以上）を管理するには、Middleware を使用してカスタムソリューションを作成することを検討してください。これにより、アプリケーションを再デプロイすることなく、プログラムでリダイレクトを処理することができます。 -これを行うには、以下を考慮する必要があります： +これを行うには、以下のことを考慮する必要があります： -1. リダイレクトマップの作成と保存 -2. データ検索パフォーマンスの最適化 +1. リダイレクトマップの作成と保存。 +2. データ検索パフォーマンスの最適化。 -> **Next.jsの例**：以下の推奨事項の実装については、[Middleware with Bloom filter](https://redirects-bloom-filter.vercel.app/)の例を参照してください。 +> **Next.js の例**：[Middleware with Bloom filter](https://redirects-bloom-filter.vercel.app/) の例を参照して、以下の推奨事項を実装してください。 ### 1. リダイレクトマップの作成と保存 {#1-creating-and-storing-a-redirect-map} -リダイレクトマップは、データベース（通常はキー・バリュー・ストア）またはJSONファイルに保存できるリダイレクトのリストです。 +リダイレクトマップは、データベース（通常はキー・バリュー ストア）または JSON ファイルに保存できるリダイレクトのリストです。 -次のデータ構造を考慮してください： +次のデータ構造を考えてみましょう： ```json { @@ -395,12 +395,12 @@ export const config = { } ``` -[Middleware](/docs/app/building-your-application/routing/middleware)で、Vercelの[Edge Config](https://vercel.com/docs/storage/edge-config/get-started?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)や[Redis](https://vercel.com/docs/storage/vercel-kv?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)などのデータベースから読み取り、受信リクエストに基づいてユーザーをリダイレクトすることができます： +[Middleware](/docs/app/building-your-application/routing/middleware) では、Vercel の [Edge Config](https://vercel.com/docs/storage/edge-config/get-started?utm_source=next-site&utm_medium=docs&utm_campaign=next-website) または [Redis](https://vercel.com/docs/storage/vercel-kv?utm_source=next-site&utm_medium=docs&utm_campaign=next-website) などのデータベースから読み取り、受信リクエストに基づいてユーザーをリダイレクトできます： - + -```tsx title="middleware.ts" switcher +```ts title="middleware.ts" switcher import { NextResponse, NextRequest } from 'next/server' import { get } from '@vercel/edge-config' @@ -419,7 +419,7 @@ export async function middleware(request: NextRequest) { return NextResponse.redirect(redirectEntry.destination, statusCode) } - // リダイレクトが見つからなかった場合、そのまま継続します + // リダイレクトが見つからない場合、リダイレクトせずに続行 return NextResponse.next() } ``` @@ -441,7 +441,7 @@ export async function middleware(request) { return NextResponse.redirect(redirectEntry.destination, statusCode) } - // リダイレクトが見つからなかった場合、そのまま継続します + // リダイレクトが見つからない場合、リダイレクトせずに続行 return NextResponse.next() } ``` @@ -451,19 +451,19 @@ export async function middleware(request) { ### 2. データ検索パフォーマンスの最適化 {#2-optimizing-data-lookup-performance} -大規模データセットをすべての受信リクエストのために読み取ることは遅く、費用がかかります。データ検索パフォーマンスを最適化する方法は2つあります： +受信リクエストごとに大規模なデータセットを読み込むことは、時間がかかり高価です。データ検索パフォーマンスを最適化するには、次の2つの方法があります： -- [Vercel Edge Config](https://vercel.com/docs/storage/edge-config/get-started?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)や[Redis](https://vercel.com/docs/storage/vercel-kv?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)などの、高速読み取りに最適化されたデータベースを使用します； -- [ブルームフィルター](https://en.wikipedia.org/wiki/Bloom_filter)のようなデータ検索戦略を使用して、リダイレクトが存在するかどうかを効率的にチェックし、より大きなリダイレクトファイルやデータベースを読み取る**前に**行います； +- [Vercel Edge Config](https://vercel.com/docs/storage/edge-config/get-started?utm_source=next-site&utm_medium=docs&utm_campaign=next-website) または [Redis](https://vercel.com/docs/storage/vercel-kv?utm_source=next-site&utm_medium=docs&utm_campaign=next-website) など、高速読み取りに最適化されたデータベースを使用します。 +- [ブルームフィルタ](https://en.wikipedia.org/wiki/Bloom_filter) などのデータ検索戦略を使用して、**大規模リダイレクトファイルやデータベースを読み込む前に**リダイレクトが存在するかどうかを効率的に確認します。 -前述の例では、生成されたブルームフィルターファイルをミドルウェアにインポートし、受信リクエストのパス名がブルームフィルターに存在するかどうかを確認します。 +以前の例を考慮して、ミドルウェアに生成されたブルームフィルタファイルをインポートし、受信リクエストパス名がブルームフィルタ内に存在するかどうかを確認できます。 -存在する場合は、要求を[API Routes](https://nextjs.org/docs/canary/pages/building-your-application/routing/api-routes) [Route Handler](/docs/app/building-your-application/routing/route-handlers)に転送し、要求が実際に存在するかをチェックし、ユーザーを適切なURLにリダイレクトします。これにより、ミドルウェアに大量のリダイレクトファイルをインポートすることを避けることができ、すべての受信リクエストが遅くなるのを防ぎます。 +存在する場合は、リクエストを [Route Handler](/docs/app/building-your-application/routing/route-handlers) [API Routes](https://nextjs.org/docs/canary/pages/building-your-application/routing/api-routes) に転送し、実際のファイルを確認して適切な URL にユーザーをリダイレクトします。これにより、ミドルウェアに大規模なリダイレクトファイルをインポートすることを回避でき、受信リクエストごとに速度が低下する可能性があります。 - + -```tsx title="middleware.ts" switcher +```ts title="middleware.ts" switcher import { NextResponse, NextRequest } from 'next/server' import { ScalableBloomFilter } from 'bloom-filters' import GeneratedBloomFilter from './redirects/bloom-filter.json' @@ -473,23 +473,23 @@ type RedirectEntry = { permanent: boolean } -// 生成されたJSONファイルからブルームフィルターを初期化する +// 生成されたJSONファイルからブルームフィルタを初期化 const bloomFilter = ScalableBloomFilter.fromJSON(GeneratedBloomFilter as any) export async function middleware(request: NextRequest) { - // 受信リクエストのパスを取得する + // 受信リクエストのパスを取得 const pathname = request.nextUrl.pathname - // パスがブルームフィルターにあるかチェックする + // パスがブルームフィルタに含まれているか確認 if (bloomFilter.has(pathname)) { - // パス名をRoute Handlerに転送する + // Route Handlerにパス名を転送 const api = new URL( `/api/redirects?pathname=${encodeURIComponent(request.nextUrl.pathname)}`, request.nextUrl.origin ) try { - // Route Handlerからリダイレクトデータを取得する + // Route Handlerでリダイレクトデータを取得 const redirectData = await fetch(api) if (redirectData.ok) { @@ -497,10 +497,10 @@ export async function middleware(request: NextRequest) { await redirectData.json() if (redirectEntry) { - // ステータスコードを決定する + // ステータスコードを決定 const statusCode = redirectEntry.permanent ? 308 : 307 - // 宛先にリダイレクトする + // 目的地へのリダイレクト return NextResponse.redirect(redirectEntry.destination, statusCode) } } @@ -509,7 +509,7 @@ export async function middleware(request: NextRequest) { } } - // リダイレクトが見つからなかった場合、そのままリクエストを続行します + // リダイレクトが見つからない場合、リダイレクトせずにリクエストを続行 return NextResponse.next() } ``` @@ -522,33 +522,33 @@ import { NextResponse } from 'next/server' import { ScalableBloomFilter } from 'bloom-filters' import GeneratedBloomFilter from './redirects/bloom-filter.json' -// 生成されたJSONファイルからブルームフィルターを初期化する +// 生成されたJSONファイルからブルームフィルタを初期化 const bloomFilter = ScalableBloomFilter.fromJSON(GeneratedBloomFilter) export async function middleware(request) { - // 受信リクエストのパスを取得する + // 受信リクエストのパスを取得 const pathname = request.nextUrl.pathname - // パスがブルームフィルターにあるかチェックする + // パスがブルームフィルタに含まれているか確認 if (bloomFilter.has(pathname)) { - // パス名をRoute Handlerに転送する + // Route Handlerにパス名を転送 const api = new URL( `/api/redirects?pathname=${encodeURIComponent(request.nextUrl.pathname)}`, request.nextUrl.origin ) try { - // Route Handlerからリダイレクトデータを取得する + // Route Handlerでリダイレクトデータを取得 const redirectData = await fetch(api) if (redirectData.ok) { const redirectEntry = await redirectData.json() if (redirectEntry) { - // ステータスコードを決定する + // ステータスコードを決定 const statusCode = redirectEntry.permanent ? 308 : 307 - // 宛先にリダイレクトする + // 目的地へのリダイレクト return NextResponse.redirect(redirectEntry.destination, statusCode) } } @@ -557,7 +557,7 @@ export async function middleware(request) { } } - // リダイレクトが見つからなかった場合、そのままリクエストを続行します + // リダイレクトが見つからない場合、リダイレクトせずにリクエストを続行 return NextResponse.next() } ``` @@ -567,12 +567,12 @@ export async function middleware(request) { -その後、Route Handlerでは： +次に、Route Handler で： - + -```tsx title="app/redirects/route.ts" switcher +```ts title="app/redirects/route.ts" switcher import { NextRequest, NextResponse } from 'next/server' import redirects from '@/app/redirects/redirects.json' @@ -584,15 +584,15 @@ type RedirectEntry = { export function GET(request: NextRequest) { const pathname = request.nextUrl.searchParams.get('pathname') if (!pathname) { - return new Response('不正なリクエスト', { status: 400 }) + return new Response('Bad Request', { status: 400 }) } - // redirects.jsonファイルからリダイレクトエントリを取得する + // redirects.jsonファイルからリダイレクトエントリを取得 const redirect = (redirects as Record)[pathname] - // ブルームフィルターの誤検知に対応する + // ブルームフィルタの誤検知を考慮する if (!redirect) { - return new Response('リダイレクトなし', { status: 400 }) + return new Response('No redirect', { status: 400 }) } // リダイレクトエントリを返す @@ -610,15 +610,15 @@ import redirects from '@/app/redirects/redirects.json' export function GET(request) { const pathname = request.nextUrl.searchParams.get('pathname') if (!pathname) { - return new Response('不正なリクエスト', { status: 400 }) + return new Response('Bad Request', { status: 400 }) } - // redirects.jsonファイルからリダイレクトエントリを取得する + // redirects.jsonファイルからリダイレクトエントリを取得 const redirect = redirects[pathname] - // ブルームフィルターの誤検知に対応する + // ブルームフィルタの誤検知を考慮する if (!redirect) { - return new Response('リダイレクトなし', { status: 400 }) + return new Response('No redirect', { status: 400 }) } // リダイレクトエントリを返す @@ -633,12 +633,12 @@ export function GET(request) { -その後、API Routeでは： +次に、API Route で： - + -```tsx title="pages/api/redirects.ts" switcher +```ts title="pages/api/redirects.ts" switcher import type { NextApiRequest, NextApiResponse } from 'next' import redirects from '@/app/redirects/redirects.json' @@ -650,15 +650,15 @@ type RedirectEntry = { export default function handler(req: NextApiRequest, res: NextApiResponse) { const pathname = req.query.pathname if (!pathname) { - return res.status(400).json({ message: '不正なリクエスト' }) + return res.status(400).json({ message: 'Bad Request' }) } - // redirects.jsonファイルからリダイレクトエントリを取得する + // redirects.jsonファイルからリダイレクトエントリを取得 const redirect = (redirects as Record)[pathname] - // ブルームフィルターの誤検知に対応する + // ブルームフィルタの誤検知を考慮する if (!redirect) { - return res.status(400).json({ message: 'リダイレクトなし' }) + return res.status(400).json({ message: 'No redirect' }) } // リダイレクトエントリを返す @@ -675,15 +675,15 @@ import redirects from '@/app/redirects/redirects.json' export default function handler(req, res) { const pathname = req.query.pathname if (!pathname) { - return res.status(400).json({ message: '不正なリクエスト' }) + return res.status(400).json({ message: 'Bad Request' }) } - // redirects.jsonファイルからリダイレクトエントリを取得する + // redirects.jsonファイルからリダイレクトエントリを取得 const redirect = redirects[pathname] - // ブルームフィルターの誤検知に対応する + // ブルームフィルタの誤検知を考慮する if (!redirect) { - return res.status(400).json({ message: 'リダイレクトなし' }) + return res.status(400).json({ message: 'No redirect' }) } // リダイレクトエントリを返す @@ -696,7 +696,7 @@ export default function handler(req, res) { -> **参考情報**： +> **Good to know**： > -> - ブルームフィルターを生成するために、[`bloom-filters`](https://www.npmjs.com/package/bloom-filters)のようなライブラリを使用できます； -> - 悪意のあるリクエストを防止するために、Route Handlerに対して行われるリクエストを検証する必要があります； +> - ブルームフィルタを生成するには、[`bloom-filters`](https://www.npmjs.com/package/bloom-filters)などのライブラリを使用できます。 +> - 悪意のあるリクエストを防ぐために、Route Handlerに対して行われるリクエストを検証する必要があります。 diff --git a/docs/01-app/02-building-your-application/04-caching/index.mdx b/docs/01-app/02-building-your-application/04-caching/index.mdx index b024cc73..c1f56028 100644 --- a/docs/01-app/02-building-your-application/04-caching/index.mdx +++ b/docs/01-app/02-building-your-application/04-caching/index.mdx @@ -1,64 +1,64 @@ --- -title: 'Next.jsのキャッシュ' -nav_title: 'キャッシュ' -description: 'Next.jsにおけるキャッシングメカニズムの概要。' +title: 'Next.jsにおけるキャッシング' +nav_title: 'キャッシング' +description: 'Next.jsのキャッシングメカニズムの概要。' --- -Next.jsは、レンダリング作業やデータリクエストをキャッシュすることで、アプリケーションのパフォーマンスを向上させ、コストを削減します。このページでは、Next.jsのキャッシングメカニズム、またそれらを設定するために使用できるAPI、およびそれらがどのように相互作用するかについて詳しく説明します。 +Next.jsは、レンダリング作業とデータリクエストをキャッシュすることで、アプリケーションのパフォーマンスを向上させ、コストを削減します。このページでは、Next.jsのキャッシングメカニズム、設定するためのAPI、およびそれらの相互作用について詳しく説明します。 -> **Good to know**: このページは、Next.jsが内部でどのように動作しているかを理解するのに役立ちますが、Next.jsを生産的に使用するための必須知識ではありません。ほとんどのNext.jsのキャッシングに関するユーリスティックは、APIの使用に基づいて決定され、最小限の設定で最高のパフォーマンスを発揮するためのデフォルトが設定されています。例を見たい場合は、[こちらから始めてください](/docs/app/building-your-application/data-fetching/fetching)。 +> **Good to know**: このページは、Next.jsの内部動作を理解するためのものであり、Next.jsを使って生産的に作業するために必須の知識では**ありません**。ほとんどのNext.jsのキャッシングヒューリスティックは、APIの使用方法によって決定され、ゼロまたは最小限の設定で最高のパフォーマンスを発揮するためのデフォルトがあります。代わりに例を見たい場合は、[こちらから始めてください](/docs/app/building-your-application/data-fetching/fetching)。 ## 概要 {#overview} -以下は、さまざまなキャッシングメカニズムとその目的に関する高レベルの概要です: +次に、異なるキャッシングメカニズムとその目的の概要を示します： -| メカニズム | 内容 | 場所 | 目的 | 期間 | -| ------------------------------------------- | ------------------- | ------------ | ---------------------------------------------------------- | ------------------------------------ | -| [Request Memoization](#request-memoization) | 関数の戻り値 | サーバー | React Component treeでデータを再利用するため | リクエストライフサイクル中 | -| [Data Cache](#data-cache) | データ | サーバー | ユーザーリクエストやデプロイメント間でデータを保持 | 永続的（再検証可能） | -| [Full Route Cache](#full-route-cache) | HTMLとRSCペイロード | サーバー | レンダリングコストを削減し、パフォーマンスを向上させるため | 永続的（再検証可能） | -| [Router Cache](#client-side-router-cache) | RSCペイロード | クライアント | ナビゲーション時のサーバーリクエストを削減するため | ユーザーセッションまたは時間に基づく | +| メカニズム | 内容 | 所在地 | 目的 | 期間 | +| ------------------------------------------- | ------------------- | ------------ | ------------------------------------------------ | ---------------------------------- | +| [Request Memoization](#request-memoization) | 関数の戻り値 | サーバ | React Component tree内でのデータ再利用 | リクエストライフサイクルごと | +| [Data Cache](#data-cache) | データ | サーバ | ユーザーリクエストとデプロイメント間のデータ保存 | 永続的（再検証可能） | +| [Full Route Cache](#full-route-cache) | HTMLとRSCペイロード | サーバ | レンダリングコスト削減とパフォーマンス向上 | 永続的（再検証可能） | +| [Router Cache](#client-side-router-cache) | RSCペイロード | クライアント | ナビゲーション時のサーバリクエスト削減 | ユーザーセッションまたは時間ベース | -Next.jsは、デフォルトでパフォーマンスを向上させコストを削減するために、できる限り多くのキャッシュを行います。つまり、ルートは**静的にレンダリング**され、データリクエストは**キャッシュ**されますが、これは任意で無効にできます。以下のダイアグラムは、ビルド時にルートが静的にレンダリングされるおよび静的なルートが最初に訪れられたときのデフォルトのキャッシング動作を示しています。 +デフォルトでは、Next.jsはできるだけ多くのキャッシュを行い、パフォーマンスを向上させ、コストを削減します。つまり、ルートは**静的にレンダリング**され、データリクエストは**キャッシュ**されますが、あなたがオプトアウトしない限りです。以下の図では、ビルド時や静的ルートが初めて訪問されたときに、ルートが静的にレンダリングされるデフォルトのキャッシング動作が示されています。 Next.jsのデフォルトキャッシング動作を示す図で、ビルド時と最初の訪問時のHIT、MISS、SETを示しています。 -キャッシング動作は、ルートが静的か動的か、データがキャッシュされているかされていないか、リクエストが初回訪問の一部なのか後続のナビゲーションによるものかによって変わります。ユースケースに応じて、個々のルートやデータリクエストのキャッシング動作を設定することができます。 +キャッシング動作は、ルートが静的または動的にレンダリングされているか、データがキャッシュされているかキャッシュされていないか、およびリクエストが最初の訪問の一部か、その後のナビゲーションの一部かに応じて変化します。使用ケースに応じて、個々のルートとデータリクエストのキャッシング動作を設定できます。 -## リクエストメモ化 {#request-memoization} +## Request Memoization {#request-memoization} -Reactは、同じURLとオプションを持つリクエストを自動的に**メモ化**するために[`fetch` API](#fetch)を拡張しています。これにより、Reactコンポーネントtree内の複数の場所で同じデータを取得するためのfetch関数を呼び出すことができますが、実行されるのは1度だけです。 +Reactは、同じURLとオプションを持つリクエストを自動で**メモ化**するために、[`fetch` API](#fetch)を拡張しています。これにより、同じデータに対するfetch関数をReact component tree内の複数の場所で呼び出しても、それを1回だけ実行することができます。 重複排除されたFetchリクエスト -例えば、ルート全体で同じデータが必要な場合（例えば、Layout、Page、および複数のコンポーネントにおいて）、treeの最上部でデータをfetchし、コンポーネント間でpropsを転送する必要はありません。その代わりに、必要なコンポーネント内でデータを取得でき、同じデータに対するネットワーク上での複数リクエストのパフォーマンスへの影響を心配する必要はありません。 +例えば、ルート全体で同じデータを使用する必要がある場合（例：Layout、Page、複数のコンポーネント内）、ツリーのトップでデータを取得してからプロップをコンポーネント間で渡す必要はありません。代わりに、必要なデータを持つコンポーネント内でデータをフェッチし、ネットワーク全体で同じデータに対して複数回リクエストを送ることのパフォーマンスへの影響を心配することなく、データを使うことができます。 ```tsx title="app/example.tsx" switcher async function getItem() { - // `fetch`関数は自動的にメモ化され、その結果はキャッシュされます + // `fetch`関数は自動的にメモ化され、その結果がキャッシュされます const res = await fetch('https://.../item/1') return res.json() } -// この関数は2回呼び出されますが、最初の1回のみ実行されます +// この関数は2回呼び出されますが、最初の1回だけ実行されます const item = await getItem() // cache MISS -// 二度目の呼び出しはルート内のどこでも可能です +// 2回目の呼び出しは、ルート内のどこでも可能です const item = await getItem() // cache HIT ``` @@ -67,472 +67,471 @@ const item = await getItem() // cache HIT ```jsx title="app/example.js" switcher async function getItem() { - // `fetch`関数は自動的にメモ化され、その結果はキャッシュされます + // `fetch`関数は自動的にメモ化され、その結果がキャッシュされます const res = await fetch('https://.../item/1') return res.json() } -// この関数は2回呼び出されますが、最初の1回のみ実行されます +// この関数は2回呼び出されますが、最初の1回だけ実行されます const item = await getItem() // cache MISS -// 二度目の呼び出しはルート内のどこでも可能です +// 2回目の呼び出しは、ルート内のどこでも可能です const item = await getItem() // cache HIT ``` -**リクエストメモ化の仕組み** +**Request Memoizationの仕組み** Reactレンダリング中にfetchメモ化がどのように機能するかを示すダイアグラム。 -- ルートをレンダリングする際に、特定のリクエストが初めて呼び出されたとき、その結果はメモリに存在せず、キャッシュの`MISS`となります。 -- したがって、関数が実行され、データが外部ソースから取得され、その結果がメモリに格納されます。 -- 同じレンダーパス内でのリクエストの後続の関数呼び出しはキャッシュの`HIT`となり、関数を実行することなくメモリからデータが返されます。 -- ルートがレンダリングされ、レンダリングパスが完了すると、メモリは「リセット」され、すべてのリクエストメモ化エントリがクリアされます。 +- ルートをレンダリングする際、特定のリクエストが初めて呼び出されたとき、その結果はメモリに存在せず、キャッシュ`MISS`となります； +- そのため、関数は実行され、データは外部ソースから取得され、結果はメモリに格納されます； +- 同じレンダリングパス内でのリクエストの後続の関数呼び出しはキャッシュ`HIT`となり、関数を実行せずにメモリからデータが返されます； +- ルートがレンダリングされ、レンダリングパスが完了すると、メモリは「リセット」され、すべてのリクエストメモ化エントリがクリアされます； > **Good to know**: > -> - リクエストメモ化はReactの機能であり、Next.jsの機能ではありません。ここでは、他のキャッシングメカニズムとの相互作用を示すために含まれています。 -> - メモ化は`fetch`リクエストの`GET`メソッドにのみ適用されます。 +> - リクエストメモ化はReactの機能であり、Next.jsの機能ではありません。他のキャッシングメカニズムとの相互作用を示すためにここに含まれています； +> - メモ化は`fetch`リクエストの`GET`メソッドにのみ適用されます； > - メモ化はReact Component treeにのみ適用されます。つまり： -> - `generateMetadata`、`generateStaticParams`、Layouts、Pages、およびその他のServer Components内の`fetch`リクエストに適用されます。 -> - Route Handlers内の`fetch`リクエストには適用されません。なぜなら、それらはReact component treeの一部ではないからです。 -> - `fetch`が適さない場合（例：一部のデータベースクライアント、CMSクライアント、GraphQLクライアント）、関数をメモ化するために[Reactの`cache`関数](#react-cache-function)を使用できます。 +> - `fetch`リクエストは、`generateMetadata`、`generateStaticParams`、Layouts、Pages、その他のServer Componentsで適用されます； +> - Route Handlers内の`fetch`リクエストには適用されません。なぜなら、それらはReact component treeの一部ではないからです； +> - `fetch`が適切でない場合（例：いくつかのデータベースクライアント、CMSクライアント、またはGraphQLクライアント）、[Reactの`cache`関数](#react-cache-function)を使用して関数をメモ化することができます； ### 期間 {#duration} -キャッシュはサーバーリクエストのライフタイムが続く間、つまりReact component treeのレンダリングが完了するまで持続します。 +キャッシュはサーバリクエストのライフタイムの間持続し、React component treeのレンダリングが完了するまで持続します； ### 再検証 {#revalidating} -メモ化はサーバーリクエスト間で共有されず、レンダリング中のみに適用されるため、再検証する必要はありません。 +メモ化はサーバリクエスト間で共有されず、レンダリング中にのみ適用されるため、再検証の必要はありません； ### オプトアウト {#opting-out} -メモ化は`fetch`リクエストの`GET`メソッドにのみ適用され、`POST`や`DELETE`などの他のメソッドはメモ化されません。このデフォルトの動作はReactの最適化であり、オプトアウトすることをお勧めしません。 +メモ化は`fetch`リクエストの`GET`メソッドにのみ適用され、`POST`や`DELETE`などの他のメソッドはメモ化されません。このデフォルトの動作はReactの最適化であり、これからオプトアウトすることは推奨されません； -個々のリクエストを管理するには、[`AbortController`](https://developer.mozilla.org/en-US/docs/Web/API/AbortController)の[`signal`](https://developer.mozilla.org/en-US/docs/Web/API/AbortController/signal)プロパティを使用できます。ただし、これはメモ化からオプトアウトするのではなく、実行中のリクエストを中止するものです。 +個々のリクエストを管理するには、[`AbortController`](https://developer.mozilla.org/en-US/docs/Web/API/AbortController)からの[`signal`](https://developer.mozilla.org/en-US/docs/Web/API/AbortController/signal)プロパティを使用できます。ただし、これによりリクエストはメモ化からオプトアウトするのではなく、処理中のリクエストを中止します； ```js title="app/example.js" const { signal } = new AbortController() fetch(url, { signal }) ``` -## データキャッシュ {#data-cache} +## Data Cache {#data-cache} -Next.jsには組み込みのデータキャッシュがあり、データの取得結果を**サーバーリクエスト**と**デプロイメント**間で**保持**します。これは、Next.jsがネイティブの`fetch` APIを拡張し、サーバー上の各リクエストが独自の永続的なキャッシングセマンティクスを設定できるようにすることで可能です。 +Next.jsには組み込みのData Cacheがあり、データフェッチの結果を**サーバリクエスト**および**デプロイメント**間で**永続化**します。これは、Next.jsがネイティブの`fetch`APIを拡張して、サーバ上の各リクエストが自身の永続的なキャッシングセマンティクスを設定できるようにすることで可能になります； -> **Good to know**: ブラウザでは、`fetch`の`cache`オプションはリクエストがブラウザのHTTPキャッシュとどのように相互作用するかを示しますが、Next.jsでは、`cache`オプションはサーバー側のリクエストがサーバーのデータキャッシュとどのように相互作用するかを示します。 +> **Good to know**: ブラウザでは、`fetch`の`cache`オプションはリクエストがブラウザのHTTPキャッシュとどのように相互作用するかを示しますが、Next.jsでは、`cache`オプションはサーバサイドリクエストがサーバのData Cacheとどのように相互作用するかを示します； -`fetch`の[`cache`](#fetch-optionscache)および[`next.revalidate`](#fetch-optionsnextrevalidate)オプションを使用して、キャッシング動作を設定できます。 +キャッシング動作を設定するには、`fetch`の[`cache`](#fetch-optionscache)および[`next.revalidate`](#fetch-optionsnextrevalidate)オプションを使用できます； -**データキャッシュの仕組み** +**Data Cacheの仕組み** データキャッシュと対話するキャッシュおよび非キャッシュのfetchリクエストの図。キャッシュリクエストはデータキャッシュに格納され、メモ化されます。非キャッシュリクエストはデータソースから取得され、データキャッシュに格納されず、メモ化されます。 -- `'force-cache'`オプション付きの`fetch`リクエストがレンダリング中に初めて呼び出されたとき、Next.jsはデータキャッシュにキャッシュされた応答があるか確認します。 -- キャッシュされた応答が見つかった場合、それはすぐに返され、[メモ化されます](#request-memoization)。 -- キャッシュされた応答が見つからなかった場合、リクエストがデータソースに送られ、その結果がデータキャッシュに保存され、メモ化されます。 -- 非キャッシュデータ（例：`cache`オプションが定義されていないまたは`{ cache: 'no-store' }`を使用）は、結果が常にデータソースから取得され、メモ化されます。 -- データがキャッシュされているかどうかにかかわらず、同じデータに対する重複したリクエストを防ぐためにリクエストは常にメモ化され、Reactレンダリングパス中に行われます。 +- 初めて`'force-cache'`オプションを持つ`fetch`リクエストがレンダリング中に呼び出されたとき、Next.jsはData Cacheでキャッシュされたレスポンスを確認します； +- キャッシュされたレスポンスが見つかった場合、それは即座に返され、[メモ化](#request-memoization)されます； +- キャッシュされたレスポンスが見つからない場合、データソースに対してリクエストが行われ、その結果がData Cacheに格納され、メモ化されます； +- キャッシュされていないデータ（例：キャッシュオプションが定義されていない、または`{ cache: 'no-store' }`を使用している場合）、したがってリクエストは常にデータソースから取得され、メモ化されます； +- データがキャッシュされているかキャッシュされていないかにかかわらず、リクエストは常にメモ化されて、Reactレンダリングパス中の同じデータに対する重複リクエストを防ぎます； -> **データキャッシュとリクエストメモ化の違い** +> **Data CacheとRequest Memoizationの違い** > -> 両方のキャッシングメカニズムは、キャッシュされたデータを再利用することによってパフォーマンスを向上させますが、データキャッシュはリクエストとデプロイメントにまたがって永続的に維持されるのに対し、メモ化はリクエストのライフタイム内でのみ持続します。 +> 両方のキャッシングメカニズムはキャッシュされたデータを再利用することによってパフォーマンスを向上させるのに役立ちますが、Data Cacheは入ってくるリクエストとデプロイメント間で永続的であるのに対し、メモ化はリクエストの寿命のみ持続です。 ### 期間 {#duration} -データキャッシュは、再検証またはオプトアウトが行われない限り、リクエストやデプロイメント間で永続的に保持されます。 +Data Cacheは、再検証またはオプトアウトしない限り、入ってくるリクエストとデプロイメント間で永続です； ### 再検証 {#revalidating} キャッシュされたデータは次の2つの方法で再検証できます： -- **時間ベースの再検証**: 一定時間経過後の新しいリクエストでデータを再検証します。これは、データがあまり頻繁に変化せず、新鮮さがあまり重要でない場合に有用です。 -- **オンデマンドの再検証**: イベントに基づいてデータを再検証します（例：フォーム送信）。オンデマンドの再検証はタグベースまたはパスベースのアプローチを使用してデータのグループを一度に再検証できます。例えば、無頭CMSのコンテンツが更新されたときに最新のデータをすぐに表示したい場合に有効です。 +- **時間ベースの再検証**：一定時間が経過し、新しいリクエストが行われるとデータを再検証します。これは、変化が少なく、鮮度がそれほど重要でないデータに便利です； +- **オンデマンド再検証**：イベントに基づいてデータを再検証します（例：フォームの送信）。オンデマンド再検証では、タグベースまたはパスベースのアプローチを使用してデータのグループを一度に再検証できます。これは、（例：ヘッドレスCMSからコンテンツが更新されたときなど）できるだけ迅速に最新データを表示したい場合に便利です； #### 時間ベースの再検証 {#time-based-revalidation} -特定の時間間隔でデータを再検証するには、`fetch`における`next.revalidate`オプションを使用して、リソースのキャッシュライフタイム（秒単位）を設定します。 +データを一定間隔で再検証するには、`fetch`の`next.revalidate`オプションを使用して、リソースのキャッシュ寿命を設定します（秒単位）； ```js -// 最大で毎時再生性を検証 +// 最長で毎時再検証 fetch('https://...', { next: { revalidate: 3600 } }) ``` -または、[ルートセグメント設定オプション](#segment-config-options)を使用して、セグメント内のすべての`fetch`リクエストを設定したり、`fetch`を使用できない場合に設定できます。 +または、[route segment configオプション](#segment-config-options)を使用して、セグメント内のすべての`fetch`リクエストを設定するか、`fetch`を使用できない場合（例：データベースクライアントやサードパーティのライブラリを使用する場合）に設定できます； **時間ベースの再検証の仕組み** 時間ベースの再検証の仕組みを示す図で、再検証期間後、最初のリクエストに対して古いデータが返され、次にデータが再検証されます。 -- `fetch`リクエストが最初に`revalidate`を指定して呼び出されたとき、外部データソースからデータが取得され、データキャッシュに保存されます。 -- 指定された時間枠内に呼び出されたリクエストは、キャッシュされたデータを返します。 -- 時間枠が経過した後、次のリクエストはまだキャッシュ（現在は古い）データを返します。 - - Next.jsはバックグラウンドでデータの再検証をトリガーします。 - - データが正常に取得されると、Next.jsは新鮮なデータでデータキャッシュを更新します。 - - バックグラウンド再検証が失敗した場合、前のデータはそのまま残ります。 +- `revalidate`を持つfetchリクエストが初めて呼び出されたとき、データが外部データソースからフェッチされ、Data Cacheに格納されます； +- 指定された時間枠（例：60 seconds）内に呼び出されたリクエストはキャッシュされたデータを返します； +- 時間枠が経過した後、次のリクエストはキャッシュされた（現在古くなった）データを返します； + - Next.jsはバックグラウンドでデータの再検証をトリガーします； + - データが正常にフェッチされた場合、Next.jsはData Cacheを新鮮なデータで更新します； + - バックグラウンドの再検証が失敗した場合、以前のデータが変更されずに保持されます； -これは[**stale-while-revalidate**](https://web.dev/stale-while-revalidate/)動作に似ています。 +これは[**stale-while-revalidate**](https://web.dev/stale-while-revalidate/)の動作に似ています； #### オンデマンド再検証 {#on-demand-revalidation} -データはパスごとに([`revalidatePath`](#revalidatepath))またはキャッシュタグごとに([`revalidateTag`](#fetch-optionsnexttags-and-revalidatetag))オンデマンドで再検証できます。 +データはパスごとにオンデマンドで再検証できます（[`revalidatePath`](#revalidatepath)）またはキャッシュタグごとに（[`revalidateTag`](#fetch-optionsnexttags-and-revalidatetag)）； **オンデマンド再検証の仕組み** オンデマンド再検証の仕組みを示す図で、データキャッシュが再検証リクエスト後に新鮮なデータで更新される仕組みを示します。 -- `fetch`リクエストが初めて呼び出されたとき、データが外部データソースから取得され、データキャッシュに保存されます。 -- オンデマンド再検証がトリガーされると、適切なキャッシュエントリはキャッシュから削除されます。 - - これは、古いデータをキャッシュに保持する時間ベースの再検証とは異なり、データが取得されるまでキャッシュに残ります。 -- 次回のリクエストが行われたとき、再びキャッシュの`MISS`となり、データが外部データソースから取得され、データキャッシュに保存されます。 +- `fetch`リクエストが初めて呼び出されると、データが外部データソースからフェッチされ、Data Cacheに格納されます； +- オンデマンド再検証がトリガーされると、適切なキャッシュエントリがキャッシュからパージされます； + - これは、古いデータをキャッシュしておく時間ベースの再検証とは異なります； +- 次のリクエストが行われると、再びキャッシュ`MISS`となり、データが外部データソースから取得され、Data Cacheに格納されます； ### オプトアウト {#opting-out} -`fetch`からの応答をキャッシュしたくない場合、以下のようにできます： +`fetch`からのレスポンスを**キャッシュしたくない**場合、以下のようにすることができます： ```js let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' }) ``` -## フルルートキャッシュ {#full-route-cache} +## Full Route Cache {#full-route-cache} -> **関連する用語**： +> **関連用語**： > -> 自動静的最適化、静的サイト生成、または静的レンダリングという用語が、アプリケーションのルートをビルド時にレンダリングおよびキャッシュするプロセスを指すために互換的に使用されることがあります。 +> **Automatic Static Optimization**、**Static Site Generation**、または**Static Rendering**は、アプリケーションのルートをビルド時にレンダリングおよびキャッシュするプロセスを指すために互換的に使用される場合があります。 -Next.jsはデフォルトでルートをビルドタイムにレンダリングし、キャッシュします。これは、個々のリクエストごとにサーバーでレンダリングする代わりにキャッシュされたルートを提供できる最適化であり、高速なページ読み込みを実現します。 +Next.jsはビルド時にルートを自動的にレンダリングし、キャッシュします。これは、各リクエストでサーバーでレンダリングする代わりにキャッシュされたルートを提供できる最適化であり、ページの読み込みを速くすることができます。 -フルルートキャッシュがどのように機能するかを理解するために、Reactがレンダリングをどのように扱うか、およびNext.jsがその結果をどのようにキャッシュするかを見ると役立ちます： +Full Route Cacheの仕組みを理解するためには、Reactがレンダリングをどのように処理するかと、Next.jsがその結果をどのようにキャッシュするかを見てみると役立ちます： -### 1. サーバーにおけるReactレンダリング {#1-react-rendering-on-the-server} +### 1. サーバーでのReactレンダリング {#1-react-rendering-on-the-server} -サーバーでは、Next.jsはReactのAPIを使用してレンダリングを調整します。レンダリング作業は、個々のルートセグメントおよびSuspenseバウンダリーごとに分割されます。 +サーバー上で、Next.jsはReactのAPIを使用してレンダリングをオーケストレートします。レンダリング作業は次のように分割されます：個々のルートセグメントおよびSuspense境界により。 各チャンクは2つのステップでレンダリングされます： -1. ReactはServer Componentsをストリーミングに最適化された特別なデータフォーマットにレンダリングします。これは**React Server Component Payload**と呼ばれます。 -2. Next.jsはReact Server Component PayloadとクライアントのJavaScript命令を使用して、サーバー上で**HTML**をレンダリングします。 +1. ReactはServer Componentsをストリーミング用に最適化された特別なデータ形式、通称**React Server Component Payload**にレンダリングします； +2. Next.jsはReact Server Component PayloadとClient Component JavaScriptの命令を使用して、サーバーで**HTML**をレンダリングします； -これにより、すべてがレンダリングされるのを待たずに作業をキャッシュしたり、応答を送信することができます。代わりに、作業が完了するたびに応答をストリーミングできるようになります。 +これにより、すべてがレンダリングされるのを待つ必要がなく、作業をキャッシュしたり、レスポンスを送信したりすることができます。代わりに、作業が完了するときにレスポンスをストリーム送信することができます； -> **React Server Component Payloadとは何か？** +> **React Server Component Payloadとは？** > -> React Server Component Payloadは、レンダリングされたReact Server Components treeのコンパクトなバイナリ表現です。クライアント上のReactにより、ブラウザのDOMを更新するために使用されます。React Server Component Payloadには以下が含まれます： +> React Server Component Payloadは、レンダリングされたReact Server Components treeのコンパクトなバイナリ表現です。このバイナリ表現は、クライアント側のReactがブラウザのDOMを更新するために使用します。React Server Component Payloadには次の内容が含まれます： > -> - Server Componentsのレンダリング結果 -> - クライアント ComponentsのJavaScriptファイルのプレースホルダーとその参照 -> - Server Componentsからクライアント Componentsに渡されたprops +> - Sever Componentsのレンダリングされた結果 +> - Client Componentsがレンダリングされるべき場所のプレースホルダーとそれらのJavaScriptファイルの参照 +> - Server ComponentからClient Componentに渡されたプロップ > -> 詳細は、[Server Components](/docs/app/building-your-application/rendering/server-components)のドキュメントをご覧ください。 +> 詳しくは、[Server Components](/docs/app/building-your-application/rendering/server-components)のドキュメントをご覧ください； -### 2. サーバーでのNext.jsキャッシング（フルルートキャッシュ） {#2-next-js-caching-on-the-server-full-route-cache} +### 2. サーバーでのNext.jsキャッシング（Full Route Cache） {#2-next-js-caching-on-the-server-full-route-cache} Next.jsのデフォルトのフルルートキャッシュの動作を示しており、React Server Component PayloadとHTMLがサーバーでキャッシュされる様子を示しています。 -Next.jsのデフォルトの動作は、ルートのレンダリング結果（React Server Component PayloadとHTML）をサーバーでキャッシュすることです。これはビルドタイムや再検証時に静的にレンダリングされたルートに適用されます。 +Next.jsのデフォルト動作は、ルートのレンダリングされた結果（React Server Component PayloadとHTML）をサーバ上でキャッシュすることです。これは、スタティックにレンダリングされたルートに対して、ビルド時、または再検証時に適用されます； -### 3. クライアントでのReact実行と同期 {#3-react-hydration-and-reconciliation-on-the-client} +### 3. クライアントでのReactのハイドレーションとリコンシリエーション {#3-react-hydration-and-reconciliation-on-the-client} -リクエスト時にクライアントでは： +リクエスト時に、クライアント上で： -1. HTMLは、クライアントとServer Componentsの非対話型の初期プレビューをすぐに表示するために使用されます。 -2. React Server Components Payloadは、クライアントとレンダリングされたServer Component treesを統合して、DOMを更新するために使用されます。 -3. JavaScript命令は、クライアント Componentsを[実行](https://react.dev/reference/react-dom/client/hydrateRoot)してアプリケーションを対話型にします。 +1. HTMLは、ClientおよびServer Componentsの非インタラクティブな初期プレビューをすぐに表示するために使用されます； +2. React Server Components Payloadは、ClientおよびレンダリングされたServer Component treeを調整し、DOMを更新するために使用されます； +3. JavaScript命令は、アプリケーションをインタラクトにするための[ハイドレート](https://react.dev/reference/react-dom/client/hydrateRoot)Client Componentsに使用されます； -### 4. クライアントでのNext.jsキャッシング（ルーターキャッシュ） {#4-next-js-caching-on-the-client-router-cache} +### 4. クライアントでのNext.jsキャッシング（Router Cache） {#4-next-js-caching-on-the-client-router-cache} -React Server Component Payloadは、クライアント側の[Router Cache](#client-side-router-cache)に格納されます。これは、個々のルートセグメントごとに分割されたメモリキャッシュです。このRouter Cacheは、以前に訪問したルートを保存し、将来的に訪問する可能性のあるルートを事前に取得するために使用されます。 +React Server Component Payloadは、クライアント側の[Router Cache](#client-side-router-cache)に保存されます。これは、個々のルートセグメントごとに分割された別のインメモリキャッシュです。このRouter Cacheは、以前に訪問されたルートを保存し、将来訪れる可能性があるルートをプリフェッチすることによって、ナビゲーション体験を向上させます； ### 5. 後続のナビゲーション {#5-subsequent-navigations} -後続のナビゲーションや事前取得中、Next.jsはRouter CacheにReact Server Components Payloadが保存されているかどうかを確認します。保存されている場合は、新しいサーバーリクエストを送信することをスキップします。 +後続のナビゲーションやプリフェッチ中に、Next.jsはReact Server Components PayloadがRouter Cacheに格納されているかどうかを確認します。それが存在する場合、新しいサーバへのリクエストをスキップします； -ルートセグメントがキャッシュにない場合、Next.jsはサーバーからReact Server Components Payloadを取得し、クライアントのRouter Cacheに追加します。 +ルートセグメントがキャッシュされていない場合、Next.jsはサーバからReact Server Componentsペイロードをフェッチし、クライアントでRouter Cacheを更新します； -### 静的と動的レンダリング {#static-and-dynamic-rendering} +### スタティックレンダリングと動的レンダリング {#static-and-dynamic-rendering} -ルートがビルドタイムにキャッシュされるかどうかは、そのルートが静的または動的にレンダリングされるかどうかに依存します。静的ルートはデフォルトでキャッシュされ、動的ルートはリクエスト時にレンダリングされ、キャッシュされません。 +ルートがビルド時にキャッシュされるかどうかは、静的にレンダリングされるか動的にレンダリングされるかによって決まります。静的ルートはデフォルトでキャッシュされますが、動的ルートはリクエスト時にレンダリングされ、キャッシュされません； -以下の図は、静的および動的にレンダリングされたルートの違いを示しており、キャッシュデータと非キャッシュデータが示されています： +この図は、キャッシュされたデータおよびキャッシュされていないデータを使用した静的レンダリングおよび動的レンダリングの違いを示しています： 静的および動的レンダリングがフルルートキャッシュに与える影響を示す図。静的ルートはビルドタイムまたはデータ再検証後にキャッシュされ、動的ルートは決してキャッシュされない。 -[静的および動的レンダリング](/docs/app/building-your-application/rendering/server-components#server-rendering-strategies)について詳しく学ぶ。 +[静的レンダリングと動的レンダリング](/docs/app/building-your-application/rendering/server-components#server-rendering-strategies)について詳しく学んでください； ### 期間 {#duration} -デフォルトでは、フルルートキャッシュは永続的です。これは、レンダー出力がユーザーリクエスト間でキャッシュされることを意味します。 +デフォルトで、Full Route Cacheは永続的です。これは、レンダリングの出力がユーザーのリクエストにわたってキャッシュされることを意味します； ### 無効化 {#invalidation} -フルルートキャッシュを無効化する方法は2つあります： +Full Route Cacheを無効にする2つの方法があります： -- **[データの再検証](/docs/app/building-your-application/caching#revalidating)**： データキャッシュを再検証すると、サーバー上でコンポーネントが再レンダリングされ、新しいレンダー出力がキャッシュされることでRouter Cacheも無効化されます。 -- **再デプロイ**： データキャッシュとは異なり、フルルートキャッシュは新しいデプロイメント時にクリアされます。 +- **[Revalidating Data](/docs/app/building-your-application/caching#revalidating)**: [Data Cache](#data-cache)を再検証することで、Router Cacheを無効にし、サーバでコンポーネントを再レンダリングし、新しいレンダリング結果をキャッシュします； +- **再デプロイ**: 入ってくるリクエストとデプロイメント間で永続的なData Cacheとは異なり、Full Route Cacheは新しいデプロイメントでクリアされます； ### オプトアウト {#opting-out} -フルルートキャッシュからオプトアウトすることができます。言い換えれば、各インカミングリクエストごとにコンポーネントを動的にレンダリングすることができます： +Full Route Cacheからオプトアウトする、つまり各着信リクエストごとにコンポーネントを動的にレンダリングするには、以下の方法があります： -- **[動的API](#dynamic-apis)の使用**： これはフルルートキャッシュからルートをオプトアウトし、リクエスト時に動的にレンダリングされることを意味します。データキャッシュは依然として使用できます。 -- ** `dynamic = 'force-dynamic'`または`revalidate = 0` ルートセグメント設定オプションを使用する**： これはフルルートキャッシュおよびデータキャッシュをスキップします。つまり、インカミングリクエストごとにサーバー上でコンポーネントがレンダリングされ、データが取得されます。ルートキャッシュはクライアント側のキャッシュであるため引き続き適用されます。 -- **[データキャッシュ](#data-cache)のオプトアウト**： `fetch`リクエストでキャッシュされないものがある場合、そのルートはフルルートキャッシュからオプトアウトします。特定の`fetch`リクエストに対して、インカミングリクエストごとにデータが取得されます。キャッシュオプトアウトしないその他の`fetch`リクエストは依然としてデータキャッシュにキャッシュされ続けます。これは、キャッシュされたデータとキャッシュされていないデータが共存するハイブリッドを可能にします。 +- **[Dynamic API](#dynamic-apis)を使用する**：これはFull Route Cacheからルートをオプトアウトし、リクエスト時に動的にレンダリングします。Data Cacheはまだ使用できます； +- **`dynamic = 'force-dynamic'`または`revalidate = 0`ルートセグメント設定オプションを使用する**：Full Route CacheとData Cacheをスキップします。つまり、サーバーへのすべてのリクエストごとにコンポーネントをレンダリングし、データを取得します。Router Cacheはクライアントサイドのキャッシュであるため、まだ適用されます； +- **[Data Cache](#data-cache)からオプトアウトする**：キャッシュされていない`fetch`リクエストを持つルートがある場合、これはルートをFull Route Cacheからオプトアウトします。特定の`fetch`リクエストのデータはすべてのリクエストごとにフェッチされます。キャッシュからオプトアウトしない他のリクエストはData Cacheにキャッシュされ続けます。これにより、キャッシュされたデータとキャッシュされていないデータのハイブリッドを作成できます； -## クライアントサイドのルーターキャッシュ {#client-side-router-cache} +## クライアントサイドRouter Cache {#client-side-router-cache} -Next.jsには、レイアウト、読み込み状態、ページごとに分割されたルートセグメントのRSCペイロードを格納するメモリ内クライアントサイドルーターキャッシュがあります。 +Next.jsには、ルートセグメントのRSCペイロードをレイアウト、ローディング状態、ページに分割してキャッシュするインメモリのクライアントサイドルータキャッシュがあります； -ユーザーがルート間を移動するとき、Next.jsは訪問したルートセグメントをキャッシュし、ユーザーが訪問する可能性があるルートを[事前取得](/docs/app/building-your-application/routing/linking-and-navigating#2-prefetching)します。これにより、瞬時のバック/フォワードナビゲーション、ナビゲーション間の全ページ更新の不要、React状態やブラウザ状態の保持が実現されます。 +ユーザーがルート間を移動すると、Next.jsは訪れたルートセグメントをキャッシュし、ユーザーが次に移動する可能性が高いルートを[prefetch](/docs/app/building-your-application/routing/linking-and-navigating#2-prefetching)します。これにより、前後のナビゲーションが即座に行われ、ナビゲーション間での全ページの再読み込みがなく、Reactステートとブラウザステートが維持されます； -ルーターキャッシュを使用することで： +Router Cacheを使用することで： -- **レイアウト**はキャッシュされ、ナビゲーション時に再利用されます（[部分レンダリング](/docs/app/building-your-application/routing/linking-and-navigating#4-partial-rendering)）。 -- **読み込み状態**はルート間の瞬時のナビゲーションのためにキャッシュされ再利用されます（[瞬時読み込み状態](/docs/app/building-your-application/routing/loading-ui-and-streaming#instant-loading-states)）。 -- **ページ** はデフォルトでキャッシュされませんが、ブラウザの前後のナビゲーション時に再利用されます。[実験オプション`staleTimes`](/docs/app/api-reference/config/next-config-js/staleTimes)を使ってページセグメントをキャッシュすることができます。 +- **レイアウト**はキャッシュされ、ナビゲーション時に再利用されます（[partial rendering](/docs/app/building-your-application/routing/linking-and-navigating#4-partial-rendering)）； +- **ローディング状態**はナビゲーション時にキャッシュされ、[インスタントナビゲーション](/docs/app/building-your-application/routing/loading-ui-and-streaming#instant-loading-states)に再利用されます； +- **ページ**はデフォルトではキャッシュされませんが、ブラウザの後ろ向きおよび前向きナビゲーション中に再利用されます。実験的な[`staleTimes`](/docs/app/api-reference/config/next-config-js/staleTimes)設定オプションを使用してページセグメントのキャッシュを有効にできます； -{/* TODO: 図をv15の動作に合わせて更新する */} +{/* TODO: v15の動作に合わせて図を更新 */} -> **Good to know:** このキャッシュはNext.jsとServer Componentsに特有であり、ブラウザの[bfcache](https://web.dev/bfcache/)とは異なりますが、似たような結果をもたらします。 +> **Good to know:** このキャッシュは特にNext.jsおよびServer Componentsに適用され、ブラウザの[bfcache](https://web.dev/bfcache/)とは異なりますが、同様の結果を持っています； ### 期間 {#duration} -キャッシュはブラウザの一時メモリに格納されます。2つの要因がルーターキャッシュの存続期間を決定します： +キャッシュはブラウザの一時メモリに保存されます。2つの要素がルータキャッシュの持続時間を決定します： -- **セッション**： ナビゲーション中にキャッシュは持続します。ただし、ページの再読み込みでクリアされます。 -- **自動無効化期間**： レイアウトと読み込み状態のキャッシュは、指定された時間後に自動的に無効化されます。期間は、リソースがどのように[事前取得された](/docs/app/api-reference/components/link#prefetch)か、そしてリソースが[静的に生成された](/docs/app/building-your-application/rendering/server-components#static-rendering-default)かに依存します： - - **デフォルトの事前取得**（`prefetch={null}`または指定なし）： 動的ページにはキャッシュされません、静的ページには5分間。 - - **完全な事前取得**（`prefetch={true}`または`router.prefetch`）： 静的および動的ページの両方に対して5分間。 +- **セッション**：キャッシュはナビゲーション中に永続します。ただし、ページの更新時にはクリアされます； +- **自動無効化期間**：レイアウトとローディング状態のキャッシュは指定された時間が経過すると自動的に無効化されます。この期間はリソースが[prefetch](/docs/app/api-reference/components/link#prefetch)された方法やリソースが[静的に生成](/docs/app/building-your-application/rendering/server-components#static-rendering-default)されたかどうかによって異なります： + - **デフォルトプリフェッチ** (`prefetch={null}`または指定なし)：動的ページのためにはキャッシュされず、静的ページのためには5分間； + - **フルプリフェッチ** (`prefetch={true}`または`router.prefetch`)：静的および動的ページの両方が5分間； -ページの再読み込みは**すべて**のキャッシュセグメントをクリアしますが、自動無効化期間は、事前取得された時間からの個々のセグメントのみに影響します。 +ページ更新時には**すべて**キャッシュされたセグメントがクリアされますが、自動無効化期間はプリフェッチされた時からの個々のセグメントにのみ影響します； -> **Good to know**: 実験オプション[`staleTimes`](/docs/app/api-reference/config/next-config-js/staleTimes)を使用して上記の自動無効化時間を調整することができます。 +> **Good to know**: 実験的な[`staleTimes`](/docs/app/api-reference/config/next-config-js/staleTimes)設定オプションを使用して上記の自動無効化時間を調整できます； ### 無効化 {#invalidation} -ルーターキャッシュを無効化する方法は次の2つです： +Router Cacheを無効にする2つの方法があります： -- **Server Action** の中で： - - パスでのオンデマンド再検証は（[`revalidatePath`](/docs/app/api-reference/functions/revalidatePath)）タグでのキャッシュ再検証は（[`revalidateTag`](/docs/app/api-reference/functions/revalidateTag)） - - [`cookies.set`](/docs/app/api-reference/functions/cookies#setting-a-cookie)または[`cookies.delete`](/docs/app/api-reference/functions/cookies#deleting-cookies)を使用してルーターキャッシュを無効にし、クッキーを使用するルートが古くなるのを防ぐ（例：認証）。 -- [`router.refresh`](/docs/app/api-reference/functions/use-router)を呼び出すことでルーターキャッシュを無効にし、現在のルートに対するサーバーへの新しいリクエストを行う。 +- **Server Action**内で： + - パスでのオンデマンドデータ再検証（[`revalidatePath`](/docs/app/api-reference/functions/revalidatePath)）またはキャッシュタグでの（[`revalidateTag`](/docs/app/api-reference/functions/revalidateTag)）； + - [`cookies.set`](/docs/app/api-reference/functions/cookies#setting-a-cookie)または[`cookies.delete`](/docs/app/api-reference/functions/cookies#deleting-cookies)を使用すると、ルートが古くならないようにするためにRouter Cacheが無効化されます（例：認証）； +- [`router.refresh`](/docs/app/api-reference/functions/use-router)を呼び出すとRouter Cacheが無効化され、現在のルートに対してサーバーへの新しいリクエストが行われます； ### オプトアウト {#opting-out} -Next.js 15以降、ページセグメントはデフォルトでオプトアウトされています。 +Next.js 15以降、ページセグメントはデフォルトでオプトアウトされています； -> **Good to know:** ``コンポーネントの`prefetch`プロップを`false`に設定することで、[事前取得](/docs/app/building-your-application/routing/linking-and-navigating#2-prefetching)をオプトアウトすることもできます。 +> **Good to know:** ``コンポーネントの`prefetch`プロップを`false`に設定することで[prefetch](/docs/app/building-your-application/routing/linking-and-navigating#2-prefetching)もオプトアウトできます。 ## キャッシュの相互作用 {#cache-interactions} -さまざまなキャッシングメカニズムを設定する際、相互作用を理解することが重要です： +異なるキャッシングメカニズムを設定する際に、それらがどのように相互作用するかを理解することが重要です： -### データキャッシュとフルルートキャッシュ {#data-cache-and-full-route-cache} +### Data CacheとFull Route Cache {#data-cache-and-full-route-cache} -- データキャッシュを再検証またはオプトアウトすることは、フルルートキャッシュを無効化します。なぜなら、レンダー出力はデータに依存しているからです。 -- フルルートキャッシュを無効化またはオプトアウトしても、データキャッシュには影響しません。キャッシュされたデータとキャッシュされていないデータの両方を持つルートを動的にレンダリングできます。たとえば、ほとんどのページがキャッシュされたデータを使用する場合でも、いくつかのコンポーネントがリクエスト時に取得する必要のあるデータに依存していることに有用です。すべてのデータを再取得する際のパフォーマンスへの影響を心配せずに動的レンダリングできます。 +- Data Cacheを再検証またはオプトアウトすると、レンダリングの出力がデータに依存しているため、Full Route Cacheが無効になります； +- Full Route Cacheを無効化またはオプトアウトしても、Data Cacheには影響しません。キャッシュされたデータとキャッシュされていないデータの両方を持つルートを動的にレンダリングすることができます。これは、ページのほとんどがキャッシュされたデータを使用しており、リクエスト時にフェッチする必要があるデータを使用しているコンポーネントがいくつかある場合に便利です。すべてのデータを再フェッチするパフォーマンス影響を心配せずに動的にレンダリングできます； -### データキャッシュとクライアントサイドのルーターキャッシュ {#data-cache-and-client-side-router-cache} +### Data CacheとClient-side Router cache {#data-cache-and-client-side-router-cache} -- データキャッシュとルーターキャッシュを即座に無効化するには[Server Action](/docs/app/building-your-application/data-fetching/server-actions-and-mutations)で[`revalidatePath`](#revalidatepath)または[`revalidateTag`](#fetch-optionsnexttags-and-revalidatetag)を使用できます。 -- [Route Handler](/docs/app/building-your-application/routing/route-handlers)でデータキャッシュを再検証しても、Router Cacheは直ちには無効化されません。これらのRoute Handlerは特定のルートに結び付けられていないため、Router Cacheはハードリフレッシュまたは自動無効化期間が経過するまで以前のペイロードを提供し続けます。 +- Data CacheとRouter cacheを即座に無効にするには、[Server Action](/docs/app/building-your-application/data-fetching/server-actions-and-mutations)で[`revalidatePath`](#revalidatepath)または[`revalidateTag`](#fetch-optionsnexttags-and-revalidatetag)を使用します； +- [Route Handler](/docs/app/building-your-application/routing/route-handlers)でのData Cacheの再検証は、Router Handlerが特定のルートに関連付けられていないため、Router Cacheを即座に無効に**しません**。これにより、Router Cacheはハードリフレッシュまたは自動無効化期間が経過するまで前のペイロードを提供し続けます； ## API {#apis} -次の表は、さまざまなNext.js APIがキャッシングにどのような影響を与えるかの概要を示しています： - -| API | Router Cache | フルルートキャッシュ | Data Cache | React Cache | -| ----------------------------------------------------------------------- | -------------------------- | --------------------- | --------------------- | ----------- | -| [``](#link) | Cache | | | | -| [`router.prefetch`](#routerprefetch) | Cache | | | | -| [`router.refresh`](#routerrefresh) | Revalidate | | | | -| [`fetch`](#fetch) | | | Cache | Cache | -| [`fetch` `options.cache`](#fetch-optionscache) | | | Cache or Opt out | | -| [`fetch` `options.next.revalidate`](#fetch-optionsnextrevalidate) | | Revalidate | Revalidate | | -| [`fetch` `options.next.tags`](#fetch-optionsnexttags-and-revalidatetag) | | Cache | Cache | | -| [`revalidateTag`](#fetch-optionsnexttags-and-revalidatetag) | Revalidate (Server Action) | Revalidate | Revalidate | | -| [`revalidatePath`](#revalidatepath) | Revalidate (Server Action) | Revalidate | Revalidate | | -| [`const revalidate`](#segment-config-options) | | Revalidate or Opt out | Revalidate or Opt out | | -| [`const dynamic`](#segment-config-options) | | Cache or Opt out | Cache or Opt out | | -| [`cookies`](#cookies) | Revalidate (Server Action) | Opt out | | | -| [`headers`, `searchParams`](#dynamic-apis) | | Opt out | | | -| [`generateStaticParams`](#generatestaticparams) | | Cache | | | -| [`React.cache`](#react-cache-function) | | | | Cache | -| [`unstable_cache`](/docs/app/api-reference/functions/unstable_cache) | | | Cache | | +以下の表は、さまざまなNext.jsのAPIがキャッシングにどのように影響するかの概要を示します： + +| API | ルーターキャッシュ | Full Route Cache | Data Cache | React Cache | +| ----------------------------------------------------------------------- | ----------------------- | ---------------------------- | ---------------------------- | ----------- | +| [``](#link) | キャッシュ | | | | +| [`router.prefetch`](#routerprefetch) | キャッシュ | | | | +| [`router.refresh`](#routerrefresh) | 再検証 | | | | +| [`fetch`](#fetch) | | | キャッシュ | キャッシュ | +| [`fetch` `options.cache`](#fetch-optionscache) | | | キャッシュまたはオプトアウト | | +| [`fetch` `options.next.revalidate`](#fetch-optionsnextrevalidate) | | 再検証 | 再検証 | | +| [`fetch` `options.next.tags`](#fetch-optionsnexttags-and-revalidatetag) | | キャッシュ | キャッシュ | | +| [`revalidateTag`](#fetch-optionsnexttags-and-revalidatetag) | 再検証（Server Action） | 再検証 | 再検証 | | +| [`revalidatePath`](#revalidatepath) | 再検証（Server Action） | 再検証 | 再検証 | | +| [`const revalidate`](#segment-config-options) | | 再検証またはオプトアウト | 再検証またはオプトアウト | | +| [`const dynamic`](#segment-config-options) | | キャッシュまたはオプトアウト | キャッシュまたはオプトアウト | | +| [`cookies`](#cookies) | 再検証（Server Action） | オプトアウト | | | +| [`headers`, `searchParams`](#dynamic-apis) | | オプトアウト | | | +| [`generateStaticParams`](#generatestaticparams) | | キャッシュ | | | +| [`React.cache`](#react-cache-function) | | | | キャッシュ | +| [`unstable_cache`](/docs/app/api-reference/functions/unstable_cache) | | | キャッシュ | | ### `` {#link} -デフォルトでは、``コンポーネントはフルルートキャッシュからルートを自動的に事前取得し、Router CacheにReact Server Component Payloadを追加します。 +デフォルトで、``コンポーネントはFull Route Cacheからルートを自動的にプリフェッチし、React Server Component PayloadをRouter Cacheに追加します； -事前取得を無効にするには、`prefetch`プロパティを`false`に設定します。ただし、これはキャッシュを永続的にスキップすることはなく、ユーザーがルートを訪問したときにルートセグメントはクライアント側でキャッシュされます。 +プリフェッチを無効にするには、`prefetch`プロップを`false`に設定します。しかし、これはキャッシュを永続的にスキップすることはありません。ユーザーがルートを訪れると、ルートセグメントはクライアントサイドでキャッシュされます； -[``コンポーネント](/docs/app/api-reference/components/link)の詳細を学ぶ。 +[``コンポーネント](/docs/app/api-reference/components/link)について詳しく学びましょう； ### `router.prefetch` {#router-prefetch} -`useRouter`フックの`prefetch`プロパティを使用して、ルートを手動で事前取得できます。これにより、Router CacheにReact Server Component Payloadを追加します。 +`useRouter`フックの`prefetch`オプションを使用して、手動でルートをプリフェッチできます。これにより、React Server Component PayloadがRouter Cacheに追加されます； -[`useRouter`フック](/docs/app/api-reference/functions/use-router)のAPIリファレンスを参照してください。 +[`useRouter`フック](/docs/app/api-reference/functions/use-router)のAPI参照を参照してください； ### `router.refresh` {#router-refresh} -`useRouter`フックの`refresh`プロパティを使用して、ルートを手動で更新できます。これによりRouter Cacheが完全にクリアされ、現在のルートに対するサーバーへの新しいリクエストが行われます。`refresh`はデータキャッシュまたはフルルートキャッシュには影響を与えません。 +`useRouter`フックの`refresh`オプションを使用して、手動でルートをリフレッシュできます。これにより、Router Cacheが完全にクリアされ、現在のルートに対してサーバーに新しいリクエストが行われます。`refresh`はDataまたはFull Route Cacheには影響しません； -描画結果はクライアント側で統合され、React状態やブラウザ状態が保持されます。 +レンダリングされた結果はReact状態とブラウザ状態を保持しながらクライアント上で調整されます； -[`useRouter`フック](/docs/app/api-reference/functions/use-router)のAPIリファレンスを参照してください。 +[`useRouter`フック](/docs/app/api-reference/functions/use-router)のAPI参照を参照してください； ### `fetch` {#fetch} -`fetch`から返されたデータは、自動的にデータキャッシュにキャッシュされます。 +`fetch`から返されるデータは、Data Cacheに自動的にキャッシュ**されません**； -`fetch`からの応答をキャッシュしたくない場合、以下のようにできます： +`fetch`のデフォルトのキャッシング動作（例：`cache`オプションが指定されていない場合）は、次のコードにおいて`cache`オプションが`no-store`に設定されているのと同等です： ```js let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' }) ``` -[`fetch` APIリファレンス](/docs/app/api-reference/functions/fetch)でその他のオプションを確認してください。 +[`fetch` API Reference](/docs/app/api-reference/functions/fetch)で他のオプションを参照してください； ### `fetch options.cache` {#fetch-options-cache} -個々の`fetch`をキャッシュにオプトインする場合、`cache`オプションを`force-cache`に設定します： +個々の`fetch`をキャッシュするためには、`cache`オプションを`force-cache`に設定します： ```jsx -// キャッシュにオプトイン +// キャッシュへオプトインする fetch(`https://...`, { cache: 'force-cache' }) ``` -[`fetch` APIリファレンス](/docs/app/api-reference/functions/fetch)でその他のオプションを確認してください。 +[`fetch` API Reference](/docs/app/api-reference/functions/fetch)で他のオプションを参照してください； ### `fetch options.next.revalidate` {#fetch-options-next-revalidate} -`fetch`の`next.revalidate`オプションを使用して、個々の`fetch`リクエストの再検証期間（秒単位）を設定することができます。これによりデータキャッシュが再検証され、結果としてフルルートキャッシュも再検証されます。新鮮なデータが取得され、コンポーネントがサーバー上で再レンダリングされます。 +`fetch`の`next.revalidate`オプションを使用して、個々の`fetch`リクエストの再検証期間（秒単位）を設定できます。これによりData Cacheが再検証され、その結果Full Route Cacheも再検証されます。新鮮なデータがフェッチされ、コンポーネントがサーバーで再レンダリングされます； ```jsx -// 最大1時間後に再検証 +// 最長で1時間後に再検証 fetch(`https://...`, { next: { revalidate: 3600 } }) ``` -[`fetch` APIリファレンス](/docs/app/api-reference/functions/fetch)でその他のオプションを確認してください。 +[`fetch` API reference](/docs/app/api-reference/functions/fetch)で他のオプションを参照してください； -### `fetch options.next.tags` and `revalidateTag` {#fetch-options-next-tags-and-revalidatetag} +### `fetch options.next.tags`と`revalidateTag` {#fetch-options-next-tags-and-revalidatetag} -Next.jsには、細かなデータキャッシングと再検証のためのキャッシュタグシステムがあります。 +Next.jsには細かいデータキャッシングと再検証のためのキャッシュタグシステムがあります； -1. `fetch`や[`unstable_cache`](/docs/app/api-reference/functions/unstable_cache)を使用するときに、キャッシュエントリを1つ以上のタグでタグ付けするオプションがあります。 -2. その後、タグに関連付けられたキャッシュエントリを削除するために`revalidateTag`を呼び出すことができます。 +1. `fetch`または[`unstable_cache`](/docs/app/api-reference/functions/unstable_cache)を使用すると、キャッシュエントリに1つまたは複数のタグを設定するオプションがあります； +2. 次に、特定のタグに関連するキャッシュエントリをパージするために`revalidateTag`を呼び出すことができます； -たとえば、データを取得する際にタグを設定できます： +例えば、データをフェッチする際にタグを設定することができます： ```jsx -// データをタグでキャッシュ +// タグでデータをキャッシュ fetch(`https://...`, { next: { tags: ['a', 'b', 'c'] } }) ``` -次に、特定のタグを持つキャッシュエントリを削除して`revalidateTag`を呼び出します： +次に、タグでキャッシュエントリをパージするために`revalidateTag`を呼び出します： ```jsx // 特定のタグを持つエントリを再検証 revalidateTag('a') ``` -使用目的によって、`revalidateTag`を次の場所で使用できます： +次の2つの場所で、目的に応じて`revalidateTag`を使用できます： -1. [Route Handlers](/docs/app/building-your-application/routing/route-handlers) - サードパーティーイベント（例：Webhook）の応答としてデータを再検証する。 - -2. [Server Actions](/docs/app/building-your-application/data-fetching/server-actions-and-mutations) - ユーザーアクション（例：フォーム送信）後にデータを再検証する。 この場合、関連するルートのRouter Cacheは無効化されます。 +1. [Route Handlers](/docs/app/building-your-application/routing/route-handlers) - サードパーティイベント（例：Webhook）に応じてデータを再検証するため。これによりRouter Cacheが即座には無効化されません。Router Handlerが特定のルートに関連付けられていないためです； +2. [Server Actions](/docs/app/building-your-application/data-fetching/server-actions-and-mutations) - ユーザーアクション（例：フォーム送信）後にデータを再検証するため。これにより対応するルートに対するRouter Cacheが無効化されます； ### `revalidatePath` {#revalidatepath} -`revalidatePath`を使って、特定のパス以下のルートセグメントを再レンダリングしつつデータを手動で再検証することが可能です。このメソッドを呼び出すことでデータキャッシュが再検証され、その結果フルルートキャッシュも無効化されます。 +`revalidatePath`を使用すると、データの再検証を手動で行い、特定のパスの下のルートセグメントを単一の操作で再レンダリングできます。`revalidatePath`メソッドを呼び出すと、データキャッシュが再検証され、その結果Full Route Cacheが無効化されます； ```jsx revalidatePath('/') ``` -使用目的によって、`revalidatePath`を次の場所で使用できます： +次の2つの場所で、目的に応じて`revalidatePath`を使用できます： -1. [Route Handlers](/docs/app/building-your-application/routing/route-handlers) - サードパーティーイベント（例：Webhook）の応答としてデータを再検証する。 -2. [Server Actions](/docs/app/building-your-application/data-fetching/server-actions-and-mutations) - ユーザーインタラクション（例：フォーム送信、ボタンのクリック）後にデータを再検証する。 +1. [Route Handlers](/docs/app/building-your-application/routing/route-handlers) - サードパーティイベント（例：Webhook）に応じてデータを再検証するため； +2. [Server Actions](/docs/app/building-your-application/data-fetching/server-actions-and-mutations) - ユーザーインタラクション（例：フォーム送信、ボタンのクリック）後にデータを再検証するため； -[`revalidatePath` APIリファレンス](/docs/app/api-reference/functions/revalidatePath)で詳細を確認してください。 +[`revalidatePath` API参照](/docs/app/api-reference/functions/revalidatePath)で詳しい情報をご確認ください； -> **`revalidatePath`** と **`router.refresh`**： +> **`revalidatePath`** vs. **`router.refresh`**： > -> `router.refresh`を呼び出すと、Router Cacheがクリアされ、サーバー上でルートセグメントが再レンダリングされますが、データキャッシュやフルルートキャッシュは無効化されません。 +> `router.refresh`を呼び出すとRouter cacheがクリアされ、データキャッシュやFull Route Cacheを無効にせずにサーバーでルートセグメントが再レンダリングされます； > -> `revalidatePath`はデータキャッシュとフルルートキャッシュをクリアしますが、`router.refresh()`はデータキャッシュとフルルートキャッシュを変更しないという違いがあります。 +> 違いは、`revalidatePath`はデータキャッシュとFull Route Cacheをパージする一方、`router.refresh()`はデータキャッシュとFull Route Cacheを変更しないクライアントサイドAPIであるということです； -### 動的API {#dynamic-apis} +### Dynamic API {#dynamic-apis} -`cookies`や`headers`のような動的API、およびPages内の`searchParams`プロップは実行時のインカミングリクエスト情報に依存します。これらを使用すると、ルートがフルルートキャッシュからオプトアウトし、つまり、ルートが動的にレンダリングされることになります。 +`cookies`や`headers`のようなDynamic API、またPagesにおける`searchParams`プロップは、実行時の受信リクエスト情報に依存しています。それらを使用すると、ルートはFull Route Cacheからオプトアウトされ、動的にレンダリングされます； #### `cookies` {#cookies} -Server Action内で`cookies.set`または`cookies.delete`を使用すると、それを使用するルートが古くならないように、Router Cacheを無効にします（例：認証の変更を反映するため）。 +Server Action内で`cookies.set`または`cookies.delete`を使用すると、認証の変更を反映するため（例：認証の変更）にRouter Cacheが無効化されます； -[`cookies`](/docs/app/api-reference/functions/cookies) APIリファレンスを参照してください。 +[`cookies`](/docs/app/api-reference/functions/cookies) API参照を参照してください； -### セグメント設定オプション {#segment-config-options} +### Segment Config Options {#segment-config-options} -ルートセグメント設定オプションは、`fetch` APIを使用できない場合（例：データベースクライアントやサードパーティライブラリ）またはデフォルトを上書きする場合に、ルートセグメントの設定をオーバーライドするために使用できます。 +Route Segment Configオプションは、ルートセグメントのデフォルトをオーバーライドするため、または`fetch` APIを使用できない場合（例：データベースクライアントや3rdパーティのライブラリ）に使用できます； -次のルートセグメント設定オプションはフルルートキャッシュをオプトアウトします： +次のRoute Segment Configオプションは、Full Route Cacheからオプトアウトします： - `const dynamic = 'force-dynamic'` -この設定オプションは、すべてのフェッチをデータキャッシュからオプトアウトします（すなわち`no-store`）： +この設定オプションは、すべてのフェッチをData Cacheからオプトアウトします（例：`no-store`）： - `const fetchCache = 'default-no-store'` -[`fetchCache`](/docs/app/api-reference/file-conventions/route-segment-config#fetchcache)でより高度なオプションを確認してください。 +[`fetchCache`](/docs/app/api-reference/file-conventions/route-segment-config#fetchcache)でより詳細なオプションをご覧ください； -[ルートセグメント設定](/docs/app/api-reference/file-conventions/route-segment-config)のドキュメントで詳細なオプションを確認してください。 +[Route Segment Config](/docs/app/api-reference/file-conventions/route-segment-config)ドキュメントで他のオプションをご覧ください； ### `generateStaticParams` {#generatestaticparams} -[動的セグメント](/docs/app/building-your-application/routing/dynamic-routes)（例：`app/blog/[slug]/page.js`）について、`generateStaticParams`によって提供されるパスはビルドタイムにフルルートキャッシュにキャッシュされます。リクエスト時にNext.jsはビルドタイムに知られていなかったパスを初めて訪問した際にもキャッシュします。 +[動的セグメント](/docs/app/building-your-application/routing/dynamic-routes)（例：`app/blog/[slug]/page.js`）の場合、`generateStaticParams`によって提供されるパスはビルド時にFull Route Cacheにキャッシュされます。リクエスト時には、ビルド時に不明だったパスも最初に訪問されたときにキャッシュされます； -ビルドタイムにすべてのパスを静的にレンダリングするには、`generateStaticParams`にパスの完全なリストを提供します： +ビルド時にすべてのパスを静的にレンダリングするには、`generateStaticParams`に完全なパスリストを提供します： ```jsx title="app/blog/[slug]/page.js" export async function generateStaticParams() { @@ -544,20 +543,20 @@ export async function generateStaticParams() { } ``` -ビルドタイムに一部のパスを静的にレンダリングし、残りは実行時に初めて訪問したときにレンダリングするには、部分的なパスのリストを返します： +ビルド時にパスのサブセットを静的にレンダリングし、その後のパスを実行時に初めて訪問されたときにレンダリングするには、部分的なパスリストを返します： ```jsx title="app/blog/[slug]/page.js" export async function generateStaticParams() { const posts = await fetch('https://.../posts').then((res) => res.json()) - // ビルドタイムに最初の10投稿をレンダリングする + // 最初の10件の投稿をビルド時にレンダリング return posts.slice(0, 10).map((post) => ({ slug: post.slug, })) } ``` -訪問時に初めてすべてのパスを静的にレンダリングするには、空の配列を返します（ビルドタイムにはパスはレンダリングされませnん）または[`export const dynamic = 'force-static'`](/docs/app/api-reference/file-conventions/route-segment-config#dynamic)を利用します： +最初に訪問されたときにすべてのパスを静的にレンダリングするには、空の配列を返す（ビルド時にはパスがレンダリングされない）か、[`export const dynamic = 'force-static'`](/docs/app/api-reference/file-conventions/route-segment-config#dynamic)を利用します： ```jsx title="app/blog/[slug]/page.js" export async function generateStaticParams() { @@ -565,19 +564,19 @@ export async function generateStaticParams() { } ``` -> **Good to know:** `generateStaticParams`から配列を返す必要があります。たとえそれが空でもそうです。さもなければ、ルートは動的にレンダリングされます。 +> **Good to know:** `generateStaticParams`では、たとえ空でも配列を返す必要があります。そうしないと、ルートは動的にレンダリングされます； ```jsx title="app/changelog/[slug]/page.js" export const dynamic = 'force-static' ``` -リクエスト時のキャッシングを無効にするには、ルートセグメントに`export const dynamicParams = false`オプションを追加します。この設定オプションが使用された場合、`generateStaticParams`によって提供されたパスのみが提供され、その他のルートは404になったり（一致した場合には[catch-all routes](/docs/app/building-your-application/routing/dynamic-routes#catch-all-segments)）になります。 +リクエスト時のキャッシングを無効にするには、ルートセグメントに`export const dynamicParams = false`オプションを追加します。この設定オプションが使用されると、`generateStaticParams`で提供されたパスのみが提供され、他のルートは404を返します（[catch-all ルート](/docs/app/building-your-application/routing/dynamic-routes#catch-all-segments)）に一致する場合があります； ### React `cache`関数 {#react-cache-function} -Reactの`cache`関数を使用すると、関数の戻り値をメモ化でき、同じ関数を複数回呼び出しながらも、一度だけ実行することができます。 +Reactの`cache`関数を使用すると、関数の戻り値をメモ化することができ、同じ関数を複数回呼び出しても1回だけ実行されます； -`fetch`リクエストは自動的にメモ化されるため、React `cache`でラップする必要はありませんが、`fetch` APIが適さない場合にデータリクエストを手動でメモ化するために`cache`を使用することができます。例えば、一部のデータベースクライアント、CMSクライアント、またはGraphQLクライアントなどの場合。 +`fetch`リクエストは自動的にメモ化されるため、React `cache`でラップする必要はありません。ただし、`fetch` APIが適さないユースケースの場合に、データリクエストを手動でメモ化するために`cache`を使用できます。例えば、いくつかのデータベースクライアント、CMSクライアント、またはGraphQLクライアントです； diff --git a/docs/01-app/02-building-your-application/06-optimizing/02-videos.mdx b/docs/01-app/02-building-your-application/06-optimizing/02-videos.mdx index 1443435d..53ddada1 100644 --- a/docs/01-app/02-building-your-application/06-optimizing/02-videos.mdx +++ b/docs/01-app/02-building-your-application/06-optimizing/02-videos.mdx @@ -1,18 +1,18 @@ --- -title: 'ビデオ最適化' -nav_title: 'ビデオ' -description: 'Next.jsアプリケーションでのビデオ最適化のための推奨事項とベストプラクティス' +title: 'Video Optimization' +nav_title: 'Videos' +description: 'Next.jsアプリケーションで動画を最適化するための推奨とベストプラクティス。' --- -このページでは、Next.jsアプリケーションでビデオをどのように使用するかを説明し、パフォーマンスに影響を与えずにビデオファイルを保存して表示する方法を示します。 +このページでは、Next.jsアプリケーションで動画をどのように利用するかを説明し、パフォーマンスに影響を与えずに動画ファイルを保存・表示する方法を示します。 -## `