Кэширование в Next.js

Next.js повышает производительность вашего приложения и снижает затраты, кэшируя работу рендеринга и запросы данных. Эта страница подробно рассматривает механизмы кэширования Next.js, API, которые вы можете использовать для их настройки, и как они взаимодействуют друг с другом.

Важно знать: Эта страница поможет вам понять, как Next.js работает внутри, но это не обязательно для продуктивной работы с Next.js. Большинство эвристик кэширования Next.js определяются вашим использованием API и имеют значения по умолчанию для наилучшей производительности с нулевой или минимальной настройкой.

Обзор

Вот общий обзор различных механизмов кэширования и их назначения:

По умолчанию Next.js кэширует как можно больше для повышения производительности и снижения затрат. Это означает, что маршруты статически рендерятся, а запросы данных кэшируются, если вы этого не отключили. Диаграмма ниже показывает поведение кэширования по умолчанию: когда маршрут статически рендерится во время сборки, и когда статический маршрут посещается впервые.

Поведение кэширования меняется в зависимости от того, статически или динамически рендерится маршрут, кэшируются или нет данные, и является ли запрос частью первого посещения или последующей навигации. В зависимости от вашего случая использования, вы можете настроить поведение кэширования для отдельных маршрутов и запросов данных.

Кэширование запросов

React расширяет fetch API, чтобы автоматически кэшировать запросы с одинаковым URL и параметрами. Это означает, что вы можете вызывать функцию fetch для одних и тех же данных в нескольких местах в дереве React-компонента, но она будет выполнена только один раз.

Например, если вам нужно использовать одни и те же данные по всему маршруту (например, в макете, странице и нескольких компонентах), вам не нужно извлекать данные в верхней части дерева и передавать props между компонентами. Вместо этого вы можете извлекать данные в компонентах, которые их нуждаются, не беспокоясь о последствиях производительности многократных запросов по сети для одних и тех же данных.

