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

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

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

Обзор

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

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

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

Мемоизация запросов

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

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

async function getItem() {
  // Функция `fetch` автоматически мемоизируется, и результат
  // кэшируется
  const res = await fetch('https://.../item/1')
  return res.json()
}

// Эта функция вызывается дважды, но выполняется только первый раз
const item = await getItem() // cache MISS

// Второй вызов может быть в любом месте вашего маршрута
const item = await getItem() // cache HIT

async function getItem() {
  // Функция `fetch` автоматически мемоизируется, и результат
  // кэшируется
  const res = await fetch('https://.../item/1')
  return res.json()
}

// Эта функция вызывается дважды, но выполняется только первый раз
const item = await getItem() // cache MISS

// Второй вызов может быть в любом месте вашего маршрута
const item = await getItem() // cache HIT

Как работает мемоизация запросов

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

Полезно знать:

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

Длительность

Кэш существует в течение времени жизни серверного запроса, пока дерево React-компонентов не завершит рендеринг.

Инвалидация

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

Отключение

Чтобы отключить мемоизацию в запросах fetch, вы можете передать signal от AbortController в запрос.

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

Кэш данных

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

Полезно знать: В браузере опция 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, чтобы установить время жизни ресурса в кэше (в секундах).

// Инвалидировать не чаще чем раз в час
fetch('https://...', { next: { revalidate: 3600 } })

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

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

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

Это похоже на поведение stale-while-revalidate.

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

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

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

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

Отключение

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

// Отключить кэширование для отдельного запроса `fetch`
fetch(`https://...`, { cache: 'no-store' })

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

// Отключить кэширование для всех запросов данных в сегменте маршрута
export const dynamic = 'force-dynamic'

Кэш данных Vercel

Если ваше приложение Next.js развёрнуто на Vercel, рекомендуем прочитать документацию Vercel Data Cache для лучшего понимания особенностей 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 Components, чтобы отрендерить 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 Components Payload используется для согласования деревьев Client и отрендеренных Server Components и обновления DOM.
3. Инструкции JavaScript используются для гидратации Client Components и делают приложение интерактивным.

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

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

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

При последующих переходах или во время предварительной загрузки (prefetching) Next.js проверит, хранится ли полезная нагрузка React Server Components в кеше маршрутизатора (Router Cache). Если да, то новый запрос к серверу отправляться не будет.

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

Статический и динамический рендеринг

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

На этой диаграмме показана разница между статически и динамически рендерящимися маршрутами с кешированными и некешированными данными:

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

Длительность

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

Инвалидация

Существует два способа инвалидировать Full Route Cache:

• Ревалидация данных: Ревалидация Data Cache приведёт к инвалидации Router Cache путём повторного рендеринга компонентов на сервере и кеширования нового результата.
• Переразвертывание: В отличие от Data Cache, который сохраняется между развертываниями, Full Route Cache очищается при новых развертываниях.

Отказ от кеширования

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

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

Router Cache

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

Router Cache может упоминаться как Клиентский кеш (Client-side Cache) или Кеш предварительной загрузки (Prefetch Cache). В то время как Prefetch Cache относится к предварительно загруженным сегментам маршрутов, Client-side Cache относится ко всему Router Cache, включая как посещённые, так и предварительно загруженные сегменты. Этот кеш специфичен для Next.js и Server Components и отличается от bfcache браузера, хотя и даёт схожий результат.

Next.js имеет клиентский кеш в памяти, который хранит полезную нагрузку React Server Components, разделённую по отдельным сегментам маршрутов, на протяжении сеанса пользователя. Это называется Router Cache.

Как работает Router Cache

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

Это улучшает пользовательский опыт навигации:

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

Разница между Router Cache и Full Route Cache:

Router Cache временно хранит полезную нагрузку React Server Components в браузере на протяжении сеанса пользователя, тогда как Full Route Cache постоянно хранит полезную нагрузку React Server Components и HTML на сервере между запросами разных пользователей.

В то время как Full Route Cache кеширует только статически рендерящиеся маршруты, Router Cache применяется как к статическим, так и к динамическим маршрутам.

Длительность

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

• Сеанс: Кеш сохраняется между переходами. Однако он очищается при обновлении страницы.
• Период автоматической инвалидации: Кеш отдельного сегмента автоматически инвалидируется через определённое время. Длительность зависит от того, является ли маршрут статическим или динамическим:
  • Динамический рендеринг: 30 секунд
  • Статический рендеринг: 5 минут

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

Добавив prefetch={true} или вызвав router.prefetch для динамически рендерящегося маршрута, вы можете включить кеширование на 5 минут.

Инвалидация

Существует два способа инвалидировать Router Cache:

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

Отказ от кеширования

Отказаться от Router Cache невозможно.

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

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

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

Data Cache и Full Route Cache

