From d17ae5c54402780711a395ee87fdfb97a256ccf0 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 30 Oct 2024 01:06:13 +0900 Subject: [PATCH] konjacbot: sync docs@acd89db (#253) * sync docs@acd89db * fix build error * fix --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: ytori --- .../02-data-fetching/01-fetching.mdx | 154 +++--- .../03-rendering/01-server-components.mdx | 106 ++--- .../04-caching/index.mdx | 440 +++++++++--------- .../10-deploying/01-production-checklist.mdx | 130 +++--- .../11-upgrading/02-version-15.mdx | 110 ++--- .../02-api-reference/01-directives/index.mdx | 10 + .../01-directives/use-cache.mdx | 382 +++++++++++++++ .../01-directives/use-client.mdx | 107 +++++ .../01-directives/use-server.mdx | 200 ++++++++ .../{01-components => 02-components}/font.mdx | 0 .../{01-components => 02-components}/form.mdx | 0 .../image.mdx | 0 .../index.mdx | 0 .../{01-components => 02-components}/link.mdx | 0 .../script.mdx | 0 .../route-segment-config.mdx | 300 ------------ .../01-metadata/app-icons.mdx | 0 .../01-metadata/index.mdx | 0 .../01-metadata/manifest.mdx | 0 .../01-metadata/opengraph-image.mdx | 0 .../01-metadata/robots.mdx | 0 .../01-metadata/sitemap.mdx | 0 .../default.mdx | 0 .../error.mdx | 0 .../index.mdx | 0 .../instrumentation.mdx | 0 .../layout.mdx | 0 .../loading.mdx | 0 .../mdx-components.mdx | 0 .../middleware.mdx | 0 .../not-found.mdx | 0 .../page.mdx | 0 .../route-segment-config.mdx | 303 ++++++++++++ .../route.mdx | 0 .../template.mdx | 0 .../04-functions/cacheTag.mdx | 136 ++++++ .../04-functions/connection.mdx | 26 +- .../04-functions/unstable_cache.mdx | 100 ---- .../04-functions/unstable_noStore.mdx | 46 -- .../05-next-config-js/cacheLife.mdx | 49 ++ .../05-next-config-js/dynamicIO.mdx | 38 ++ .../02-api-reference/08-legacy-apis/index.mdx | 10 + .../08-legacy-apis/unstable_cache.mdx | 102 ++++ .../08-legacy-apis/unstable_noStore.mdx | 46 ++ docs/04-architecture/turbopack.mdx | 94 ++-- kj-diff.json | 54 ++- next.js | 2 +- static/img/docs/dark/data-cache.avif | Bin 17182 -> 16454 bytes static/img/docs/light/data-cache.avif | Bin 13706 -> 13069 bytes 49 files changed, 1961 insertions(+), 984 deletions(-) create mode 100644 docs/02-app/02-api-reference/01-directives/index.mdx create mode 100644 docs/02-app/02-api-reference/01-directives/use-cache.mdx create mode 100644 docs/02-app/02-api-reference/01-directives/use-client.mdx create mode 100644 docs/02-app/02-api-reference/01-directives/use-server.mdx rename docs/02-app/02-api-reference/{01-components => 02-components}/font.mdx (100%) rename docs/02-app/02-api-reference/{01-components => 02-components}/form.mdx (100%) rename docs/02-app/02-api-reference/{01-components => 02-components}/image.mdx (100%) rename docs/02-app/02-api-reference/{01-components => 02-components}/index.mdx (100%) rename docs/02-app/02-api-reference/{01-components => 02-components}/link.mdx (100%) rename docs/02-app/02-api-reference/{01-components => 02-components}/script.mdx (100%) delete mode 100644 docs/02-app/02-api-reference/02-file-conventions/route-segment-config.mdx rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/01-metadata/app-icons.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/01-metadata/index.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/01-metadata/manifest.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/01-metadata/opengraph-image.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/01-metadata/robots.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/01-metadata/sitemap.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/default.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/error.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/index.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/instrumentation.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/layout.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/loading.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/mdx-components.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/middleware.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/not-found.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/page.mdx (100%) create mode 100644 docs/02-app/02-api-reference/03-file-conventions/route-segment-config.mdx rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/route.mdx (100%) rename docs/02-app/02-api-reference/{02-file-conventions => 03-file-conventions}/template.mdx (100%) create mode 100644 docs/02-app/02-api-reference/04-functions/cacheTag.mdx delete mode 100644 docs/02-app/02-api-reference/04-functions/unstable_cache.mdx delete mode 100644 docs/02-app/02-api-reference/04-functions/unstable_noStore.mdx create mode 100644 docs/02-app/02-api-reference/05-next-config-js/cacheLife.mdx create mode 100644 docs/02-app/02-api-reference/05-next-config-js/dynamicIO.mdx create mode 100644 docs/02-app/02-api-reference/08-legacy-apis/index.mdx create mode 100644 docs/02-app/02-api-reference/08-legacy-apis/unstable_cache.mdx create mode 100644 docs/02-app/02-api-reference/08-legacy-apis/unstable_noStore.mdx diff --git a/docs/02-app/01-building-your-application/02-data-fetching/01-fetching.mdx b/docs/02-app/01-building-your-application/02-data-fetching/01-fetching.mdx index 9ddc24fb..d22cee8b 100644 --- a/docs/02-app/01-building-your-application/02-data-fetching/01-fetching.mdx +++ b/docs/02-app/01-building-your-application/02-data-fetching/01-fetching.mdx @@ -1,11 +1,11 @@ --- -title: 'データのフェッチとキャッシング' -nav_title: 'データのフェッチとキャッシング' -description: 'Next.jsでサーバまたはクライアント上でデータを取得するためのベストプラクティスを学びます。' +title: 'データフェッチとキャッシング' +nav_title: 'データフェッチとキャッシング' +description: 'Next.jsでサーバーまたはクライアント側でデータを取得するためのベストプラクティスを学びましょう。' ---
- 例 + Examples - [Next.js Commerce](https://vercel.com/templates/next.js/nextjs-commerce) - [On-Demand ISR](https://on-demand-isr.vercel.app) @@ -13,9 +13,9 @@ description: 'Next.jsでサーバまたはクライアント上でデータを
-このガイドでは、Next.jsにおけるデータのフェッチとキャッシングの基本を実践的な例やベストプラクティスを通じて説明します。 +このガイドでは、Next.jsにおけるデータフェッチとキャッシングの基本を、実践的な例とベストプラクティスを通じて案内します。 -ここにNext.jsでデータをフェッチするミニマルな例があります： +次のコードは、Next.jsでのデータフェッチのミニマムな例です： @@ -54,19 +54,19 @@ export default async function Page() { -この例は、非同期のReact Server Componentで`fetch` APIを使用して基本的なサーバサイドのデータ取得を実演しています。 +この例は、非同期React server component内で`fetch` APIを使用した基本的なサーバーサイドデータフェッチを示しています。 -## 参照 {#reference} +## リファレンス {#reference} - [`fetch`](/docs/app/api-reference/functions/fetch) - React [`cache`](https://react.dev/reference/react/cache) -- Next.js [`unstable_cache`](/docs/app/api-reference/functions/unstable_cache) +- Next.js [`unstable_cache`](/docs/app/api-reference/legacy-apis/unstable_cache) ## 例 {#examples} -### `fetch` APIを使用してサーバでデータを取得する {#fetching-data-on-the-server-with-the-fetch-api} +### `fetch` APIを使用したサーバーでのデータフェッチ {#fetching-data-on-the-server-with-the-fetch-api} -このコンポーネントはブログポストのリストを取得し表示します。`fetch`からのレスポンスは自動的にキャッシュされます。 +このコンポーネントはブログ投稿のリストをフェッチして表示します。`fetch`からのレスポンスは自動的にキャッシュされます。 @@ -105,17 +105,17 @@ export default async function Page() { -このルートの他の場所で[Dynamic APIs](/docs/app/building-your-application/rendering/server-components#dynamic-rendering)を使用していない場合、`next build`中に静的ページにプレンダリングされます。データは[Incremental Static Regeneration](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)を使用して更新できます。 +このルートの他の箇所で[Dynamic APIs](/docs/app/building-your-application/rendering/server-components#dynamic-rendering)を使用していない場合、`next build`中に静的ページとして事前レンダリングされます。このデータは[Incremental Static Regeneration](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)を使用して更新できます。 -`fetch`からのレスポンスをキャッシュしたくない場合は以下を行います： +`fetch`からのレスポンスをキャッシングしたくない場合、以下のように行えます： ```js let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' }) ``` -### ORMやデータベースを使用してサーバでデータを取得する {#fetching-data-on-the-server-with-an-orm-or-database} +### ORMまたはデータベースを使用したサーバーでのデータフェッチ {#fetching-data-on-the-server-with-an-orm-or-database} -このコンポーネントはブログポストのリストを取得し表示します。データベースからのレスポンスはデフォルトではキャッシュされませんが、[追加の設定](#caching-data-with-an-orm-or-database)でキャッシュされることもあります。 +このコンポーネントはブログ投稿のリストをフェッチして表示します。データベースからのレスポンスはデフォルトでキャッシュされませんが、[追加の設定](#caching-data-with-an-orm-or-database)でキャッシュされる可能性があります。 @@ -156,21 +156,21 @@ export default async function Page() { -このルートの他の場所で[Dynamic APIs](/docs/app/building-your-application/rendering/server-components#dynamic-rendering)を使用していない場合、`next build`中に静的ページにプレンダリングされます。データは[Incremental Static Regeneration](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)を使用して更新できます。 +このルートの他の箇所で[Dynamic APIs](/docs/app/building-your-application/rendering/server-components#dynamic-rendering)を使用していない場合、`next build`中に静的ページとして事前レンダリングされます。このデータは[Incremental Static Regeneration](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)を使用して更新できます。 -ページのプレンダリングを防ぐためには、以下をファイルに追加することができます： +ページの事前レンダリングを防ぐには、次のものをファイルに追加できます： ```js export const dynamic = 'force-dynamic' ``` -ただし、`cookies`や`headers`、ページpropsからの`searchParams`の読み取りなどの関数を通常使用すると、そのページは自動的に動的にレンダリングされます。この場合、`force-dynamic`を明示的に使う必要はありません。 +しかし、通常は、`cookies`、`headers`、またはページpropsからの`searchParams`の読み取りのような関数を使用し、自動的にページが動的にレンダリングされるようにします。この場合、明示的に`force-dynamic`を使用する必要はありません。 -### クライアントでデータを取得する {#fetching-data-on-the-client} +### クライアントでのデータフェッチ {#fetching-data-on-the-client} -まずはサーバ側でのデータフェッチを試みることをお勧めします。 +まず、サーバーサイドでのデータフェッチを試みることをお勧めします。 -ただし、クライアント側でのデータ取得が適しているケースもあります。こういった場合には、`useEffect`で`fetch`を手動で呼び出す（非推奨）か、クライアントフェッチに人気のあるReactライブラリ（[SWR](https://swr.vercel.app/)や[React Query](https://tanstack.com/query/latest)など）を利用することができます。 +ただし、クライアントサイドでのデータフェッチが意味を持つケースもあります。こういったシナリオでは、`useEffect`内で手動で`fetch`を呼び出すか（推奨されません）、コミュニティで人気のあるReactライブラリ（例： [SWR](https://swr.vercel.app/) または [React Query](https://tanstack.com/query/latest)）を活用してクライアントフェッチを行えます。 @@ -239,9 +239,9 @@ export function Posts() { -### ORMやデータベースを使用してデータをキャッシュする {#caching-data-with-an-orm-or-database} +### ORMまたはデータベースでデータをキャッシュする {#caching-data-with-an-orm-or-database} -`unstable_cache` APIを使用してレスポンスをキャッシュし、`next build`を実行するときにページをプレンダリングすることができます。 +`unstable_cache` APIを使用して、レスポンスをキャッシュし、`next build`を実行する際にページを事前レンダリングできるようにします。 @@ -302,13 +302,13 @@ export default async function Page() { -この例では、データベースクエリの結果を1時間（3600秒）キャッシュしています。また、キャッシュタグ`posts`を追加しており、後で[Incremental Static Regeneration](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)で無効化できます。 +この例では、データベースクエリの結果を1時間（3600秒）キャッシュします。また、キャッシュタグ`posts`を追加し、これにより[Incremental Static Regeneration](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)で無効化できます。 -### 複数の関数でデータを再利用する {#reusing-data-across-multiple-functions} +### 複数の関数間でデータを再利用する {#reusing-data-across-multiple-functions} -Next.jsでは、`generateMetadata`や`generateStaticParams`のようなAPIを使用して、ページでフェッチしたデータを再利用する必要があります。 +Next.jsでは、API `generateMetadata`や`generateStaticParams`を使用して、`page`で取得したのと同じデータを使う必要があります。 -`fetch`を使用している場合、リクエストは自動的に[メモ化](/docs/app/building-your-application/caching#request-memoization)されます。これは、同じURLと同じオプションで安全に呼び出すことができ、1つのリクエストのみが行われることを意味します。 +`fetch`を使用している場合、リクエストは自動的に[request memoization](/docs/app/building-your-application/caching#request-memoization)されます。これは、同じURLと同じオプションで安全に呼び出すと、1つのリクエストのみが行われることを意味します。 @@ -405,7 +405,7 @@ export default async function Page({ params }) { -`fetch`を使用していない場合、つまりORMやデータベースを直接使用している場合は、データの取得をReactの`cache`関数でラップすることができます。これにより、重複のない1つのクエリが作成されます。 +`fetch`を使用せず、代わりに直接ORMやデータベースを使用する場合、データフェッチをReactの`cache`関数でラップできます。これにより重複が排除され、1回のクエリのみが実行されます。 ```jsx import { cache } from 'react' @@ -422,32 +422,32 @@ export const getPost = cache(async (id) => { }) ``` -### キャッシュされたデータの再検証 {#revalidating-cached-data} +### キャッシュされたデータを再検証する {#revalidating-cached-data} -キャッシュされたデータの再検証については、[Incremental Static Regeneration](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)を参照してください。 +キャッシュされたデータを再検証する方法について、[Incremental Static Regeneration](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)で詳しく知ることができます。 ## パターン {#patterns} -### 並列および順次データフェッチ {#parallel-and-sequential-data-fetching} +### 並行データフェッチと逐次データフェッチ {#parallel-and-sequential-data-fetching} -コンポーネント内でデータをフェッチするときは、2つのデータフェッチパターンに注意する必要があります。ParallelとSequentialです。 +コンポーネント内でデータをフェッチする際には、2つのデータフェッチパターン：並行と逐次に注意する必要があります。 Sequential and Parallel Data Fetching -- **Sequential**: コンポーネントツリー内のリクエストが互いに依存しているパターンです。これにより、読み込み時間が長くなる可能性があります。 -- **Parallel**: ルート内のリクエストが並行して開始され、同時にデータをロードします。これにより、データをロードするのにかかる総時間を短縮できます。 +- **逐次**：コンポーネントツリー内のリクエストが互いに依存している。これにより読み込み時間が長くなることがあります。 +- **並行**：ルート内のリクエストは積極的に開始され、同時にデータをロードします。これによりデータのロードにかかる全体的な時間が短縮されます。 -#### 順次データフェッチ {#sequential-data-fetching} +#### 逐次データフェッチ {#sequential-data-fetching} -ネストされたコンポーネントがあり、それぞれが独自のデータをフェッチする場合、これらのデータリクエストが[メモ化](/docs/app/building-your-application/caching#request-memoization)されていない場合、データフェッチは順次行われます。 +入れ子のコンポーネントがあり、各コンポーネントが独自のデータをフェッチする場合、これらのデータリクエストが[request memoization](/docs/app/building-your-application/caching#request-memoization)されていない場合、データフェッチは逐次的に行われます。 -1つのフェッチが他の結果に依存するため、このパターンを使用したい場合もあります。例えば、`Playlists`コンポーネントは`artistID` propに依存しているため、`Artist`コンポーネントがデータのフェッチを完了するまでデータフェッチを開始しません。 +1つのフェッチが他のフェッチの結果に依存するため、このパターンを望むケースがあるかもしれません。例えば、`Playlists`コンポーネントは`artistID` propに依存しているため、`Artist`コンポーネントがデータのフェッチを終えた後にのみデータのフェッチを開始します： @@ -464,7 +464,7 @@ export default async function Page({ return ( <>

{artist.name}

- {/* Playlistsコンポーネントがロードされる間のフォールバックUIを表示 */} + {/* Playlistsコンポーネントが読み込まれている間、フォールバックUIを表示 */} Loading...}> {/* PlaylistsコンポーネントにアーティストIDを渡す */} @@ -474,7 +474,7 @@ export default async function Page({ } async function Playlists({ artistID }: { artistID: string }) { - // アーティストIDを使用してプレイリストをフェッチ + // アーティストIDを使用してプレイリストを取得 const playlists = await getArtistPlaylists(artistID) return ( @@ -498,7 +498,7 @@ export default async function Page({ params: { username } }) { return ( <>

{artist.name}

- {/* Playlistsコンポーネントがロードされる間のフォールバックUIを表示 */} + {/* Playlistsコンポーネントが読み込まれている間、フォールバックUIを表示 */} Loading...}> {/* PlaylistsコンポーネントにアーティストIDを渡す */} @@ -508,7 +508,7 @@ export default async function Page({ params: { username } }) { } async function Playlists({ artistID }) { - // アーティストIDを使用してプレイリストをフェッチ + // アーティストIDを使用してプレイリストを取得 const playlists = await getArtistPlaylists(artistID) return ( @@ -524,19 +524,19 @@ async function Playlists({ artistID }) { -[`loading.js`](/docs/app/building-your-application/routing/loading-ui-and-streaming)（ルートセグメント用）や[React ``](/docs/app/building-your-application/routing/loading-ui-and-streaming#streaming-with-suspense)（ネストされたコンポーネント用）を使用して即時の読み込み状態を表示し、Reactが結果をストリーミングするまで待つことができます。 +[`loading.js`](/docs/app/building-your-application/routing/loading-ui-and-streaming)（ルートセグメント用）または[React ``](/docs/app/building-your-application/routing/loading-ui-and-streaming#streaming-with-suspense)（ネストされたコンポーネント用）を使用して、即時の読み込み状態を表示し、Reactが結果をストリーミングしている間に表示できるようにします。 -これにより、データリクエストによってルート全体がブロックされるのを防ぎ、ユーザーは準備ができているページの部分と対話できるようになります。 +これにより、データリクエストによって全体のルートがブロックされるのを防ぎ、ユーザーは準備ができたページの一部と対話できます。 -#### 並列データフェッチ {#parallel-data-fetching} +#### 並行データフェッチ {#parallel-data-fetching} -デフォルトでは、レイアウトとページセグメントは並列にレンダリングされます。これはリクエストが並行して開始されることを意味します。 +デフォルトでは、レイアウトとページセグメントは並行してレンダリングされます。これにより、リクエストが並行に開始されます。 -しかし、`async`/`await`の性質上、同じセグメントやコンポーネント内で待機するリクエストは、その下のリクエストをブロックします。 +ただし、 `async`/`await`の性質により、同じセグメントまたはコンポーネント内の待機されたリクエストは、その下のリクエストをブロックします。 -データを並行してフェッチするためには、データを使用するコンポーネントの外でリクエストを事前に開始することができます。これにより、リクエストを並行して開始する時間が節約できますが、両方のPromiseが解決されるまでユーザーはレンダリング結果を見ることができません。 +データを並行してフェッチするには、データを使用するコンポーネントの外側でリクエストを積極的に開始してください。これにより、両方のリクエストが並行して開始されるため時間が節約されますが、両方のプロミスが解決されるまでユーザーはレンダリングされた結果を見られません。 -以下の例では、`getArtist`および`getAlbums`関数が`Page`コンポーネントの外で定義され、`Promise.all`を使用してコンポーネント内で開始されています。 +以下の例では、`getArtist`および`getAlbums`関数は`Page`コンポーネントの外に定義され、`Promise.all`を使用してコンポーネント内部で開始されます： @@ -562,7 +562,7 @@ export default async function Page({ const artistData = getArtist(username) const albumsData = getAlbums(username) - // 両方のリクエストを並列で開始 + // 両方のリクエストを並行して開始 const [artist, albums] = await Promise.all([artistData, albumsData]) return ( @@ -594,7 +594,7 @@ export default async function Page({ params: { username } }) { const artistData = getArtist(username) const albumsData = getAlbums(username) - // 両方のリクエストを並列で開始 + // 両方のリクエストを並行して開始 const [artist, albums] = await Promise.all([artistData, albumsData]) return ( @@ -609,13 +609,13 @@ export default async function Page({ params: { username } }) { -さらに、[Suspense Boundary](/docs/app/building-your-application/routing/loading-ui-and-streaming)を追加してレンダリング作業を分割し、可能な限り早く結果の一部を表示することができます。 +さらに、[Suspense Boundary](/docs/app/building-your-application/routing/loading-ui-and-streaming)を追加して、レンダリング作業を分割し、できるだけ早く結果の一部を表示することができます。 -### データのプリロード {#preloading-data} +### データの事前読み込み {#preloading-data} -ウォーターフォールを防ぐもう1つの方法は、ブロックリクエストの上のユーティリティ関数を作成して事前に呼び出すことによる*プリロード*パターンを使用することです。たとえば、`checkIsAvailable()`が``のレンダリングをブロックするため、`preload()`をその前に呼び出して``のデータ依存関係を事前に開始することができます。 ``がレンダリングされた時点で、そのデータは既にフェッチされています。 +ウォーターフォールを防ぐ別の方法は、ユーティリティ関数を作成し、ブロックするリクエストの上で積極的に呼び出すことで`preload`パターンを使用することです。例えば、`checkIsAvailable()`は``のレンダリングをブロックするため、`preload()`を呼び出して``データ依存関係を積極的に開始できます。 ``がレンダリングされた時点では、データはすでにフェッチされています。 -なお、`preload`関数は`checkIsAvailable()`の実行をブロックしません。 +`preload`関数は`checkIsAvailable()`の実行をブロックしないことに注意してください。 @@ -624,7 +624,7 @@ export default async function Page({ params: { username } }) { import { getItem } from '@/utils/get-item' export const preload = (id: string) => { - // voidは、与えられた式を評価して未定義を返します + // voidは指定した式を評価してundefinedを返します // https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/void void getItem(id) } @@ -641,7 +641,7 @@ export default async function Item({ id }: { id: string }) { import { getItem } from '@/utils/get-item' export const preload = (id) => { - // voidは、与えられた式を評価して未定義を返します + // voidは指定した式を評価してundefinedを返します // https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/void void getItem(id) } @@ -665,9 +665,9 @@ export default async function Page({ }: { params: { id: string } }) { - // アイテムデータのロード開始 + // アイテムデータの読み込みを開始 preload(id) - // 別の非同期タスクの実行 + // 別の非同期タスクを実行 const isAvailable = await checkIsAvailable() return isAvailable ? : null @@ -681,9 +681,9 @@ export default async function Page({ import Item, { preload, checkIsAvailable } from '@/components/Item' export default async function Page({ params: { id } }) { - // アイテムデータのロード開始 + // アイテムデータの読み込みを開始 preload(id) - // 別の非同期タスクの実行 + // 別の非同期タスクを実行 const isAvailable = await checkIsAvailable() return isAvailable ? : null @@ -693,11 +693,11 @@ export default async function Page({ params: { id } }) { -> **Good to know:** 「preload」関数には、それがパターンでありAPIではないため、任意の名前をつけることができます。 +> **Good to know:** "preload"関数はパターンであり、APIではないため、名前には何でも使用できます。 -#### プリロードパターンでのReact `cache`と`server-only`の使用 {#using-react-cache-and-server-only-with-the-preload-pattern} +#### PreloadパターンでReact `cache`と`server-only`を使用する {#using-react-cache-and-server-only-with-the-preload-pattern} -`cache`関数、`preload`パターン、および`server-only`パッケージを組み合わせることで、アプリ全体で使用できるデータフェッチユーティリティを作成することができます。 +`cache`関数、`preload`パターン、`server-only`パッケージを組み合わせて、アプリ全体で使用できるデータフェッチユーティリティを作成できます。 @@ -734,19 +734,19 @@ export const getItem = cache(async (id) => { -このアプローチではデータを事前にフェッチし、レスポンスをキャッシュし、このデータフェッチが[サーバ上のみで行われること](/docs/app/building-your-application/rendering/composition-patterns#keeping-server-only-code-out-of-the-client-environment)を保証します。 +このアプローチを使用すると、データを積極的にフェッチしたり、レスポンスをキャッシュしたり、このデータ取得が[サーバーでのみ行われる保証ができるように](/docs/app/building-your-application/rendering/composition-patterns#keeping-server-only-code-out-of-the-client-environment)します。 -`utils/get-item`のエクスポートは、レイアウト、ページ、または他のコンポーネントによって使用され、データのフェッチ時期を制御できます。 +`utils/get-item`のエクスポートは、Layouts、Pages、その他のコンポーネントによって使用され、アイテムのデータが取得されるタイミングを制御できます。 > **Good to know:** > -> - サーバデータフェッチ関数がクライアント上で使用されないようにするため、[`server-only`パッケージ](/docs/app/building-your-application/rendering/composition-patterns#keeping-server-only-code-out-of-the-client-environment)を使用することをお勧めします。 +> - サーバーデータフェッチ関数がクライアントでは決して使用されないことを確認するために[`server-only`パッケージ](/docs/app/building-your-application/rendering/composition-patterns#keeping-server-only-code-out-of-the-client-environment)の使用をお勧めします。 -### センシティブなデータをクライアントに公開しないようにする {#preventing-sensitive-data-from-being-exposed-to-the-client} +### クライアントに機密データが露出しないようにする {#preventing-sensitive-data-from-being-exposed-to-the-client} -センシティブなデータのクライアントへの公開を防ぐために、ReactのテイントAPI、[`taintObjectReference`](https://react.dev/reference/react/experimental_taintObjectReference)および[`taintUniqueValue`](https://react.dev/reference/react/experimental_taintUniqueValue)を使用することをお勧めします。 +Reactのtaint APIs、[`taintObjectReference`](https://react.dev/reference/react/experimental_taintObjectReference)および[`taintUniqueValue`](https://react.dev/reference/react/experimental_taintUniqueValue)を使用して、オブジェクト全体のインスタンスや機密値がクライアントに渡されることがないようにすることをお勧めします。 -アプリケーションでテイントを有効にするには、Next.jsの設定で`experimental.taint`オプションを`true`に設定します： +アプリケーションでのtaintingを有効にするには、Next.js Configのexperimental.taintオプションをtrueに設定します： ```js title="next.config.js" module.exports = { @@ -756,7 +756,7 @@ module.exports = { } ``` -次に、`experimental_taintObjectReference`または`experimental_taintUniqueValue`関数にテイントしたいオブジェクトまたは値を渡します： +次に、`experimental_taintObjectReference`または`experimental_taintUniqueValue`関数にtaintしたいオブジェクトまたは値を渡します： @@ -771,7 +771,7 @@ import { export async function getUserData() { const data = await queryDataFromDB() experimental_taintObjectReference( - 'ユーザーオブジェクト全体をクライアントに渡さないでください', + 'オブジェクト全体をクライアントに渡さないでください', data ) experimental_taintUniqueValue( @@ -796,7 +796,7 @@ import { export async function getUserData() { const data = await queryDataFromDB() experimental_taintObjectReference( - 'ユーザーオブジェクト全体をクライアントに渡さないでください', + 'オブジェクト全体をクライアントに渡さないでください', data ) experimental_taintUniqueValue( @@ -821,8 +821,8 @@ export async function Page() { const userData = getUserData() return ( ) } @@ -838,8 +838,8 @@ export async function Page() { const userData = await getUserData() return ( ) } diff --git a/docs/02-app/01-building-your-application/03-rendering/01-server-components.mdx b/docs/02-app/01-building-your-application/03-rendering/01-server-components.mdx index 9fe6ffaf..bc183e8f 100644 --- a/docs/02-app/01-building-your-application/03-rendering/01-server-components.mdx +++ b/docs/02-app/01-building-your-application/03-rendering/01-server-components.mdx @@ -1,132 +1,132 @@ --- title: 'Server Components' -description: 'React Server Componentsを使用して、アプリケーションの一部をサーバーでレンダリングする方法を学びます。' +description: 'React Server Componentsを使用して、アプリケーションの一部をサーバーでレンダリングする方法を学びましょう。' related: - description: 'Next.jsがデータおよび静的レンダリングの結果をどのようにキャッシュするかを学びます。' + description: 'Next.jsがデータや静的レンダリングの結果をどのようにキャッシュするかを学びましょう。' links: - app/building-your-application/caching --- -React Server Componentsを使用すると、UIをサーバー上でレンダリングし、必要に応じてキャッシュできます。Next.jsでは、ルートセグメントごとにレンダリング作業がさらに分割され、ストリーミングや部分レンダリングが可能になります。以下の3つの異なるサーバーレンダリング戦略があります： +React Server Componentsを使用すると、UIをサーバーでレンダリングし、オプションでキャッシュすることができます。Next.jsでは、レンダリング作業がさらにルートセグメントごとに分割され、ストリーミングや部分的なレンダリングを可能にし、3つの異なるサーバーレンダリング戦略があります： - [静的レンダリング](#static-rendering-default) - [動的レンダリング](#dynamic-rendering) - [ストリーミング](#streaming) -このページでは、Server Componentsがどのように機能するか、いつそれらを使用すべきか、および異なるサーバーレンダリング戦略について説明します。 +このページでは、Server Componentsがどのように動作するのか、いつ使用するのか、そして異なるサーバーレンダリング戦略について説明します。 ## サーバーレンダリングの利点 {#benefits-of-server-rendering} -サーバーでレンダリング作業を行うことには、いくつかの利点があります： +サーバーでレンダリング作業を行うことにはいくつかの利点があります。 -- **データフェッチ**：Server Componentsを使用すると、データフェッチをサーバーに移動でき、データソースに近づけることができます。これにより、レンダリングに必要なデータを取得する時間と、クライアントがリクエストする数を減らすことができ、パフォーマンスが向上します。 -- **セキュリティ**：Server Componentsは、トークンやAPIキーなどの機密情報やロジックをクライアントに公開せずにサーバー上に保つことができます。 -- **キャッシング**：サーバー上でレンダリングを行うことで、その結果をキャッシュし、後続のリクエストやユーザー間で再利用できます。これにより、各リクエストごとに行われるレンダリングおよびデータフェッチの量を減らし、パフォーマンスを向上させ、コストを削減できます。 -- **パフォーマンス**：Server Componentsは、基本的なパフォーマンスを最適化するための追加ツールを提供します。例えば、すべてのUIコンポーネントがClient Componentsで構成されたアプリから始めた場合、インタラクティブでないUIの部分をServer Componentsに移すことで、必要なクライアントサイドJavaScriptの量を削減できます。これにより、遅いインターネットや性能の低いデバイスを使用しているユーザーにとって有益です。ブラウザはダウンロード、解析、実行するクライアントサイドのJavaScriptが少なくて済みます。 -- **初期ページ読み込みと[First Contentful Paint (FCP)](https://web.dev/fcp/)**：サーバーでは、ユーザーがページを即座に見ることができるようにHTMLを生成できます。これは、クライアントがページのレンダリングに必要なJavaScriptをダウンロード、解析、実行するのを待たずに済むことを意味します。 -- **検索エンジン最適化とソーシャルネットワークの共有性**：レンダリングされたHTMLは、検索エンジンボットにページをインデックスさせたり、ソーシャルネットワークボットがページのソーシャルカードプレビューを生成するために使用できます。 -- **ストリーミング**：Server Componentsは、レンダリング作業をチャンクに分割し、準備ができたらクライアントにストリーミングすることができます。これにより、ユーザーはページ全体がサーバーでレンダリングされるのを待たずに、ページの一部を早く見ることができます。 +- **データ取得**：Server Componentsを使用すると、データ取得をサーバー側に移行させ、データソースに近づけることができます。これにより、レンダリングに必要なデータを取得する時間を短縮し、クライアントが行うリクエストの数を減らしてパフォーマンスが向上します。 +- **セキュリティ**：サーバー上でトークンやAPIキーなどの機密データやロジックを保持し、クライアントに露出させるリスクを回避できます。 +- **キャッシング**：サーバーでレンダリングすることで、結果をキャッシュし、後のリクエストやユーザー間で再利用できます。これにより、各リクエストで行うレンダリングとデータ取得の量を減らし、パフォーマンス向上とコスト削減を実現できます。 +- **パフォーマンス**：Server Componentsを使用すると、基本からパフォーマンスを最適化するための追加ツールを使用できます。たとえば、完全にClient Componentsで構成されたアプリをベースにした場合、UIの非対話型部分をServer Componentsに移行すると、必要なクライアントサイドJavaScriptを減らすことができます。これは、インターネットが遅いユーザーや性能の低いデバイスを使用しているユーザーにとって有益です。ブラウザがダウンロード、解析、実行するクライアントサイドJavaScriptが少なくなります。 +- **初回ページロードと[First Contentful Paint (FCP)](https://web.dev/fcp/)**：サーバーでHTMLを生成し、ユーザーがページを即座に確認できるようにします。クライアントがページレンダリングに必要なJavaScriptをダウンロード、解析、実行するのを待つ必要はありません。 +- **検索エンジン最適化（SEO）とソーシャルネットワークでの共有性**：レンダリングされたHTMLを使用して、検索エンジンのボットがページをインデックス化したり、ソーシャルネットワークのボットがページのソーシャルカードプレビューを生成したりできます。 +- **ストリーミング**：Server Componentsを使用することで、レンダリング作業をチャンクに分割し、それが準備でき次第クライアントにストリーミングできます。この方法を用いると、ページ全体がサーバーでレンダリングされるのを待たずに、ページの一部をユーザーが早く確認できるようになります。 -## Next.jsでのServer Componentsの使用 {#using-server-components-in-next-js} +## Next.jsでServer Componentsを使用する {#using-server-components-in-next-js} -デフォルトで、Next.jsはServer Componentsを使用します。これにより、追加の設定なしで自動的にサーバーレンダリングを実装でき、必要に応じてClient Componentsを使用するオプトインが可能です。[Client Components](/docs/app/building-your-application/rendering/client-components)を参照してください。 +デフォルトでは、Next.jsはServer Componentsを使用します。これにより、追加の設定なしでサーバーレンダリングを自動的に実装することができ、必要に応じてClient Componentsを使用するオプションがあります。詳細は[Client Components](/docs/app/building-your-application/rendering/client-components)を参照してください。 -## Server Componentsはどのようにレンダリングされるか？ {#how-are-server-components-rendered} +## Server Componentsはどのようにレンダリングされるのか？{#how-are-server-components-rendered} -サーバーで、Next.jsはReactのAPIを使用してレンダリングを調整します。レンダリング作業は、個々のルートセグメントや[スプレンス境界](https://react.dev/reference/react/Suspense)ごとにチャンクに分割されます。 +サーバー側では、Next.jsはReactのAPIを使用してレンダリングをオーケストレーションします。レンダリング作業は、個別のルートセグメントや[サスペンス境界](https://react.dev/reference/react/Suspense)に分割されます。 各チャンクは次の2段階でレンダリングされます： -1. ReactはServer Componentsを特別なデータフォーマットである**React Server Component Payload (RSC Payload)**にレンダリングします。 -2. Next.jsはRSC PayloadとClient ComponentのJavaScript命令を使用してサーバー上で**HTML**をレンダリングします。 +1. ReactがServer Componentsを**React Server Component Payload (RSC Payload)**という特別なデータ形式にレンダリングします。 +2. Next.jsがRSC PayloadとClient ComponentのJavaScript命令を使用して、サーバー上で**HTML**をレンダリングします。 {/* レンダリング図 */} -その後、クライアントでは： +その後、クライアント側では以下の処理が行われます： -1. HTMLが即座にルートの迅速な非インタラクティブプレビューを表示するために使用されます。これは初期ページ読み込み時のみです。 -2. React Server Componentのペイロードがクライアントとサーバーのコンポーネントツリーを調整し、DOMを更新します。 -3. JavaScript命令がクライアントコンポーネントを[ハイドレート](https://react.dev/reference/react-dom/client/hydrateRoot)してアプリケーションをインタラクティブにします。 +1. HTMLを使用して、ルートの速い非対話型プレビューを即座に表示します。これは初回ページロード時のみです。 +2. React Server Components Payloadを使用して、Client ComponentとServer Componentの木を調整し、DOMを更新します。 +3. JavaScript命令を使用して、クライアントコンポーネントを[ハイドレート](https://react.dev/reference/react-dom/client/hydrateRoot)し、アプリケーションを対話型にします。 -> #### React Server Component Payload (RSC)とは何か？ +> #### React Server Component Payload (RSC)とは？ > -> RSC Payloadは、レンダリングされたReact Server Componentsツリーのコンパクトなバイナリ表現です。このペイロードは、クライアントのReactがブラウザのDOMを更新するために使用されます。RSC Payloadには以下が含まれます： +> RSC Payloadは、レンダリングされたReact Server Componentsツリーのコンパクトなバイナリ表現です。クライアント上のReactによりブラウザのDOMを更新するために使用されます。RSC Payloadには次の内容が含まれています： > > - Server Componentsのレンダリング結果 -> - Client Componentsがレンダリングされるべき位置と、そのJavaScriptファイルへの参照 -> - Server ComponentからClient Componentに渡されるプロップ +> - Client Componentsがレンダリングされるべき場所のプレースホルダーとそのJavaScriptファイルへの参照 +> - Server ComponentからClient Componentに渡されるprop ## サーバーレンダリング戦略 {#server-rendering-strategies} -サーバーレンダリングには、静的、動的、およびストリーミングという3つのサブセットがあります。 +サーバーレンダリングには、静的、動的、ストリーミングの3つのサブセットがあります。 -### 静的レンダリング（デフォルト） {#static-rendering-default} +### 静的レンダリング (デフォルト) {#static-rendering-default} -静的レンダリングでは、ルートは**ビルド時**または[データ再検証](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)後にバックグラウンドでレンダリングされます。その結果はキャッシュされ、[コンテンツ配信ネットワーク (CDN)](https://developer.mozilla.org/docs/Glossary/CDN)にプッシュできます。この最適化により、レンダリング作業の結果をユーザーやサーバーリクエスト間で共有できるようになります。 +静的レンダリングでは、ルートが**ビルド時**または[データの再検証](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)後にバックグラウンドでレンダリングされます。その結果はキャッシュされ、[コンテンツ配信ネットワーク (CDN)](https://developer.mozilla.org/docs/Glossary/CDN)にプッシュすることができます。この最適化により、レンダリング作業の結果をユーザーやサーバーリクエスト間で共有できます。 -静的レンダリングは、ユーザーに対してパーソナライズされていないデータを持ち、ビルド時に分かる、静的なブログ投稿や製品ページなどのルートに適しています。 +静的レンダリングは、ルートにユーザーごとにパーソナライズされていないデータがあり、ビルド時に判明している場合に役立ちます。たとえば、静的なブログ記事や商品ページです。 ### 動的レンダリング {#dynamic-rendering} -動的レンダリングでは、ルートは**リクエスト時**に各ユーザーごとにレンダリングされます。 +動的レンダリングでは、ルートが各ユーザーに対して**リクエスト時**にレンダリングされます。 -動的レンダリングは、ユーザーにパーソナライズされたデータや、リクエスト時にしか分からないクッキーやURLの検索パラメータの情報を持つルートに適しています。 +動的レンダリングは、ルートにユーザーごとにパーソナライズされたデータや、cookieまたはURLの検索パラメータなど、リクエスト時にしかわからない情報がある場合に役立ちます。 -> **キャッシュされたデータを持つ動的ルート** +> **キャッシュされたデータを伴う動的ルート** > -> ほとんどのWebサイトでは、ルートは完全に静的でも動的でもありません。例えば、キャッシュされた商品データを一定の間隔で再検証し、パーソナライズされた顧客データは未キャッシュのものにすることがあります。 +> ほとんどのウェブサイトでは、ルートは完全に静的でも完全に動的でもなく、スペクトラム上にあります。たとえば、定期的に再検証されるキャッシュされた製品データを使用するeコマースページがありながら、キャッシュされていないパーソナライズされた顧客データがあります。 > -> Next.jsでは、キャッシュされたデータと未キャッシュのデータの両方を持つ動的にレンダリングされたルートを持つことができます。これは、RSCペイロードとデータが別々にキャッシュされるためです。これにより、すべてのデータをリクエスト時に取得するパフォーマンスへの影響を気にすることなく、動的レンダリングを選択することができます。 +> Next.jsでは、キャッシュされたデータとキャッシュされていないデータの両方を持つ動的にレンダリングされたルートを持つことができます。これは、RSC Payloadとデータが別々にキャッシュされるためです。これにより、全てのデータをリクエスト時に取得する際のパフォーマンスへの影響を心配せずに、動的レンダリングのオプションを選ぶことができます。 > -> [full-route cache](/docs/app/building-your-application/caching#full-route-cache)と[データキャッシュ](/docs/app/building-your-application/caching#data-cache)についての詳細を学びましょう。 +> [フルルートキャッシュ](/docs/app/building-your-application/caching#full-route-cache)や[データキャッシュ](/docs/app/building-your-application/caching#data-cache)について詳しく学んでください。 #### 動的レンダリングへの切り替え {#switching-to-dynamic-rendering} -レンダリング中に、[Dynamic API](#dynamic-apis)または未キャッシュのデータリクエストが発見された場合、Next.jsはルート全体を動的にレンダリングするように切り替えます。以下の表は、Dynamic APIとデータキャッシングがルートが静的または動的にレンダリングされるかにどのように影響するかをまとめたものです： +レンダリング中に[動的API](#dynamic-apis)またはキャッシュされていないデータ要求が発見された場合、Next.jsはルート全体を動的にレンダリングするように切り替えます。この表は、動的APIとデータキャッシングがルートが静的にあるいは動的にレンダリングされるかを示しています： -| Dynamic APIs | Data | Route | -| ------------ | ---------- | ------------------------ | -| No | Cached | スタティックレンダリング | -| Yes | Cached | ダイナミックレンダリング | -| No | Not Cached | ダイナミックレンダリング | -| Yes | Not Cached | ダイナミックレンダリング | +| 動的API | データ | ルート | +| ------- | ------------ | ------------------ | +| いいえ | キャッシュ | 静的にレンダリング | +| はい | キャッシュ | 動的にレンダリング | +| いいえ | 非キャッシュ | 動的にレンダリング | +| はい | 非キャッシュ | 動的にレンダリング | -上記の表では、ルートが完全に静的であるためには、すべてのデータがキャッシュされている必要があります。ただし、キャッシュされたデータフェッチと非キャッシュされたデータフェッチの両方を使用する動的にレンダリングされたルートを持つことも可能です。 +上記の表では、ルートが完全に静的であるためには、すべてのデータがキャッシュされている必要があります。ただし、キャッシュされたデータ取得とキャッシュされていないデータ取得を利用する動的にレンダリングされたルートを持つことができます。 -開発者としては、Next.jsが使用される機能とAPIを基に各ルートに最適なレンダリング戦略を自動的に選択するので、静的レンダリングと動的レンダリングのどちらかを選ぶ必要はありません。かわりに、[データをキャッシュ](/docs/app/building-your-application/data-fetching/fetching)または[特定のデータを再検証する](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)時期を選択し、UIの一部を[ストリーム](#streaming)することができます。 +開発者として、Next.jsは使用されるフィーチャーとAPIに基づいて各ルートに最適なレンダリング戦略を自動的に選択するため、静的と動的レンダリングの選択を行う必要はありません。その代わりに、いつ[キャッシュする](/docs/app/building-your-application/data-fetching/fetching)か、または特定のデータを[再検証する](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)かを選択し、UIの一部を[ストリーミングする](#streaming)ことを選択できます。 -### ダイナミックAPIs {#dynamic-apis} +### 動的API {#dynamic-apis} -Dynamic APIsは、リクエスト時にのみ分かる情報（そしてそれ以外の事前レンダリング時には分からない）に依存します。これらのAPIを使用することにより、開発者はリクエスト時に動的レンダリングを選択する意図を示します。これらのAPIには次が含まれます： +動的APIは、プリレンダリング中には事前に把握できず、リクエスト時にのみわかる情報に依存しています。これらのAPIのいずれかを使用すると、開発者の意図を示し、リクエスト時にルート全体を動的レンダリングに適応させます。これらのAPIには次のものが含まれます： - [`cookies`](/docs/app/api-reference/functions/cookies) - [`headers`](/docs/app/api-reference/functions/headers) - [`connection`](/docs/app/api-reference/functions/connection) - [`draftMode`](/docs/app/api-reference/functions/draft-mode) - [`searchParams` prop](/docs/app/api-reference/file-conventions/page#searchparams-optional) -- [`unstable_noStore`](/docs/app/api-reference/functions/unstable_noStore) +- [`unstable_noStore`](/docs/app/api-reference/legacy-apis/unstable_noStore) - [`unstable_after`](/docs/app/api-reference/functions/unstable_after) ### ストリーミング {#streaming} ストリーミング中にルートセグメントの並列化を示す図で、個々のチャンクのデータフェッチ、レンダリング、ハイドレーションを示しています。 -ストリーミングを利用すると、サーバーからUIを段階的にレンダリングすることができます。作業はチャンクに分割され、準備ができたらクライアントにストリーミングされます。これにより、ユーザーはコンテンツ全体がレンダリングされる前にページの一部を見ることができます。 +ストリーミングにより、サーバーからUIを段階的にレンダリングできます。作業はチャンクに分割され、それが準備でき次第クライアントにストリーミングされます。これにより、ユーザーはコンテンツ全体がレンダリングされる前にページの一部をすぐに見ることができます。 クライアントで部分的にレンダリングされたページの図で、ストリーミングされているチャンクの読み込みUIを示しています。 -ストリーミングはデフォルトでNext.js App Routerに組み込まれています。これにより、初期ページの読み込みパフォーマンスの向上が図れるだけでなく、レンダリング全体をブロックする遅いデータフェッチに依存するUIが改善されます。例として、製品ページのレビューがあります。 +ストリーミングはデフォルトでNext.js App Routerに組み込まれており、初期ページの読み込みパフォーマンスおよび、レンダリング全体を妨げるような遅いデータ取得に依存するUIの改善に役立ちます。たとえば、商品ページのレビューが該当します。 -`loading.js`とUIコンポーネントを使ってルートセグメントをストリームし始めることができます。詳細については、[Loading UI and Streaming](/docs/app/building-your-application/routing/loading-ui-and-streaming)セクションをご覧ください。 +`loading.js`を使用してルートセグメントをストリーミングすることや、[React Suspense](/docs/app/building-your-application/routing/loading-ui-and-streaming)を使用してUIコンポーネントと共にストリーミングを開始できます。詳しくは[Loading UI and Streaming](/docs/app/building-your-application/routing/loading-ui-and-streaming)セクションを参照してください。 diff --git a/docs/02-app/01-building-your-application/04-caching/index.mdx b/docs/02-app/01-building-your-application/04-caching/index.mdx index 2656382c..4a202f05 100644 --- a/docs/02-app/01-building-your-application/04-caching/index.mdx +++ b/docs/02-app/01-building-your-application/04-caching/index.mdx @@ -1,66 +1,66 @@ --- -title: 'Next.jsにおけるキャッシュ' +title: 'Next.jsのキャッシュ' nav_title: 'キャッシュ' -description: 'Next.jsのキャッシュメカニズムの概要。' +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)。 +> **知っておくとよいこと**: このページは、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における4つのメカニズムのデフォルトのキャッシュ動作を示している、HIT、MISS、SETがビルド時とルートが最初に訪問されたときにどのように発生するかを示した図 -キャッシュの動作は、ルートが静的または動的にレンダリングされるか、データがキャッシュされるかされないか、またはリクエストが初回訪問かそれ以降のナビゲーションかによって変化します。ユースケースに応じて、個別のルートとデータリクエストのキャッシュ動作を設定できます。 +キャッシュ動作は、ルートが静的または動的にレンダリングされるか、データがキャッシュされるかされないか、リクエストが初回訪問またはその後のナビゲーションの一部であるかによって変わります。利用ケースに応じて個々のルートとデータリクエストのキャッシュ動作を設定できます。 ## Request Memoization {#request-memoization} -Reactは同じURLとオプションを持つリクエストを自動的に**メモ化**するために[`fetch` API](#fetch)を拡張しています。これは、React Component treeの複数の箇所で同じデータを取得するためのfetch関数を呼び出しても、それが1回だけ実行されることを意味します。 +Reactは[`fetch` API](#fetch)を拡張して、同じURLとオプションを持つリクエストを自動的に**メモ化**します。これにより、React component tree内の複数の場所で同じデータのfetch関数を呼び出しても、一度だけ実行されます。 デデュプリケートされたFetchリクエスト -たとえば、ルート全体で同じデータを使用する必要がある場合（例：Layout、Page、および複数のコンポーネントで）、ツリーの上部でデータを取得し、コンポーネント間でpropsを転送する必要はありません。その代わりに、必要なデータをコンポーネント内でフェッチし、ネットワーク上で同じデータを複数回リクエストすることによるパフォーマンスへの影響を心配することなく使用できます。 +たとえば、あるルート全体で同じデータを使用する必要がある場合（例：Layout、Page、および複数のコンポーネント）、データをtreeの最上部でfetchしてコンポーネント間でpropsを転送する必要はありません。代わりに、データを必要とするコンポーネントでfetchし、ネットワークを介して同じデータの複数のリクエストを行うパフォーマンスの影響を心配することなくデータを取得できます。 ```tsx title="app/example.tsx" switcher async function getItem() { - // The `fetch` function is automatically memoized and the result - // is cached + // `fetch` 関数は自動的にメモ化され、その結果が + // キャッシュされます const res = await fetch('https://.../item/1') return res.json() } -// This function is called twice, but only executed the first time -const item = await getItem() // cache MISS +// この関数は2回呼ばれますが、最初の1回のみ実行されます +const item = await getItem() // キャッシュ MISS -// The second call could be anywhere in your route -const item = await getItem() // cache HIT +// 2回目の呼び出しはルートのどこでも行われる可能性があります +const item = await getItem() // キャッシュ HIT ``` @@ -68,17 +68,17 @@ const item = await getItem() // cache HIT ```jsx title="app/example.js" switcher async function getItem() { - // The `fetch` function is automatically memoized and the result - // is cached + // `fetch` 関数は自動的にメモ化され、その結果が + // キャッシュされます const res = await fetch('https://.../item/1') return res.json() } -// This function is called twice, but only executed the first time -const item = await getItem() // cache MISS +// この関数は2回呼ばれますが、最初の1回のみ実行されます +const item = await getItem() // キャッシュ MISS -// The second call could be anywhere in your route -const item = await getItem() // cache HIT +// 2回目の呼び出しはルートのどこでも行われる可能性があります +const item = await getItem() // キャッシュ HIT ``` @@ -87,40 +87,40 @@ const item = await getItem() // cache HIT **Request Memoizationの仕組み** Reactレンダリング中にfetchのメモ化がどのように機能するか -- ルートをレンダリング中に特定のリクエストが最初に呼び出された場合、その結果はメモリに存在せず、キャッシュ`MISS`になります -- したがって、関数が実行され、データが外部ソースからフェッチされ、その結果がメモリに保存されます -- 同じレンダリングパス内でのリクエストの後続の関数呼び出しはキャッシュ`HIT`になり、メモリからデータが返され、関数は実行されません -- ルートがレンダリングされレンダリングパスが完了すると、メモリは「リセット」され、すべてのリクエストメモ化エントリがクリアされます +- ルートをレンダリング中、特定のリクエストが初めて呼び出されると、その結果はメモリ内に存在しないのでキャッシュ`MISS`となります； +- したがって、関数は実行され、データは外部ソースから取得され、その結果はメモリに保存されます； +- 同じレンダリングパスでリクエストが再度呼び出された場合、キャッシュ`HIT`となり、データは関数を実行せずにメモリから返されます； +- ルートのレンダリングが完了し、レンダリングパスが完了すると、メモリは「リセット」され、すべてのrequest memoizationエントリがクリアされます； -> **Good to know**: - -- Request Memoizationは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)を使用して関数をメモ化することができます。 +> **知っておくとよいこと**： +> +> - Request memoizationは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)を使用して関数をメモ化できます； ### 期間 {#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() @@ -129,95 +129,95 @@ fetch(url, { signal }) ## Data Cache {#data-cache} -Next.jsには、着信**サーバリクエスト**と**デプロイ**間でデータフェッチの結果を**永続化**するビルトインのData Cacheがあります。これは、Next.jsがネイティブの`fetch` APIを拡張して、サーバ内での各リクエストが自分自身の永続的なキャッシュセマンティクスを設定できるようにするため可能です。 +Next.jsには組み込みのData Cacheがあり、データフェッチの結果を**サーバーリクエスト**間や**デプロイ**間で**永続**します。これは、Next.jsがネイティブの`fetch` APIを拡張して、サーバー上の各リクエストが独自の永続的なキャッシュセマンティクスを設定できるようにしているためです。 -> **Good to know**: ブラウザ内では、`fetch`の`cache`オプションは、リクエストがブラウザのHTTPキャッシュとどのように相互作用するかを示しますが、Next.jsでは、`cache`オプションはサーバサイドリクエストがサーバのData Cacheとどのように相互作用するかを示します。 +> **知っておくとよいこと**: ブラウザーでは、`fetch`の`cache`オプションはリクエストがブラウザーのHTTPキャッシュとどのように対話するかを示しますが、Next.jsでは、`cache`オプションはサーバー側リクエストがサーバーのData Cacheとどのように対話するかを示します； -`fetch`のキャッシュ動作を設定するには、[`cache`](#fetch-optionscache)と[`next.revalidate`](#fetch-optionsnextrevalidate)オプションを使用できます。 +`fetch`の`cache`および`next.revalidate`オプションを使用して、キャッシュ動作を構成できます。 **Data Cacheの仕組み** キャッシュされたfetchリクエストとキャッシュされていないfetchリクエストがData Cacheとどのように相互作用するかを示した図。キャッシュされたリクエストはData Cacheに保存され、メモ化され、キャッシュされていないリクエストはデータソースからフェッチされ、Data Cacheには保存されず、メモ化される。 -- `fetch`リクエストがレンダリング中に`'force-cache'`オプションで初めて呼び出されると、Next.jsはData Cacheにキャッシュされたレスポンスがあるかどうかを確認します -- キャッシュされたレスポンスが見つかった場合、それが直ちに返され、[メモ化](#request-memoization)されます -- キャッシュされたレスポンスが見つからなかった場合、リクエストはデータソースに行われ、その結果はData Cacheに保存され、メモ化されます -- キャッシュされていないデータ（例：`cache`オプションが定義されていない、または`{ cache: 'no-store' }`が使用されている）の場合、結果は常にデータソースからフェッチされ、メモ化されます -- データがキャッシュされているかキャッシュされていないかに関係なく、リクエストは常にメモ化されて、Reactのレンダリングパス中に同じデータに対する重複したリクエストが行われるのを避けます +- レンダリング中に`'force-cache'`オプション付きの`fetch`リクエストが初めて呼び出されると、Next.jsはData Cacheでキャッシュされたレスポンスを確認します； +- キャッシュされたレスポンスが見つかった場合、それを即座に返し、[メモ化](#request-memoization)します； +- キャッシュされたレスポンスが見つからない場合、リクエストはデータソースに送られ、結果はData Cacheに保存され、メモ化されます； +- キャッシュされていないデータの場合（例：`cache`オプションが定義されていないか、`{ cache: 'no-store' }`を使用している場合）、結果は常にデータソースから取得され、メモ化されます； +- データがキャッシュされているかキャッシュされていないかに関係なく、リクエストは常にメモ化され、Reactのレンダリングパス中に同じデータの重複リクエストを行うのを避けることができます； > **Data CacheとRequest Memoizationの違い** > -> 両方のキャッシュメカニズムはキャッシュされたデータを再利用してパフォーマンスを向上させるのに役立ちますが、Data Cacheは着信リクエストとデプロイ間で永続的であるのに対し、メモ化はリクエストのライフタイムのみ継続します。 +> 両方のキャッシュメカニズムはキャッシュされたデータを再利用することでパフォーマンスの向上に役立ちますが、Data Cacheはリクエストやデプロイを越えて永続的であり、メモ化はリクエストのライフタイムにしか続きません； ### 期間 {#duration} -デフォルトでは、Data Cacheは着信リクエストとデプロイ間で永続的です。再検証するかオプトアウトするまで続きます。 +特にオプトアウトせずに再検証しない限り、Data Cacheはリクエストやデプロイをまたいで永続します。 ### 再検証 {#revalidating} -キャッシュされたデータは、以下の2つの方法で再検証できます： +キャッシュされたデータは2つの方法で再検証できます： -- **時間ベースの再検証**：新しいリクエストが行われた後、一定時間が経過するとデータを再検証します。これは、データがいくつかの間隔でのみ変更され、新しさがそれほど重要でない場合に役立ちます。 -- **オンデマンドの再検証**：イベントに基づいてデータを再検証します（例：フォーム送信）。オンデマンドの再検証は、タグベースまたはパスベースのアプローチを使用して、データのグループを一度に再検証できます。これは、ヘッドレスCMSからのコンテンツが更新されたとき、できるだけ早く最新のデータを確実に表示したい場合に役立ちます。 +- **時間ベースの再検証**: ある時間が経過した後に新しいリクエストが行われた際にデータを再検証します。データがあまり頻繁に変わらず、新鮮さがそれほど重要でない場合に便利です； +- **オンデマンドの再検証:** イベント（例：フォーム送信）に基づいてデータを再検証します。オンデマンドの再検証は、タグベースまたはパスベースのアプローチを使用してデータのグループを一度に再検証することができます。これは、ヘッドレスCMSのコンテンツが更新されたときなど、できるだけ早く最新のデータを表示することを確実にしたい場合に便利です； #### 時間ベースの再検証 {#time-based-revalidation} -タイムイントターバルでデータを再検証するには、`fetch`の`next.revalidate`オプションを使用して、リソースのキャッシュライフタイム（秒単位）を設定できます。 +時間間隔でデータを再検証するには、`fetch`の`next.revalidate`オプションを使用してリソースのキャッシュ期間（秒単位）を設定できます。 ```js -// 最大1時間ごとに再検証 +// 最高で毎時再検証 fetch('https://...', { next: { revalidate: 3600 } }) ``` -または、[Route Segment Config options](#segment-config-options)を使用して、セグメント内のすべての`fetch`リクエストを設定するか、`fetch`を使用できない場合に設定できます。 +あるいは、[Route Segment Config options](#segment-config-options)を使用して、セグメント内のすべての`fetch`リクエストを構成するか、`fetch`を使用できない場合の設定を変更できます。 -**時間ベースの再検証の動作** +**時間ベースの再検証がどのように機能するか** 時間ベースの再検証の動作を示した図。再検証期間後、最初のリクエストに対して古いデータが返され、その後データが再検証される。 -- `revalidate`付きのfetchリクエストが初めて呼び出されたとき、データは外部データソースからフェッチされ、Data Cacheに保存されます -- 指定された時間枠内に呼び出されたリクエストはキャッシュされたデータを返します -- 時間枠が過ぎた後、次のリクエストはキャッシュされた（今は古くなった）データを返します - - Next.jsは背景でデータの再検証をトリガーします - - データが正常にフェッチされると、Next.jsはData Cacheを新鮮なデータで更新します - - 背景での再検証が失敗した場合、以前のデータがそのまま保持されます +- `revalidate`付きのfetchリクエストが初めて呼び出されるとき、データは外部データソースからフェッチされ、Data Cacheに保存されます； +- 指定された期間内（例：60秒）に呼び出されるリクエストは、キャッシュされたデータを返します； +- 期間が過ぎると、次のリクエストは古い（すでに使用されなくなった）データを返します； + - 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)）オンデマンドで再検証できます。 -**オンデマンドの再検証の動作** +**オンデマンドの再検証がどのように機能するか** オンデマンドの再検証の動作を示した図。再検証リクエストの後にData Cacheが新鮮なデータで更新される。 -- `fetch`リクエストが初めて呼び出されたとき、データは外部データソースからフェッチされ、Data Cacheに保存されます -- オンデマンドの再検証がトリガーされた場合、キャッシュの適切なエントリがキャッシュからパージされます - - これは、古いデータをキャッシュに保持する時間ベースの再検証とは異なります -- 次回リクエストが行われる時、それは再びキャッシュ`MISS`になり、データは外部データソースからフェッチされ、Data Cacheに保存されます +- `fetch`リクエストが初めて呼び出されたとき、データは外部データソースから取得され、Data Cacheに保存されます； +- オンデマンドの再検証がトリガーされると、該当するキャッシュエントリがキャッシュから削除されます； + - これは時間ベースの再検証とは異なり、新鮮なデータが取得されるまで古いデータがキャッシュ内に保持されます； +- リクエストが次に行われると、再度キャッシュMISSとなり、データは外部データソースからフェッチされ、Data Cacheに保存されます； ### オプトアウト {#opting-out} -`fetch`のレスポンスをキャッシュしたくない場合、以下のことを行うことができます： +`fetch`からのレスポンスをキャッシュしたくない場合、以下を行うことができます： ```js let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' }) @@ -225,243 +225,243 @@ let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' }) ## Full Route Cache {#full-route-cache} -> **関連用語**： +> **関連用語**: > -> 指定された用語は、アプリケーションのルートをビルド時にレンダリングしてキャッシュするプロセスを指すために、**Automatic Static Optimization**、**Static Site Generation**、または**Static Rendering**と交換して使用されることがあります。 +> **Automatic Static Optimization**、**Static Site Generation**、または**Static Rendering**という用語が、このプロセスと同様に、あなたのアプリケーションのルートをビルド時にレンダリングしてキャッシュすることを指して使用されることがあります； -Next.jsはビルド時にルートを自動的にレンダリングしてキャッシュします。これは、ルートをサーバ上で毎回リクエストごとにレンダリングする代わりに、キャッシュされたルートを提供することができる最適化であり、ページロードを高速化します。 +Next.jsは、ビルド時にルートを自動的にレンダリングしてキャッシュします。これは最適化であり、すべてのリクエストに対してサーバー上でレンダリングするのではなく、キャッシュされたルートを提供することで、ページの読み込みがより速くなることがあります。 -Full Route Cacheがどのように機能するかを理解するためには、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 boundaryによってチャンクに分割されます。 +サーバー上でNext.jsはReactのAPIを使用してレンダリングを調整します。レンダリング作業はチャンク（個別のルートセグメントとSuspense境界）に分割されます。 -各チャンクは2段階でレンダリングされます： +各チャンクは次の2ステップでレンダリングされます： -1. ReactはServer Componentsをストリーミング用に最適化された特別なデータフォーマットである**React Server Component Payload**としてレンダーします -2. Next.jsは、React Server Component PayloadとClient Componentの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のレンダリング結果 -> - Client Componentsがレンダリングされるべき場所とそのJavaScriptファイルへの参照のプレースホルダー -> - Server ComponentからClient Componentへ渡されるprops +> - Server Componentsのレンダリング結果； +> - Client ComponentsのJavaScriptファイルへの参照とそれがレンダリングされるべきプレースホルダー； +> - Server ComponentからClient Componentに渡されたすべてのprops； > -> 詳しくは、[Server Components](/docs/app/building-your-application/rendering/server-components)のドキュメントを参照してください。 +> 詳細については、[Server Components](/docs/app/building-your-application/rendering/server-components)のドキュメントを参照してください； -### 2. サーバ上でのNext.jsキャッシュ (Full Route Cache) {#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のFull Route Cacheのデフォルトの動作、静的にレンダリングされたルートに対してサーバ上でReact Server Component PayloadとHTMLがキャッシュされる様子 -Next.jsのデフォルトの動作は、静的にレンダリングされたルートのレンダリング結果（React Server Component PayloadおよびHTML）をサーバ上でキャッシュすることです。これはビルド時または再検証中に適用されます。 +Next.jsのデフォルトの動作は、ルートのレンダリング結果（React Server Component PayloadとHTML）をサーバーでキャッシュすることです。これはビルド時、または再検証中の静的にレンダリングされたルートに適用されます。 -### 3. クライアントでのReact HydrationとReconciliation {#3-react-hydration-and-reconciliation-on-the-client} +### 3. クライアントでのReactのハイドレーションと調停 {#3-react-hydration-and-reconciliation-on-the-client} リクエスト時、クライアント上で： -1. HTMLは、Client and Server Componentsのインタラクティブではない初期プレビューを即座に表示するために使用されます -2. React Server Components Payloadは、Client ComponentとレンダリングされたServer Componentのtreeを調整し、DOMを更新するために使用されます -3. JavaScriptの命令は[hydrate](https://react.dev/reference/react-dom/client/hydrateRoot)を使用してClient Componentsをインタラクティブにするために使用されます +1. HTMLはClientとServer Componentsの即座に速く非インタラクティブな初期プレビューを示すために使用されます； +2. React Server Components PayloadがClientでレンダリングされたServer Component treeと調停され、DOMを更新するために使用されます； +3. JavaScriptの指示はClient Componentsを[ハイドレート](https://react.dev/reference/react-dom/client/hydrateRoot)し、アプリケーションをインタラクティブにします； -### 4. クライアント上でのNext.jsキャッシュ (Router Cache) {#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は、Layouts、Loading states、Pagesごとに分割されたクライアント側のRouter Cacheに保存されます。このRouter Cacheは、以前に訪問したルートを保存し、将来のルートをプリフェッチすることで、ナビゲーションエクスペリエンスを向上させるために使用されます。 -### 5. 以降のナビゲーション {#5-subsequent-navigations} +### 5. Subsequent Navigations {#5-subsequent-navigations} -次回のナビゲーションやプレフェッチ中、Next.jsはReact Server Components PayloadがRouter Cacheに保存されているかどうかを確認します。そうである場合、新しいリクエストをサーバに送信するのをスキップします。 +その後のナビゲーションまたはプリフェッチ中、Next.jsはReact Server Components PayloadがRouter Cacheに保存されているか確認します。そうであれば、新たなリクエストをサーバーに送信するのをスキップします。 -ルートセグメントがキャッシュにない場合、Next.jsはReact Server Components Payloadをサーバからフェッチし、クライアント上でRouter Cacheに追加します。 +ルートセグメントがキャッシュにない場合、Next.jsはReact Server Components Payloadをサーバーから取得し、クライアントでRouter Cacheをポピュレートします。 ### 静的および動的レンダリング {#static-and-dynamic-rendering} -ルートがビルド時にキャッシュされるかどうかは、それが静的にレンダリングされるか動的にレンダリングされるかによります。静的ルートはデフォルトでキャッシュされますが、動的ルートはリクエスト時にレンダリングされ、キャッシュされません。 +ビルド時にルートがキャッシュされるかどうかは、そのルートが静的または動的にレンダリングされるかによります。静的ルートはデフォルトでキャッシュされますが、動的ルートはリクエスト時にレンダリングされ、キャッシュされません； -この図は、静的および動的にレンダリングされたルートの違いを、キャッシュされたデータとキャッシュされていないデータを含んで示しています： +この図は、キャッシュされたデータとキャッシュされていないデータで静的にレンダリングされたルートと動的にレンダリングされたルートの違いを示しています： 静的および動的レンダリングがFull Route Cacheにどのように影響するかを示す図。静的ルートはビルド時またはデータの再検証後にキャッシュされ、動的ルートは決してキャッシュされない。 -[静的および動的レンダリング](/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は永続的です。これは、レンダリング出力がユーザーのリクエストを超えてキャッシュされることを意味します。 +デフォルトでは、Full Route Cacheは永続的です。これは、レンダリング出力がユーザーリクエストを横断してキャッシュされていることを意味します。 ### 無効化 {#invalidation} -Full Route Cacheを無効化する方法は次の2通りです： +Full Route Cacheを無効化する方法は2つあります： -- **[データの再検証](/docs/app/building-your-application/caching#revalidating)**： [Data Cache](#data-cache)を再検証すると、サーバでコンポーネントを再レンダリングし、新しいレンダリング出力をキャッシュすることによって、Router Cacheも無効化されます。 -- **再デプロイ**： デプロイ間で永続的なData Cacheとは異なり、Full Route Cacheは新しいデプロイでクリアされます。 +- **[データの再検証](/docs/app/building-your-application/caching#revalidating)**： [Data Cache](#data-cache)を再検証すると、Router Cacheはサーバー上でコンポーネントを再レンダリングし、新しいレンダリング出力をキャッシュすることで無効化されます； +- **再デプロイ**： デプロイをまたいで永続するData Cacheと異なり、Full Route Cacheは新しいデプロイ時にクリアされます； ### オプトアウト {#opting-out} -Full Route Cacheをオプトアウトする、または言いかえると、動的にレンダリングするためには次のように行います： +Full Route Cacheからオプトアウトする、つまり、すべてのリクエストに対してコンポーネントを動的にレンダリングするには、次の方法があります： -- **[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`リクエストに関しては、着陸リクエストごとにデータがフェッチされますが、他のキャッシュをオプトアウトしない`fetch`リクエストは引き続きData Cacheにキャッシュされます。これにより、キャッシュされたデータとキャッシュされていないデータのハイブリッドが可能になります。 +- **[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`リクエストのデータは,各リクエストごとに取得されます。他のキャッシュをオプトアウトしていない`fetch`リクエストの場合、それらは引き続きData Cacheにキャッシュされます。これにより、キャッシュされたデータとキャッシュされていないデータのハイブリッドが可能になります。 -## クライアントサイドRouter Cache {#client-side-router-cache} +## クライアント側Router Cache {#client-side-router-cache} -Next.jsには、ルートセグメントのRSCペイロードをレイアウト、読み込み状態、ページごとに分割して保存する、クライアントサイドのメモリ内Router Cacheがあります。 +Next.jsには、ルートセグメントのRSCペイロードを、レイアウト、 ローディング状態、ページごとに分割してキャッシュするインメモリーのクライアント側Router Cacheがあります。 -ユーザーがルート間を移動するとき、Next.jsは訪問したルートセグメントをキャッシュし、ユーザーがナビゲートする可能性の高いルートを[プレフェッチ](/docs/app/building-your-application/routing/linking-and-navigating#2-prefetching)します。これにより、ナビゲーション間での完全なページのリロードを行うことなく、即座の戻る/進むナビゲーションが可能になり、React状態とブラウザの状態が保存されます。 +ユーザーがルート間をナビゲートするとき、Next.jsは訪問したルートセグメントをキャッシュし、ユーザーが移動する可能性のあるルートを[プリフェッチ](/docs/app/building-your-application/routing/linking-and-navigating#2-prefetching)します。これにより、バック/フォワードナビゲーションが瞬時になり、ナビゲーション間でのページ全体のリロードがなくなり、React stateとブラウザstateが保持されます。 -Router Cacheを使用すると： +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/next-config-js/staleTimes)設定オプションを使用できます +- **レイアウト**はキャッシュされ、ナビゲーション時に再利用されます（[部分的レンダリング](/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/next-config-js/staleTimes)設定オプションを使用します； -{/* TODO: Update diagram to match v15 behavior */} +{/* TODO: v15の動作に合わせて図を更新する */} -> **Good to know:** このキャッシュは特にNext.jsとServer Componentsに適用され、ブラウザの[bfcache](https://web.dev/bfcache/)とは異なりますが、似たような結果を持ちます。 +> **知っておくとよいこと**：このキャッシュは特にNext.jsおよびServer Componentsに適用され、ブラウザの[bfcache](https://web.dev/bfcache/)とは異なりますが、似た結果をもたらします。 ### 期間 {#duration} -キャッシュはブラウザの一時メモリに保存されます。routerのキャッシュが持続する期間は次の2つの要素で決まります： +キャッシュはブラウザの一時メモリーに保存されます。Router Cacheの持続期間を決定するのは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分間です +- **セッション**： キャッシュはナビゲーション中に永続します。ただし、ページをリフレッシュするとクリアされます； +- **自動無効化期間**：レイアウトとローディング状態のキャッシュは特定の時間が経過後に自動的に無効化されます。この持続時間は、リソースがどのように[プリフェッチ](/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/next-config-js/staleTimes)設定オプションを使用して、上記の自動無効化時間を調整できます。 +> **知っておくとよいこと**: 実験的な[`staleTimes`](/docs/app/api-reference/next-config-js/staleTimes)設定オプションを使用すると、前述の自動無効化時間を調整できます； ### 無効化 {#invalidation} -Router Cacheを無効化する方法は次の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#methods)または[`cookies.delete`](/docs/app/api-reference/functions/cookies#methods)を使用して、cookieを使用するルートが古くならないようにRouter Cacheを無効化します（例：認証） -- [`router.refresh`](/docs/app/api-reference/functions/use-router)を呼び出すことで、Router Cacheを無効化し、現在のルートに対してサーバへの新しいリクエストを行います +- **Server Action**内で： + - ([`revalidatePath`](/docs/app/api-reference/functions/revalidatePath))を使用してパスごとにデータをオンデマンドで再検証する、または([`revalidateTag`](/docs/app/api-reference/functions/revalidateTag))を使用してキャッシュタグごとにデータをオンデマンドで再検証する； + - [`cookies.set`](/docs/app/api-reference/functions/cookies#methods)または[`cookies.delete`](/docs/app/api-reference/functions/cookies#methods)を使用してRouter Cacheを無効化し、cookieを使用しているルートが古くならないようにします（例：認証）； +- [`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)もオプトアウトできます。 +> **知っておくとよいこと**：``コンポーネントの`prefetch` propを`false`に設定することで、[プリフェッチング](/docs/app/building-your-application/routing/linking-and-navigating#2-prefetching)をオプトアウトすることもできます； ## キャッシュの相互作用 {#cache-interactions} -異なるキャッシュメカニズムを設定するとき、これらがどのように相互作用するかを理解することが重要です： +さまざまなキャッシュメカニズムを設定する際には、それらがどのように相互作用するかを理解することが重要です； -### Data CacheとFull Route Cache {#data-cache-and-full-route-cache} +### データキャッシュとFull Route Cache {#data-cache-and-full-route-cache} -- Data Cacheの再検証またはオプトアウトを行うと、Full Route Cacheは無効化されます。なぜなら、レンダリング出力がデータに依存するからです -- Full Route Cacheの無効化またはオプトアウトはData Cacheに影響しません。キャッシュされたデータとキャッシュされていないデータが混在するルートを動的にレンダリングすることができます。これは、ページの大部分がキャッシュされたデータを使用する場合に便利ですが、リクエスト時にフェッチする必要があるデータに依存するコンポーネントがいくつかあります。すべてのデータを再フェッチすることによるパフォーマンスへの影響を心配せずに、動的にレンダリングできます +- Data Cacheを再検証またはオプトアウトすると、レンダリング出力がデータに依存しているため、Full Route Cacheが無効化されます； +- Full Route Cacheを無効化またはオプトアウトしても、Data Cacheには影響しません。キャッシュされたデータとされていないデータを持つルートを動的にレンダリングすることができます。これは、あなたのページのほとんどがキャッシュされたデータを使用していますが、リクエスト時に取得する必要のあるデータに依存するコンポーネントがいくつかある場合に便利です。すべてのデータを再取得するパフォーマンスの影響を心配することなく動的にレンダリングできます； -### Data CacheとクライアントサイドRouter cache {#data-cache-and-client-side-router-cache} +### データキャッシュとクライアント側Router cache {#data-cache-and-client-side-router-cache} -- Data CacheとRouter cacheをすぐに無効化するには、Server Actionで[`revalidatePath`](#revalidatepath)または[`revalidateTag`](#fetch-optionsnexttags-and-revalidatetag)を使用します -- Router Handlerは特定のルートに結びついていないため、[Route Handler](/docs/app/building-your-application/routing/route-handlers)でのData Cacheの再検証はRouter Cacheをすぐには無効化しません。つまり、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 Cacheは即座に無効化されません。Route Handlerは特定のルートに結びつけられていないためです；これは、ハードリフレッシュまたは自動的な無効化期間が経過するまで、Router Cacheが以前のペイロードを提供し続けることを意味します； -## APIs {#apis} +## API {#apis} -以下の表は、異なるNext.jsのAPIがキャッシュにどのように影響するかの概要を示しています： +次の表は、さまざまなNext.js APIがキャッシュにどのように影響するかの概要を示しています： -| API | Router Cache | Full Route 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またはオプトアウト | | -| [`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またはオプトアウト | Revalidateまたはオプトアウト | | -| [`const dynamic`](#segment-config-options) | | Cacheまたはオプトアウト | Cacheまたはオプトアウト | | -| [`cookies`](#cookies) | Revalidate (Server Action) | オプトアウト | | | -| [`headers`, `searchParams`](#dynamic-apis) | | オプトアウト | | | -| [`generateStaticParams`](#generatestaticparams) | | Cache | | | -| [`React.cache`](#react-cache-function) | | | | Cache | -| [`unstable_cache`](/docs/app/api-reference/functions/unstable_cache) | | | Cache | | +| API | Router Cache | 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/legacy-apis/unstable_cache) | | | キャッシュ | | ### `` {#link} -デフォルトで、``コンポーネントはFull Route Cacheからルートを自動的にプレフェッチし、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`オプションを使用してルートを手動でプリフェッチできます。これはRouter CacheにReact Server Component Payloadを追加します； -[`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`はDataまたはFull Route Cacheに影響しません。 +`useRouter` フックの`refresh`オプションを使用してルートを手動で更新できます。これはRouter Cacheを完全にクリアし、現在のルートのためにサーバーに新しいリクエストを行います。 `refresh` はDataまたはFull Route Cacheに影響を与えません； -レンダリングされた結果はReact状態とブラウザの状態が保持された状態でクライアント上で調整されます。 +レンダリングされた結果は、リアクトステートとブラウザーステートを保持しながらクライアント上で調停されます； -[`useRouter`フック](/docs/app/api-reference/functions/use-router)のAPIリファレンスを参照してください。 +[`useRouter` フック](/docs/app/api-reference/functions/use-router)APIリファレンスを参照してください； ### `fetch` {#fetch} -`fetch`から返されるデータは自動的にData Cacheにキャッシュされます。 +`fetch`から返されるデータは自動的にData Cacheにキャッシュされます； -`fetch`のレスポンスをキャッシュしたくない場合は、以下のことを行うことができます： +`fetch`からのレスポンスをキャッシュしたくない場合、以下を行うことができます： ```js let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' }) ``` -他のオプションについては、[`fetch` APIリファレンス](/docs/app/api-reference/functions/fetch)を参照してください。 +[`fetch` APIリファレンス](/docs/app/api-reference/functions/fetch)で詳細オプションを参照できます； ### `fetch options.cache` {#fetch-options-cache} -個々の`fetch`を強制的にキャッシュさせるために`cache`オプションを`force-cache`に設定できます： +`cache`オプションを`force-cache`に設定して個別の`fetch`をキャッシュにオプトインできます： ```jsx -// キャッシュをオプトイン +// キャッシュにオプトイン fetch(`https://...`, { cache: 'force-cache' }) ``` -他のオプションについては、[`fetch` APIリファレンス](/docs/app/api-reference/functions/fetch)を参照してください。 +[`fetch` APIリファレンス](/docs/app/api-reference/functions/fetch)を参照して詳細オプションを確認してください； ### `fetch options.next.revalidate` {#fetch-options-next-revalidate} -`fetch`の`next.revalidate`オプションを使用して、個々の`fetch`リクエストの再検証期間（秒単位）を設定できます。これによりData Cacheが再検証され、結果としてFull Route Cacheも再検証されます。新鮮なデータが取得され、コンポーネントがサーバ上で再レンダリングされます。 +`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リファレンス](/docs/app/api-reference/functions/fetch)を参照して詳細オプションを確認してください； -### `fetch options.next.tags`と`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/legacy-apis/unstable_cache)を使用する場合、キャッシュエントリに1つ以上のタグを設定するオプションがあります； +2. 次に、`revalidateTag`を呼び出して、そのタグに関連付けられたキャッシュエントリを削除できます； たとえば、データをフェッチする際にタグを設定できます： @@ -470,70 +470,70 @@ Next.jsは微細なデータキャッシュと再検証のためのキャッシ fetch(`https://...`, { next: { tags: ['a', 'b', 'c'] } }) ``` -その後、特定のタグでキャッシュエントリを消去するために`revalidateTag`を呼び出します： +次に、`revalidateTag`をタグで呼び出してキャッシュエントリを削除します： ```jsx // 特定のタグでエントリを再検証 revalidateTag('a') ``` -達成しようとしている内容に応じて、`revalidateTag`を使用する2つの場所があります： +あなたが達成しようとしている内容に基づいて、`revalidateTag`を2つの場所で使用できます： -1. [Route Handlers](/docs/app/building-your-application/routing/route-handlers) - サードパーティのイベントに応じてデータを再検証するため（例：ウェブフック）。これは、Router Handlerが特定のルートに結びついていないため、Router Cacheを直ちに無効化しません。 -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 Handlerが特定のルートに結びついていないため、Router Cacheを即座に無効にしません； +2. [Server Actions](/docs/app/building-your-application/data-fetching/server-actions-and-mutations) - ユーザーアクション（例：フォームの送信）の後にデータを再検証する；これは関連付けられたルートのRouter Cacheを無効にします； ### `revalidatePath` {#revalidatepath} -`revalidatePath`を使用すると、単一の操作でデータを手動で再検証し、特定のパス下のルートセグメントを再レンダリングすることができます。`revalidatePath`メソッドを呼び出すことにより、Data Cacheが再検証され、それに続いてFull Route Cacheが無効化されます。 +`revalidatePath`を使うと、データを**再検証**し特定のパス下のルートセグメントを再レンダリングするメソッドで、一度の操作で手動でデータを再検証できます。 `revalidatePath`メソッドを呼び出すと、Data Cacheが再検証され、それによってFull Route Cacheが無効化されます； ```jsx revalidatePath('/') ``` -達成しようとしている内容に応じて、`revalidatePath`を使用する2つの場所があります： +あなたが達成しようとしている内容に基づいて、`revalidatePath`を2つの場所で使用できます： -1. [Route Handlers](/docs/app/building-your-application/routing/route-handlers) - サードパーティのイベントに応じてデータを再検証するため（例：ウェブフック）。 -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`** vs. **`router.refresh`**： +> **`revalidatePath`**と**`router.refresh`**： > -> `router.refresh`を呼び出すと、Router cacheがクリアされ、Data CacheやFull Route Cacheを無効化することなく、サーバ上でルートセグメントが再レンダリングされます。 +> `router.refresh`を呼び出すと、Data CacheやFull Route Cacheを無効にすることなく、Router cacheをクリアし、サーバー上のルートセグメントを再レンダリングします； > -> 違いは、`revalidatePath`がData CacheとFull Route Cacheをパージするのに対して、`router.refresh()`はData CacheやFull Route Cacheを変更しないクライアントサイドAPIです。 +> `revalidatePath`はData CacheやFull Route Cacheを削除するのに対して、`router.refresh()`はData CacheやFull Route Cacheを変更しません；これはクライアントサイドのAPIであるためです； -### 動的API {#dynamic-apis} +### Dynamic API {#dynamic-apis} -`cookies`や`headers`などの動的API、Pagesの`searchParams` propは、ランタイムの着信リクエスト情報に依存します。これらを使用すると、ルートはFull Route Cacheからオプトアウトされ、つまり、ルートは動的にレンダリングされます。 +`cookies`、`headers`、およびPagesの`searchParams`プロップなどのDynamic APIは、実行時のリクエスト情報に依存します。それらを使用すると、ルートがFull Route Cacheをオプトアウトし、動的にレンダリングされることになります； #### `cookies` {#cookies} -Server Action内で`cookies.set`または`cookies.delete`を使用すると、cookieを使用するルートが古くならないようにRouter Cacheが無効化されます（例：認証の変更を反映するため）。 +Server Actionで`cookies.set`または`cookies.delete`を使用すると、cookieを使用するルートが古くならないように、Router Cacheが無効化されます（例：認証の変更を反映するため）； -[`cookies`](/docs/app/api-reference/functions/cookies) APIリファレンスを参照してください。 +[`cookies`](/docs/app/api-reference/functions/cookies)APIリファレンスを参照してください； ### セグメント設定オプション {#segment-config-options} -Route Segment Configオプションは`fetch` APIを使用できない場合（例：データベースクライアントやサードパーティライブラリ）に、ルートセグメントのデフォルト設定を上書きするために使用できます。 +Route Segment Configオプションは、デフォルトのスルートセグメントをオーバーライドするためや`fetch` APIを使用できない場合（例：データベースクライアントまたはサードパーティライブラリ）に使用できます； -以下のRoute Segment Configオプションは、Full Route Cacheのオプトアウトを行います： +次のRoute Segment ConfigオプションがFull Route Cacheからオプトアウトします： - `const dynamic = 'force-dynamic'` -この設定オプションは、Data Cacheのすべてのフェッチをオプトアウトします（例：`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)を参照してください； -他のオプションについては、[Route Segment Config](/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`によって提供されるパスはビルド時にFull Route Cacheにキャッシュされます。リクエスト時、Next.jsは初めて訪れたパスについてもキャッシュします。 +[動的セグメント](/docs/app/building-your-application/routing/dynamic-routes)用（例：`app/blog/[slug]/page.js`）、`generateStaticParams`によって提供されたパスはビルド時にFull Route Cacheにキャッシュされます。リクエスト時、Next.jsはビルド時に知られていなかったパスも最初に訪れたときにキャッシュします。 -すべてのパスをビルド時に静的にレンダリングするには、`generateStaticParams`にパスの完全なリストを提供してください： +すべてのパスをビルド時に静的にレンダリングするには、`generateStaticParams`にパスの完全なリストを提供します： ```jsx title="app/blog/[slug]/page.js" export async function generateStaticParams() { @@ -545,7 +545,7 @@ export async function generateStaticParams() { } ``` -一部のパスをビルド時に静的にレンダリングし、残りを実行時に初めて訪問された時に静的にレンダリングするには、部分的なパスリストを返します： +ビルド時に一部のパスを静的にレンダリングし、残りのパスを最初に訪れた際に実行時にレンダリングするには、部分的なリストを返します： ```jsx title="app/blog/[slug]/page.js" export async function generateStaticParams() { @@ -558,7 +558,7 @@ export async function generateStaticParams() { } ``` -すべてのパスを初めて訪れた時に静的にレンダリングするには、空の配列を返して（ビルド時にパスがレンダリングされない）、または[`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() { @@ -566,19 +566,19 @@ export async function generateStaticParams() { } ``` -> **Good to know:** `generateStaticParams`からは、たとえ空であっても、配列を返す必要があります。そうでない場合、ルートは動的にレンダリングされます。 +> **知っておくとよいこと**： `generateStaticParams`からは、空であっても配列を返す必要があります。そうしなければ、そのルートは動的にレンダリングされます； ```jsx title="app/changelog/[slug]/page.js" export const dynamic = 'force-static' ``` -リクエスト時にキャッシュを無効にするには、ルートセグメントに`export const dynamicParams = false`オプションを追加します。この設定オプションを使用する場合、`generateStaticParams`で提供されたパスのみが提供され、他のルートは404または一致します（[catch-allルート](/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` 関数を使用すると、関数の戻り値をメモ化し、同じ関数を複数回呼び出すことができますが、一度だけ実行します。 -`fetch`リクエストは自動的にメモ化されるため、React `cache`でラップする必要はありません。ただし、`cache` を使用して、`fetch` APIが適さないユースケースのデータリクエストを手動でメモ化できます。たとえば、一部のデータベースクライアント、CMSクライアント、またはGraphQLクライアントです。 +`fetch`リクエストは自動的にメモ化されるため、React `cache`でラップする必要はありません。ただし、`fetch` APIが適さないケースの場合、データリクエストを手動でメモ化するために`cache`を使用できます。たとえば、いくつかのデータベースクライアント、CMSクライアント、またはGraphQLクライアントの場合です。 diff --git a/docs/02-app/01-building-your-application/10-deploying/01-production-checklist.mdx b/docs/02-app/01-building-your-application/10-deploying/01-production-checklist.mdx index 85f2d719..33621536 100644 --- a/docs/02-app/01-building-your-application/10-deploying/01-production-checklist.mdx +++ b/docs/02-app/01-building-your-application/10-deploying/01-production-checklist.mdx @@ -1,58 +1,58 @@ --- title: 'プロダクションチェックリスト' -description: 'Next.js アプリケーションをプロダクションへ移行する際に最適なパフォーマンスとユーザーエクスペリエンスを確保するための推奨事項。' +description: 'Next.jsアプリケーションをプロダクションに導入する前に、最高のパフォーマンスとユーザーエクスペリエンスを確保するための推奨事項を紹介します。' --- -Next.js アプリケーションをプロダクションへ移行する前に、最適なユーザーエクスペリエンス、パフォーマンス、セキュリティを確保するために実装を検討すべき最適化およびパターンがあります。 +Next.jsアプリケーションをプロダクションに導入する前に、最適なユーザーエクスペリエンス、パフォーマンス、安全性を実現するためのいくつかの最適化やパターンを考慮すべきです。 -このページは、[アプリケーションを構築する際](#during-development)、[プロダクションへ移行する前](#before-going-to-production)、および[デプロイ後](#after-deployment)に参照できるベストプラクティスを提供しています。また、知っておくべき[Next.js の自動最適化](#automatic-optimizations)についても説明しています。 +このページでは、[アプリケーションをビルドするとき](#during-development)、[プロダクションに進む前](#before-going-to-production)、および[デプロイ後](#after-deployment)に参考にできるベストプラクティスと、知っておくべき[Next.jsの自動最適化](#automatic-optimizations)を紹介します。 ## 自動最適化 {#automatic-optimizations} -これらの Next.js の最適化はデフォルトで有効であり、設定は不要です： +これらのNext.jsの最適化はデフォルトで有効で、設定は不要です： -- **[Server Components](/docs/app/building-your-application/rendering/server-components)：** Next.js はデフォルトで Server Components を使用します。Server Components はサーバー上で実行され、クライアント上でのレンダリングに JavaScript を必要としません。そのため、クライアント側の JavaScript バンドルのサイズに影響を与えません。対話性のために必要に応じて [Client Components](/docs/app/building-your-application/rendering/client-components) を利用できます。 -- **[コードスプリッティング](/docs/app/building-your-application/routing/linking-and-navigating#how-routing-and-navigation-works)：** Server Components はルートセグメントによる自動コードスプリッティングを可能にします。また、場合に応じて [Client Components](/docs/app/building-your-application/optimizing/lazy-loading) やサードパーティライブラリの遅延読み込みを検討してください。 -- **[プリフェッチ](/docs/app/building-your-application/routing/linking-and-navigating#2-prefetching)：** 新しいルートへのリンクがユーザーのビューポートに入ると、Next.js はバックグラウンドでそのルートをプリフェッチします。これにより、新しいルートへのナビゲーションがほぼ即時に行えます。場合に応じて、プリフェッチをオプトアウトできます。 -- **[静的レンダリング](/docs/app/building-your-application/rendering/server-components#static-rendering-default)：** Next.js はビルド時にサーバー上でサーバーおよびクライアントコンポーネントを静的にレンダリングし、レンダリングされた結果をキャッシュしてアプリケーションのパフォーマンスを向上させます。必要に応じて、特定のルートで [動的レンダリング](/docs/app/building-your-application/rendering/server-components#dynamic-rendering) にオプトインできます。 {/* TODO: PPR が安定したら更新 */} -- **[キャッシング](/docs/app/building-your-application/caching)：** Next.js はデータリクエスト、サーバーおよびクライアントコンポーネントのレンダリング結果、静的アセットなどをキャッシュし、サーバー、データベース、およびバックエンドサービスへのネットワークリクエストの数を減らします。必要に応じて、キャッシングをオプトアウトできます。 +- **[Server Components](/docs/app/building-your-application/rendering/server-components):** Next.jsはデフォルトでServer Componentを使用します。Server Componentはサーバー上で実行され、クライアントサイドでのJavaScriptのレンダリングを必要としません。そのため、クライアントサイドJavaScriptバンドルのサイズに影響を与えません。必要に応じて、インタラクティブ性のために[Client Component](/docs/app/building-your-application/rendering/client-components)を使用できます。 +- **[コード分割](/docs/app/building-your-application/routing/linking-and-navigating#how-routing-and-navigation-works):** Server Componentはルートセグメントごとに自動的なコード分割を可能にします。適切な場合は、Client Componentやサードパーティライブラリーの[遅延読み込み](/docs/app/building-your-application/optimizing/lazy-loading)を検討してください。 +- **[プリフェッチ](/docs/app/building-your-application/routing/linking-and-navigating#2-prefetching):** 新しいルートへのリンクがユーザーのビューポートに入ると、Next.jsはバックグラウンドでそのルートをプリフェッチします。これにより、新しいルートへのナビゲーションがほぼ瞬時に行われます。必要に応じてプリフェッチをオプトアウトできます。 +- **[静的レンダリング](/docs/app/building-your-application/rendering/server-components#static-rendering-default):** Next.jsはビルド時にサーバー上でServer ComponentとClient Componentを静的にレンダリングし、アプリケーションのパフォーマンスを向上させるためにキャッシュします。必要に応じて特定のルートに[動的レンダリング](/docs/app/building-your-application/rendering/server-components#dynamic-rendering)を選択できます。 {/* TODO: PPRが安定したら更新 */} +- **[キャッシング](/docs/app/building-your-application/caching):** Next.jsは、データリクエスト、Server ComponentやClient Componentのレンダリング結果、静的アセットなどをキャッシュして、サーバー、データベース、バックエンドサービスへのネットワークリクエスト数を減らします。必要に応じてキャッシングをオプトアウトすることができます。 -- **[コードスプリッティング](https://nextjs.org/docs/canary/pages/building-your-application/routing/pages-and-layouts)：** Next.js はアプリケーションのコードをページごとに自動的にコードスプリッティングします。これにより、ナビゲーション時に現在のページに必要なコードのみが読み込まれます。また、場合に応じてサードパーティライブラリの[遅延読み込み](https://nextjs.org/docs/canary/pages/building-your-application/optimizing/lazy-loading)を検討してください。 -- **[プリフェッチ](https://nextjs.org/docs/canary/pages/api-reference/components/link#prefetch)：** 新しいルートへのリンクがユーザーのビューポートに入ると、Next.js はバックグラウンドでそのルートをプリフェッチします。これにより、新しいルートへのナビゲーションがほぼ即時に行えます。場合に応じて、プリフェッチをオプトアウトできます。 -- **[自動静的最適化](https://nextjs.org/docs/canary/pages/building-your-application/rendering/automatic-static-optimization)：** Next.js は、ページにブロックされるデータ要件がない場合、そのページが静的（事前レンダリング可能）であることを自動的に判断します。最適化されたページはキャッシュされ、複数の CDN ロケーションからエンドユーザーに提供されます。必要に応じて、[サーバーサイドレンダリング](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-server-side-props) にオプトインできます。 +- **[コード分割](https://nextjs.org/docs/canary/pages/building-your-application/routing/pages-and-layouts):** Next.jsは自動的にアプリケーションコードをページごとにコード分割します。これにより、ナビゲーション時に現在のページに必要なコードだけが読み込まれます。適切な場合は、サードパーティライブラリーの[遅延読み込み](https://nextjs.org/docs/canary/pages/building-your-application/optimizing/lazy-loading)を検討してください。 +- **[プリフェッチ](https://nextjs.org/docs/canary/pages/api-reference/components/link#prefetch):** 新しいルートへのリンクがユーザーのビューポートに入ると、Next.jsはバックグラウンドでそのルートをプリフェッチします。これにより、新しいルートへのナビゲーションがほぼ瞬時になります。必要に応じてプリフェッチをオプトアウトしてください。 +- **[自動静的最適化](https://nextjs.org/docs/canary/pages/building-your-application/rendering/automatic-static-optimization):** Next.jsはページがブロッキングデータ要件を持たない場合に、ページが静的である（プリレンダリング可能である）と自動的に判断します。最適化されたページはキャッシュされ、エンドユーザーに複数のCDNロケーションから配信されます。必要に応じて[サーバーサイドレンダリング](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-server-side-props)を選択できます。 -これらのデフォルト設定は、アプリケーションのパフォーマンスを向上させ、各ネットワークリクエストでのデータ転送量とコストを削減することを目的としています。 +これらのデフォルト設定は、アプリケーションのパフォーマンスを向上させ、各ネットワークリクエストで転送されるコストとデータ量を削減することを目的としています。 -## 開発中 {#during-development} +## 開発中に {#during-development} -アプリケーションを構築する際に、最適なパフォーマンスとユーザーエクスペリエンスを確保するために、以下の機能の使用をお勧めします： +アプリケーションを構築する際には、以下の機能を使用して、最高のパフォーマンスとユーザーエクスペリエンスを確保することをおすすめします： ### ルーティングとレンダリング {#routing-and-rendering} -- **[レイアウト](/docs/app/building-your-application/routing/layouts-and-templates#layouts)：** レイアウトを使用してページ間で UI を共有し、ナビゲーション時に [部分レンダリング](/docs/app/building-your-application/routing/linking-and-navigating#4-partial-rendering) を有効にします。 -- **[`` コンポーネント](/docs/app/building-your-application/routing/linking-and-navigating#link-component)：** `` コンポーネントを使用して、[クライアントサイドでのナビゲーションとプリフェッチ](/docs/app/building-your-application/routing/linking-and-navigating#how-routing-and-navigation-works) を行います。 -- **[エラーハンドリング](/docs/app/building-your-application/routing/error-handling)：** カスタムエラーページを作成することにより、プロダクションで[キャッチオールエラー](/docs/app/building-your-application/routing/error-handling)と [404 エラー](/docs/app/api-reference/file-conventions/not-found)を適切に処理します。 -- **[コンポジションパターン](/docs/app/building-your-application/rendering/composition-patterns)：** サーバーおよびクライアントコンポーネントの推奨されるコンポジションパターンに従い、[`"use client"` 境界](/docs/app/building-your-application/rendering/composition-patterns#moving-client-components-down-the-tree)の配置を確認し、クライアントサイドの JavaScript バンドルを不必要に増加させないようにします。 -- **[動的 API](/docs/app/building-your-application/rendering/server-components#dynamic-apis)：** [`cookies`](/docs/app/api-reference/functions/cookies) や [`searchParams`](/docs/app/api-reference/file-conventions/page#searchparams-optional) プロップのような動的 API が[動的レンダリング](/docs/app/building-your-application/rendering/server-components#dynamic-rendering)（または[Root レイアウト](/docs/app/building-your-application/routing/layouts-and-templates#root-layout-required)で使用される場合はアプリ全体）へルート全体をオプトインさせることを認識します。動的 API の使用は意図的であり、必要に応じてそれらを `` 境界でラップしていることを確認します。 +- **[レイアウト](/docs/app/building-your-application/routing/layouts-and-templates#layouts):** レイアウトを使用して、ページ間でUIを共有し、ナビゲーション時に[部分レンダリング](/docs/app/building-your-application/routing/linking-and-navigating#4-partial-rendering)を可能にします。 +- **[``コンポーネント](/docs/app/building-your-application/routing/linking-and-navigating#link-component):** ``コンポーネントを使用して[クライアントサイドナビゲーションとプリフェッチ](/docs/app/building-your-application/routing/linking-and-navigating#how-routing-and-navigation-works)を行います。 +- **[エラーハンドリング](/docs/app/building-your-application/routing/error-handling):** カスタムエラーページを作成することで、プロダクションにおいて[全体エラー](/docs/app/building-your-application/routing/error-handling)や[404エラー](/docs/app/api-reference/file-conventions/not-found)を優雅に処理します。 +- **[コンポジションパターン](/docs/app/building-your-application/rendering/composition-patterns):** Server ComponentとClient Component向けの推奨されるコンポジションパターンに従い、クライアントサイドJavaScriptバンドルを不必要に増やすことを避けるために[`"use client"`境界](/docs/app/building-your-application/rendering/composition-patterns#moving-client-components-down-the-tree)の配置を確認します。 +- **[動的API](/docs/app/building-your-application/rendering/server-components#dynamic-apis):** [`cookies`](/docs/app/api-reference/functions/cookies)や[`searchParams`](/docs/app/api-reference/file-conventions/page#searchparams-optional) propのような動的APIは、ルート全体を[動的レンダリング](/docs/app/building-your-application/rendering/server-components#dynamic-rendering)にオプトインさせることに注意してください（Root Layoutで使用される場合は、アプリケーション全体）。動的APIの使用が意図的であることを確認し、適宜``境界でラップしてください。 -> **Good to know**: [Partial Prerendering（実験的）](https://nextjs.org/blog/next-14#partial-prerendering-preview) により、ルート全体を動的レンダリングにオプトインすることなくルートの一部を動的にすることが可能になります。 +> **知っておくと良い情報**: [部分プリレンダリング（実験的）](https://nextjs.org/blog/next-14#partial-prerendering-preview)は、ルートの一部を動的にすることを可能にし、ルート全体を動的レンダリングにオプトインすることなく行うことができます。 -- **[`` コンポーネント](https://nextjs.org/docs/canary/pages/building-your-application/routing/linking-and-navigating)：** `` コンポーネントを使用して、クライアントサイドでのナビゲーションおよびプリフェッチを行います。 -- **[カスタムエラー](https://nextjs.org/docs/canary/pages/building-your-application/routing/custom-error)：** [500](https://nextjs.org/docs/canary/pages/building-your-application/routing/custom-error#500-page) および [404 エラー](https://nextjs.org/docs/canary/pages/building-your-application/routing/custom-error#404-page)を適切に処理します。 +- **[``コンポーネント](https://nextjs.org/docs/canary/pages/building-your-application/routing/linking-and-navigating):** ``コンポーネントを使用してクライアントサイドナビゲーションとプリフェッチを行います。 +- **[カスタムエラー](https://nextjs.org/docs/canary/pages/building-your-application/routing/custom-error):** 500エラーや404エラーを優雅に処理します。 @@ -60,88 +60,88 @@ Next.js アプリケーションをプロダクションへ移行する前に、 -- **[サーバーコンポーネント](/docs/app/building-your-application/data-fetching/fetching)：** サーバー上でデータをフェッチする利点をサーバーコンポーネントを使用して活用します。 -- **[ルートハンドラー](/docs/app/building-your-application/routing/route-handlers)：** ルートハンドラーを使用してクライアントコンポーネントからバックエンドリソースへアクセスします。ただし、追加のサーバーリクエストを避けるためにサーバーコンポーネントからルートハンドラーを呼び出さないようにします。 -- **[ストリーミング](/docs/app/building-your-application/routing/loading-ui-and-streaming)：** Loading UI と React Suspense を使用して、UI をサーバーからクライアントに段階的に送信し、データフェッチ中にルート全体がブロックされることを防ぎます。 -- **[並行データフェッチ](/docs/app/building-your-application/data-fetching/fetching#parallel-and-sequential-data-fetching)：** 必要に応じて、データを並行してフェッチし、ネットワークウォーターフォールを削減します。また、必要に応じて[データをプレロード](/docs/app/building-your-application/data-fetching/fetching#preloading-data)することを検討してください。 -- **[データキャッシング](/docs/app/building-your-application/caching#data-cache)：** データリクエストがキャッシュされているかどうかを確認し、必要に応じてキャッシングにオプトインします。`fetch` を使用しないリクエストが[キャッシュされている](/docs/app/api-reference/functions/unstable_cache)ことを確認します。 -- **[静的画像](/docs/app/building-your-application/optimizing/static-assets)：** `public` ディレクトリを使用して、アプリケーションの静的アセット（例えば画像）を自動的にキャッシュします。 +- **[Server Component](/docs/app/building-your-application/data-fetching/fetching):** Server Componentsを使用してデータをサーバー上でフェッチするメリットを活用します。 +- **[ルートハンドラー](/docs/app/building-your-application/routing/route-handlers):** Client Componentからバックエンドのリソースにアクセスするためにルートハンドラーを使用します。ただし、追加のサーバーリクエストを避けるため、Server Componentsからルートハンドラーを呼び出さないでください。 +- **[ストリーミング](/docs/app/building-your-application/routing/loading-ui-and-streaming):** サーバーからクライアントにUIを逐次送信するためにローディングUIとReact Suspenseを使用し、データがフェッチされる間、ルート全体がブロックされるのを防ぎます。 +- **[並列データフェッチ](/docs/app/building-your-application/data-fetching/fetching#parallel-and-sequential-data-fetching):** 必要に応じてデータを並列にフェッチすることでネットワークウォーターフォールを縮小します。また、必要に応じてデータを[プリロードすること](/docs/app/building-your-application/data-fetching/fetching#preloading-data)を検討してください。 +- **[データキャッシング](/docs/app/building-your-application/caching#data-cache):** データリクエストがキャッシュされているかどうかを確認し、必要に応じてキャッシングを選択します。`fetch`を使用しないリクエストがキャッシュされることを確認し、キャッシュされることを確認してください。 +- **[静的画像](/docs/app/building-your-application/optimizing/static-assets):** `public`ディレクトリを使用して、アプリケーションの静的アセット（例：画像）を自動的にキャッシュします。 -- **[API ルート](https://nextjs.org/docs/canary/pages/building-your-application/routing/api-routes)：** ルートハンドラーを使用してバックエンドリソースにアクセスし、機密情報がクライアントに露出しないようにします。 -- **[データキャッシング](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-static-props)：** データリクエストがキャッシュされているかどうかを確認し、必要に応じてキャッシングにオプトインします。`getStaticProps` を使用しないリクエストが適切にキャッシュされていることを確認します。 -- **[増分静的再生成](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/incremental-static-regeneration)：** 全サイトを再ビルドせずに、ビルドされた後の静的ページを更新するために増分静的再生成を使用します。 -- **[静的画像](https://nextjs.org/docs/canary/pages/building-your-application/optimizing/static-assets)：** `public` ディレクトリを使用して、アプリケーションの静的アセット（例えば画像）を自動的にキャッシュします。 +- **[APIルート](https://nextjs.org/docs/canary/pages/building-your-application/routing/api-routes):** ルートハンドラーを使用してバックエンドリソースにアクセスし、クライアントに機密情報をさらさないようにします。 +- **[データキャッシング](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-static-props):** データリクエストがキャッシュされているかどうかを確認し、必要に応じてキャッシングを選択します。`getStaticProps`を使用しないリクエストが適切にキャッシュされることを確認してください。 +- **[インクリメンタル静的再生成](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/incremental-static-regeneration):** インクリメンタル静的再生成を使用して静的ページをビルド後に更新し、サイト全体を再ビルドすることなく行います。 +- **[静的画像](https://nextjs.org/docs/canary/pages/building-your-application/optimizing/static-assets):** `public`ディレクトリを使用して、アプリケーションの静的アセット（例：画像）を自動的にキャッシュします。 -### UI とアクセシビリティ {#ui-and-accessibility} +### UIとアクセシビリティ {#ui-and-accessibility} -- **[フォームとバリデーション](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#forms)：** フォームの送信を処理、サーバーサイドでのバリデーション、エラー処理を行うためにServer Actionsを使用します。 +- **[フォームとバリデーション](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#forms):** フォームの送信、サーバーサイドのバリデーション、エラーの処理にServer Actionsを使用します。 -- **[フォントモジュール](/docs/app/building-your-application/optimizing/fonts)：** フォントモジュールを使用してフォントを最適化します。これによりフォントファイルが他の静的アセットと共に自動的にホストされ、外部ネットワークリクエストが削減され、[レイアウトシフト](https://web.dev/articles/cls)も減少します。 -- **[`` コンポーネント](/docs/app/building-your-application/optimizing/images)：** Image コンポーネントを使用して画像を最適化し、レイアウトシフトを防ぎ、WebP や AVIF などの最新形式で提供します。 -- **[`