async function getItem() {
  // The `fetch` function is automatically memoized and the result
  // is cached
  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
 
// The second call could be anywhere in your route
const item = await getItem() // cache HIT

Как работает кэширование запросов

• Во время рендеринга маршрута, в первый раз, когда вызывается конкретный запрос, его результат не находится в памяти, и это кэш MISS.
• Поэтому функция будет выполнена, данные будут извлечены из внешнего источника, а результат будет сохранен в памяти.
• Последующие вызовы функции запроса в том же цикле рендеринга будут кэшем HIT, а данные будут возвращены из памяти без выполнения функции.
• После того, как маршрут был отображен и цикл рендеринга завершен, память «обнуляется», и все записи кэша запросов очищаются.

Важно знать:

• Кэширование запросов — это функция React, а не Next.js. Она включена здесь, чтобы показать, как она взаимодействует с другими механизмами кэширования.
• Кэширование применяется только к методу GET в запросах fetch.
• Кэширование применяется только к дереву React-компонентов, это означает:
  • Он применяется к запросам fetch в generateMetadata, generateStaticParams, макетах, страницах и других серверных компонентах.
  • Он не применяется к запросам fetch в обработчиках маршрутов, так как они не являются частью дерева React-компонентов.
• В случаях, когда fetch не подходит (например, некоторые клиенты баз данных, клиенты CMS или клиенты GraphQL), вы можете использовать функцию React cache для кэширования функций.

Срок действия

Кэш хранится в течение всего времени запроса сервера до завершения рендеринга дерева React-компонентов.

Перевалидация

Поскольку кэширование не делится между запросами сервера и применяется только во время рендеринга, нет необходимости в его перевалидации.

Отключение

Кэширование применяется только к методу GET в запросах fetch , другие методы, такие как POST и DELETE, не кэшируются. Это поведение по умолчанию является оптимизацией React, и мы не рекомендуем его отключать.

Для управления отдельными запросами вы можете использовать свойство signal из AbortController. Однако это не отключает запросы от кэширования, а скорее прерывает выполнение запросов.

const { signal } = new AbortController()
fetch(url, { signal })

Кэш данных

Next.js имеет встроенный кэш данных, который хранит результат извлечения данных при последующих серверных запросах и развертываниях. Это возможно, потому что Next.js расширяет родной fetch API, позволяя каждому запросу на сервере устанавливать свои собственные постоянные параметры кэширования.

Важно знать: В браузере параметр cache из fetch указывает, как запрос будет взаимодействовать с кэшем браузера HTTP, в Next.js параметр cache указывает, как серверный запрос будет взаимодействовать с кэшем данных сервера.

По умолчанию запросы данных, использующие fetch , кэшируются. Вы можете использовать параметры cache и next.revalidate функции fetch для настройки поведения кэширования.

Как работает кэш данных

• В первый раз, когда запрос fetch вызывается во время рендеринга, Next.js проверяет кэш данных на наличие кэшированного ответа.
• Если кэшированный ответ найден, он возвращается немедленно и кэшируется.
• Если кэшированный ответ не найден, запрос выполняется к источнику данных, результат хранится в кэше данных и кэшируется.
• Для некэшированных данных (например, { cache: 'no-store' }), результат всегда извлекается из источника данных и кэшируется.
• Независимо от того, кэшируются данные или нет, запросы всегда кэшируются, чтобы избежать дублирования запросов для одних и тех же данных во время цикла рендеринга React.

Отличия между кэшем данных и кэшированием запросов

Хотя оба механизма кэширования помогают повысить производительность за счет повторного использования кэшированных данных, кэш данных сохраняется между входящими запросами и развертываниями, тогда как кэширование запросов сохраняется только в течение жизни запроса.

С кэшированием запросов мы уменьшаем количество повторных запросов в одном цикле рендеринга, которые должны пересечь границу сети от сервера рендеринга до сервера кэша данных (например, CDN или Edge Network) или источника данных (например, базы данных или CMS). С кэшем данных мы уменьшаем количество запросов к нашему исходному источнику данных.

Срок действия

Кэш данных сохраняется между входящими запросами и развертываниями, если вы не перевалидируете или не отключите его.

Перевалидация

Кэшированные данные могут быть перевалидированы двумя способами:

• Перевалидация по времени: Перевалидировать данные после определенного периода времени и при выполнении нового запроса. Это полезно для данных, которые меняются редко, и свежесть не является критической.
• Перевалидация по требованию: Перевалидировать данные на основе события (например, отправки формы). Перевалидация по требованию может использовать подходы на основе тегов или путей для перевалидации групп данных одновременно. Это полезно, когда вы хотите отобразить последние данные как можно быстрее (например, когда контент из вашего headless CMS обновляется).

Перевалидация по времени

Для перевалидации данных через определенные интервалы времени вы можете использовать параметр next.revalidate функции fetch для установки срока действия кэша ресурса (в секундах).

// Revalidate at most every hour
fetch('https://...', { next: { revalidate: 3600 } })

В качестве альтернативы вы можете использовать параметры настройки сегментов для настройки всех fetch запросов в сегменте или в случаях, когда вы не можете использовать fetch.

Как работает перевалидация по времени

• В первый раз, когда выполняется запрос fetch с revalidate, данные будут получены из внешнего источника и сохранены в кэше данных.
• Любые запросы, которые вызываются в течение указанного периода времени (например, 60 секунд), вернут кэшированные данные.
• По истечении периода времени следующий запрос по-прежнему вернет кэшированные (теперь устаревшие) данные.
  • Next.js запустит перевалидацию данных в фоновом режиме.
  • После успешного извлечения данных Next.js обновит кэш данных свежими данными.
  • Если фоновая перевалидация завершится неудачно, предыдущие данные останутся неизменными.

Это аналогично поведению stale-while-revalidate.

Перевалидация по требованию

Данные могут быть перевалидированы по требованию по пути (revalidatePath) или по тегу кэша (revalidateTag).

Как работает перевалидация по требованию

• В первый раз, когда вызывается запрос fetch, данные будут извлечены из внешнего источника данных и сохранены в кэше данных.
• При срабатывании запроса на повторную валидацию по требованию соответствующие записи кэша будут удалены из кэша.
  • Это отличается от повторной валидации по времени, которая хранит устаревшие данные в кэше до тех пор, пока свежие данные не будут извлечены.
• В следующий раз при выполнении запроса он снова будет использоваться из кэша MISS, и данные будут извлечены из внешнего источника данных и сохранены в кэше данных.

Отключение

Для отдельных извлечений данных вы можете отключить кеширование, установив параметр cache в значение no-store. Это означает, что данные будут извлекаться всякий раз, когда fetch вызывается.

// Opt out of caching for an individual `fetch` request
fetch(`https://...`, { cache: 'no-store' })

Кроме того, вы также можете использовать параметры конфигурации сегмента маршрута параметры конфигурации сегмента маршрута, чтобы отключить кеширование для определенного сегмента маршрута. Это повлияет на все запросы данных в сегменте маршрута, включая сторонние библиотеки.

// Opt out of caching for all data requests in the route segment
export const dynamic = 'force-dynamic'

Примечание: Кэш данных в настоящее время доступен только на страницах/маршрутах, а не в middleware. Любые запросы, выполненные внутри middleware, по умолчанию не будут кешироваться.

Кэш данных Vercel

Если ваше приложение Next.js развернуто на Vercel, мы рекомендуем ознакомиться с документацией кэша данных Vercel для лучшего понимания функций, специфичных для Vercel.

Полный кэш маршрута

Связанные термины:

Вы можете встретить термины Автоматическая статическая оптимизация, Статическое создание сайта или Статическое отображение, используемые взаимозаменяемо для обозначения процесса отображения и кэширования маршрутов вашего приложения во время сборки.

Next.js автоматически отображает и кеширует маршруты во время сборки. Это оптимизация, которая позволяет предоставлять кэшированный маршрут вместо рендеринга на сервере для каждого запроса, что приводит к более быстрой загрузке страниц.

Чтобы понять, как работает Полный кэш маршрута, полезно взглянуть на то, как React обрабатывает рендеринг, и как Next.js кэширует результат:

1. Отображение React на сервере

На сервере Next.js использует API React для управления отображением. Работа по рендерингу разделена на части: по отдельным сегментам маршрутов и границам Suspense.

Каждая часть рендерится в два этапа:

1. React отображает Server Components в специальный формат данных, оптимизированный для потоковой передачи, называемый React Server Component Payload.
2. Next.js использует React Server Component Payload и JavaScript-инструкции Client Component для отображения HTML на сервере.

Это означает, что нам не нужно ждать, пока все отобразится, прежде чем кэшировать работу или отправлять ответ. Вместо этого мы можем передавать ответ по частям по мере завершения работы.

Что такое React Server Component Payload?

React Server Component Payload — это компактное двоичное представление дерева отрендеренных React Server Components. Он используется React на клиенте для обновления DOM браузера. React Server Component Payload содержит:

• Результат рендеринга Server Components
• Плацехолдеры для того, где должны быть отображены Client Components, и ссылки на их JavaScript-файлы
• Любые передаваемые от Server Component к Client Component параметры

Для получения дополнительной информации см. документацию по Server Components.

2. Кэширование Next.js на сервере (Полный кэш маршрута)

По умолчанию Next.js кэширует результат рендеринга (React Server Component Payload и HTML) маршрута на сервере. Это относится к статически отрендеренным маршрутам во время сборки или во время повторной валидации.

3. Гидратация и согласование React на клиенте

Во время запроса на клиенте:

1. HTML используется для немедленного отображения быстрого неинтерактивного предварительного просмотра Client и Server Components.
2. React Server Component Payload используется для согласования деревьев Client и отрендеренных Server Components и обновления DOM.
3. Инструкции JavaScript используются для гидратации Client Components и создания интерактивного приложения.

4. Кэширование Next.js на клиенте (Кэш маршрутизатора)

React Server Component Payload хранится в кэше маршрутизатора на стороне клиента — отдельном кэше в оперативной памяти, разделенном по отдельным сегментам маршрута. Этот кэш маршрутизатора используется для улучшения навигации, храня ранее посещенные маршруты и предварительно загружая будущие маршруты.

5. Последующие навигации

При последующих навигациях или предварительной загрузке Next.js проверит, хранится ли React Server Component Payload в кэше маршрутизатора. Если да, он пропустит отправку нового запроса на сервер.

Если сегменты маршрута отсутствуют в кэше, Next.js извлечет React Server Component Payload с сервера и заполнит кэш маршрутизатора на клиенте.

Статическое и динамическое отображение

Кэшируется ли маршрут во время сборки или нет, зависит от того, статически или динамически он отображается. Статические маршруты по умолчанию кешируются, а динамические маршруты отображаются во время запроса и не кешируются.

На этом рисунке показано различие между статическими и динамическими отрендеренными маршрутами с кэшированными и некэшированными данными:

Узнайте больше о статическом и динамическом рендеринге.

Продолжительность

По умолчанию Полный кэш маршрута является постоянным. Это означает, что выходные данные рендеринга кэшируются для всех запросов пользователей.

Недействительность

Существует два способа сделать Полный кэш маршрута недействительным:

• Повторная валидация данных: Повторная валидация кэша данных повлечет за собой аннулирование кэша маршрутизатора путем повторного рендеринга компонентов на сервере и кэширования новых выходных данных рендеринга.
• Переразвертывание: В отличие от кэша данных, который сохраняется между развертываниями, Полный кэш маршрута очищается при новых развертываниях.

Отключение

Вы можете отключить Полный кэш маршрута, или, другими словами, динамически отображать компоненты для каждого входящего запроса, выполнив следующие действия:

• Использование динамической функции Динамической функции: Это выведет маршрут из Полного кэша маршрута и динамически отобразит его при получении запроса. Кэш данных по-прежнему может использоваться.
• Использование параметров конфигурации сегмента маршрута dynamic = 'force-dynamic' или revalidate = 0: Это пропустит Полный кэш маршрута и кэш данных. Это означает, что компоненты будут отображаться и данные извлекаться при каждом входящем запросе на сервер. Кэш маршрутизатора по-прежнему будет применяться, поскольку это кэш на стороне клиента.
• Отключение кэша данных: Если у маршрута есть запрос fetch, который не кэшируется, это выведет маршрут из Полного кэша маршрута. Данные для конкретного запроса fetch будут извлекаться для каждого входящего запроса. Другие запросы fetch , которые не отключают кеширование, по-прежнему будут кэшироваться в кэше данных. Это позволяет использовать гибрид кэшированных и некэшированных данных.

Кэш маршрутизатора

Связанные термины:

Кэш маршрутизатора может упоминаться как Кэш на стороне клиента или Кэш предварительной загрузки. В то время как Кэш предварительной загрузки относится к предварительно загруженным сегментам маршрута, Кэш на стороне клиента относится ко всему кэшу маршрутизатора, который включает как посещенные, так и предварительно загруженные сегменты. Этот кэш конкретно относится к Next.js и Server Components и отличается от кэша браузера bfcache, хотя результат аналогичен.

Next.js имеет кэш на стороне клиента в оперативной памяти, который хранит React Server Component Payload, разделенный по отдельным сегментам маршрута, на протяжении всей сессии пользователя. Это называется Кэш маршрутизатора.

Как работает кэш маршрутизатора

По мере навигации пользователя между маршрутами Next.js кэширует посещенные сегменты маршрутов и предварительно загружает маршруты, по которым пользователь, скорее всего, будет перемещаться (на основе <Link> компонентов в поле просмотра).

Это приводит к улучшению навигации для пользователя:

• Мгновенная навигация назад/вперед, так как посещенные маршруты кэшированы, и быстрая навигация к новым маршрутам благодаря предварительной загрузке и частичному рендерингу.
• Отсутствие полной перезагрузки страницы между навигациями и сохранение состояния React и состояния браузера.

Разница между кэшем маршрутизатора и Полным кэшем маршрута:

Кэш маршрутизатора временно хранит React Server Component Payload в браузере на протяжении всей сессии пользователя, а Полный кэш маршрута постоянно хранит React Server Component Payload и HTML на сервере для множества запросов пользователей.

В то время как Полный кэш маршрута кеширует только статически отрендеренные маршруты, кэш маршрутизатора применяется как к статически, так и к динамически отрендеренным маршрутам.

Продолжительность

Данные хранятся в временной памяти браузера. Два фактора определяют, как долго сохраняется кэш маршрутизатора:

• Сессия: Кэш сохраняется при переходе между страницами. Однако он очищается при обновлении страницы.
• Автоматический период аннулирования: Кэш отдельного сегмента автоматически аннулируется после определенного времени. Продолжительность зависит от того, как ресурс был предварительно загружен:
  • Стандартная предварительная загрузка (prefetch={null} или не указано): 30 секунд
  • Полная предварительная загрузка: (prefetch={true} или router.prefetch): 5 минут

При обновлении страницы кешированные сегменты очищаются, а период автоматической проверки валидности затрагивает только отдельный сегмент с момента его предварительной загрузки.

Примечание: Экспериментальная поддержка настройки этих значений доступна начиная с версии v14.2.0-canary.53. Подробнее

Недействительность

Существует два способа сделать кеш маршрутизатора недействительным:

• В действии на сервере:
  • Перепроверка данных по запросу по пути с помощью (revalidatePath) или по тегу кеша с помощью (revalidateTag)
  • Использование cookies.set или cookies.delete делает кеш маршрутизатора недействительным, чтобы предотвратить устаревание маршрутов, использующих куки (например, аутентификация).
• Вызов router.refresh сделает кеш маршрутизатора недействительным и отправит новый запрос на сервер для текущего маршрута.

Исключение из учёта

Исключить кеш маршрутизатора из учёта невозможно. Однако, вы можете сделать его недействительным, вызвав router.refresh, revalidatePath или revalidateTag (см. выше). Это очистит кеш и отправит новый запрос на сервер, гарантируя отображение последних данных.

Вы также можете исключить предварительную загрузку, установив свойство prefetch компонента <Link> в значение false. Однако, сегменты маршрута по-прежнему будут временно храниться в течение 30 секунд, чтобы обеспечить мгновенную навигацию между вложенными сегментами, такими как панели вкладок, или навигация назад и вперёд. Посещённые маршруты всё равно будут кешироваться.

Взаимодействие с кешем

При настройке различных механизмов кеширования важно понимать, как они взаимодействуют друг с другом:

Кеш данных и полный кеш маршрута

• Перепроверка или исключение кеша данных приведёт к аннулированию полного кеша маршрута, так как выходной результат рендеринга зависит от данных.
• Аннулирование или исключение полного кеша маршрута не повлияет на кеш данных. Вы можете динамически рендерить маршрут, который содержит как кешированные, так и некешированные данные. Это полезно, когда большая часть страницы использует кешированные данные, но есть несколько компонентов, которые полагаются на данные, которые необходимо извлекать во время запроса. Вы можете динамически рендерить, не беспокоясь о влиянии на производительность повторного извлечения всех данных.

Кеш данных и кеш маршрутизатора на стороне клиента

• Перепроверка кеша данных в обработчике маршрута Обработчик маршрута не приведёт к немедленному аннулированию кеша маршрутизатора, так как обработчик маршрута не привязан к определённому маршруту. Это означает, что кеш маршрутизатора будет продолжать предоставлять предыдущую полезную нагрузку до перезагрузки или истечения срока автоматической проверки валидности.
• Для немедленного аннулирования кеша данных и кеша маршрутизатора используйте revalidatePath или revalidateTag в действии на сервере действие на сервере.

API

В следующей таблице представлен обзор того, как различные API Next.js влияют на кеширование:

<Link>

По умолчанию компонент <Link> автоматически предварительно загружает маршруты из полного кеша маршрута и добавляет полезную нагрузку React серверного компонента в кеш маршрутизатора.

Для отключения предварительной загрузки можно установить свойство prefetch в значение false. Но это не предотвратит кеширование маршрута постоянно, сегмент маршрута всё равно будет кешироваться на стороне клиента, когда пользователь посещает маршрут.

Подробнее о компоненте <Link>.

router.prefetch

Вариант prefetch хука useRouter может использоваться для ручного предварительного запроса маршрута. Это добавляет полезную нагрузку React серверного компонента в кеш маршрутизатора.

См. справку по API хука useRouter.

router.refresh

Вариант refresh хука useRouter может использоваться для ручного обновления маршрута. Это полностью очищает кеш маршрутизатора и отправляет новый запрос на сервер для текущего маршрута. refresh не затрагивает кеш данных или полный кеш маршрута.

Результат рендеринга будет согласован на клиенте с сохранением состояния React и состояния браузера.

См. справку по API хука useRouter.

fetch

Данные, возвращаемые fetch, автоматически кешируются в кеше данных.

// Cached by default. `force-cache` is the default option and can be omitted.
fetch(`https://...`, { cache: 'force-cache' })

См. fetch Справочник по API для получения дополнительной информации.

fetch options.cache

Вы можете исключить отдельные запросы fetch данных из кеширования, установив опцию cache в значение no-store.

// Opt out of caching
fetch(`https://...`, { cache: 'no-store' })

Поскольку выходной результат рендеринга зависит от данных, использование cache: 'no-store' также пропустит полный кеш маршрута для маршрута, где используется запрос fetch. То есть, маршрут будет динамически рендериться при каждом запросе, но вы по-прежнему можете иметь другие кешированные запросы данных в этом же маршруте.

См. fetch Справочник по API для получения дополнительной информации.

fetch options.next.revalidate

Вы можете использовать опцию next.revalidate запроса fetch для установки периода перепроверки (в секундах) для отдельного запроса fetch. Это перепроверит кеш данных, который, в свою очередь, перепроверит полный кеш маршрута. Будут получены свежие данные, и компоненты будут повторно рендериться на сервере.

// Revalidate at most after 1 hour
fetch(`https://...`, { next: { revalidate: 3600 } })

См. fetch Справочник по API для получения дополнительной информации.

fetch options.next.tags и revalidateTag

Next.js имеет систему тегирования кеша для тонкой настройки кеширования данных и перепроверки.

1. При использовании fetch или unstable_cache у вас есть возможность пометить записи кеша одним или несколькими тегами.
2. Затем, вы можете вызвать revalidateTag для удаления записей кеша, связанных с этим тегом.

Например, вы можете установить тег при извлечении данных:

// Cache data with a tag
fetch(`https://...`, { next: { tags: ['a', 'b', 'c'] } })

Затем, вызовите revalidateTag с тегом для очистки записи кеша:

// Revalidate entries with a specific tag
revalidateTag('a')

Существуют два места, где вы можете использовать revalidateTag, в зависимости от того, чего вы пытаетесь достичь:

1. Обработчики маршрутов - для перепроверки данных в ответ на событие третьей стороны (например, вебхук). Это не приведёт к немедленному аннулированию кеша маршрутизатора, так как обработчик маршрута не привязан к определённому маршруту.
2. Действия на сервере - для перепроверки данных после действия пользователя (например, отправки формы). Это аннулирует кеш маршрутизатора для соответствующего маршрута.

revalidatePath

revalidatePath позволяет вручную перепроверить данные и перерендерить сегменты маршрута ниже определённого пути в одной операции. Вызов метода revalidatePath перепроверяет кеш данных, который, в свою очередь, аннулирует полный кеш маршрута.

revalidatePath('/')

Существуют два места, где вы можете использовать revalidatePath, в зависимости от того, чего вы пытаетесь достичь:

1. Обработчики маршрутов - для повторной валидации данных в ответ на событие от третьей стороны (например, webhook).
2. Действия сервера - для повторной валидации данных после взаимодействия пользователя (например, отправки формы, нажатия кнопки).

Дополнительную информацию см. в revalidatePath справке по API.

revalidatePath против router.refresh:

Вызов router.refresh очистит кэш маршрутизатора и повторно отобразит сегменты маршрутов на сервере без аннулирования кэша данных или полного кэша маршрутов.

Разница в том, что revalidatePath очищает кэш данных и полный кэш маршрутов, тогда как router.refresh() не изменяет кэш данных и полный кэш маршрутов, так как это API клиентской стороны.

Динамические функции

Динамические функции, такие как cookies и headers, и свойство searchParams в страницах зависят от информации о входящем запросе во время выполнения. Их использование исключит маршрут из полного кэша маршрутов, другими словами, маршрут будет динамически отображаться.

Куки

Использование cookies.set или cookies.delete в действии сервера аннулирует кэш маршрутизатора, чтобы предотвратить устаревание маршрутов, использующих куки (например, для отражения изменений в аутентификации).

См. cookies справку по API.

Параметры конфигурации сегмента

Параметры конфигурации сегмента маршрута можно использовать для переопределения значений по умолчанию сегмента маршрута или в тех случаях, когда невозможно использовать API fetch (например, клиент базы данных или библиотеки третьей стороны).

Следующие параметры конфигурации сегмента маршрута исключат сегмент из кэша данных и полного кэша маршрутов:

• const dynamic = 'force-dynamic'
• const revalidate = 0

См. документацию Параметры конфигурации сегмента маршрута для получения дополнительной информации.

generateStaticParams

Для динамических сегментов (например, app/blog/[slug]/page.js), пути, предоставляемые generateStaticParams, кэшируются в полном кэше маршрутов во время сборки. Во время обработки запроса Next.js также будет кэшировать пути, которые не были известны на этапе сборки, при первом их посещении.

Вы можете отключить кэширование при обработке запроса, используя параметр export const dynamicParams = false в сегменте маршрута. При использовании этого параметра конфигурации будут обрабатываться только пути, предоставленные generateStaticParams, а другие маршруты будут возвращать 404 или совпадать (в случае маршрутов с подстановочными символами).

См. generateStaticParams справку по API.

Функция кэширования React

Функция React cache позволяет запоминать возвращаемое значение функции, позволяя вызывать одну и ту же функцию несколько раз, выполняя ее только один раз.

Поскольку запросы fetch автоматически запоминаются, вам не нужно заключать их в функцию кэширования React cache. Однако вы можете использовать cache для ручного запоминания запросов данных в тех случаях, когда API fetch не подходит. Например, для некоторых клиентов баз данных, клиентов CMS или клиентов GraphQL.

import { cache } from 'react'
import db from '@/lib/db'
 
export const getItem = cache(async (id: string) => {
  const item = await db.item.findUnique({ id })
  return item
})