• Ревалидация или отказ от Data Cache приведёт к инвалидации Full Route Cache, так как результат рендеринга зависит от данных.
• Инвалидация или отказ от Full Route Cache не влияет на Data Cache. Вы можете динамически рендерить маршрут, который содержит как кешированные, так и некешированные данные. Это полезно, когда большая часть страницы использует кешированные данные, но у вас есть несколько компонентов, зависящих от данных, которые нужно загружать во время запроса. Вы можете динамически рендерить без опасений о влиянии на производительность из-за повторной загрузки всех данных.

Data Cache и клиентский Router Cache

• Ревалидация Data Cache в Route Handler не приведёт к немедленной инвалидации Router Cache, так как Route Handler не привязан к конкретному маршруту. Это означает, что Router Cache продолжит обслуживать предыдущую полезную нагрузку до полного обновления страницы или истечения периода автоматической инвалидации.
• Для немедленной инвалидации Data Cache и Router Cache вы можете использовать revalidatePath или revalidateTag в Server Action.

API

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

<Link>

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

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

Узнайте больше о компоненте <Link>.

router.prefetch

Опция prefetch хука useRouter может использоваться для ручной предварительной загрузки маршрута. Это добавляет полезную нагрузку React Server Components в Router Cache.

См. документацию хука useRouter.

router.refresh

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

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

См. документацию хука useRouter.

fetch

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

// Кешируется по умолчанию. `force-cache` — опция по умолчанию и может быть опущена.
fetch(`https://...`, { cache: 'force-cache' })

См. документацию API fetch для получения дополнительных опций.

fetch options.cache

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

// Отказ от кеширования
fetch(`https://...`, { cache: 'no-store' })

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

См. документацию API fetch для получения дополнительных опций.

fetch options.next.revalidate

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

// Ревалидировать не чаще чем раз в час
fetch(`https://...`, { next: { revalidate: 3600 } })

См. документацию API fetch для получения дополнительных опций.

fetch options.next.tags и revalidateTag

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

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

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

// Кешировать данные с тегом
fetch(`https://...`, { next: { tags: ['a', 'b', 'c'] } })

Затем вызовите revalidateTag с тегом, чтобы очистить запись кеша:

// Ревалидировать записи с определённым тегом
revalidateTag('a')

Есть два места, где вы можете использовать revalidateTag, в зависимости от того, чего вы хотите достичь:

1. Route Handlers — для ревалидации данных в ответ на событие от третьей стороны (например, вебхук). Это не приведёт к немедленной инвалидации Router Cache, так как Route Handler не привязан к конкретному маршруту.
2. Server Actions — для ревалидации данных после действия пользователя (например, отправки формы). Это инвалидирует Router Cache для связанного маршрута.

revalidatePath

revalidatePath позволяет вручную обновить данные и перерендерить сегменты маршрута ниже указанного пути в одной операции. Вызов revalidatePath обновляет Кеш данных (Data Cache), что, в свою очередь, инвалидирует Полный кеш маршрута (Full Route Cache).

revalidatePath('/')

Есть два места, где можно использовать revalidatePath, в зависимости от цели:

1. Обработчики маршрутов (Route Handlers) — для обновления данных в ответ на внешнее событие (например, вебхук).
2. Серверные действия (Server Actions) — для обновления данных после взаимодействия пользователя (например, отправка формы, нажатие кнопки).

Подробнее см. в справочнике API revalidatePath.

Разница между revalidatePath и router.refresh:

Вызов router.refresh очищает кеш маршрутизатора (Router cache) и перерендеривает сегменты маршрута на сервере без инвалидации Кеша данных или Полного кеша маршрута.

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

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

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

cookies

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

Подробнее см. в справочнике API cookies.

Настройки сегментов маршрута

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

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

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

Другие варианты см. в документации Route Segment Config.

generateStaticParams

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

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

Подробнее см. в справочнике API generateStaticParams.

Функция cache в React

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

Поскольку запросы fetch автоматически мемоизируются, оборачивать их в 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
})

import { cache } from 'react'
import db from '@/lib/db'

export const getItem = cache(async (id) => {
  const item = await db.item.findUnique({ id })
  return item
})

unstable_cache

unstable_cache — это экспериментальный API для добавления значений в Кеш данных (Data Cache), когда API fetch не подходит. Например, при работе с клиентами баз данных, CMS или GraphQL.

import { unstable_cache } from 'next/cache'

export default async function Page() {
  const cachedData = await unstable_cache(
    async () => {
      const data = await db.query('...')
      return data
    },
    ['cache-key'],
    {
      tags: ['a', 'b', 'c'],
      revalidate: 10,
    }
  )()
}

Предупреждение: Этот API находится в разработке, и мы не рекомендуем использовать его в продакшене. Он приведён здесь, чтобы показать направление развития Кеша данных.