Кэширование в Next.js
Next.js улучшает производительность вашего приложения и снижает затраты за счёт кэширования результатов рендеринга и запросов данных. На этой странице подробно рассматриваются механизмы кэширования в Next.js, API для их настройки и их взаимодействие между собой.
Полезно знать: Эта страница помогает понять внутреннюю работу Next.js, но не является обязательной для продуктивной работы с фреймворком. Большинство эвристик кэширования Next.js определяются использованием API и имеют настройки по умолчанию для оптимальной производительности с нулевой или минимальной конфигурацией.
Обзор
Вот краткий обзор различных механизмов кэширования и их назначения:
Механизм | Что кэшируется | Где | Назначение | Длительность |
---|---|---|---|---|
Мемоизация запросов | Возвращаемые значения функций | Сервер | Повторное использование данных в дереве React-компонентов | В течение жизненного цикла запроса |
Кэш данных | Данные | Сервер | Хранение данных между запросами пользователей и деплоями | Постоянно (можно инвалидировать) |
Полный кэш маршрута | HTML и RSC-полезная нагрузка | Сервер | Снижение затрат на рендеринг и повышение производительности | Постоянно (можно инвалидировать) |
Кэш роутера | RSC-полезная нагрузка | Клиент | Снижение серверных запросов при навигации | Сессия пользователя или по времени |
По умолчанию 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-компонентов.
Инвалидация
Поскольку мемоизация не распространяется между серверными запросами и применяется только во время рендеринга, нет необходимости её инвалидировать.
Отказ от использования
Мемоизация применяется только к методу GET
в запросах fetch
, другие методы, такие как POST
и DELETE
, не мемоизируются. Это поведение по умолчанию является оптимизацией React, и мы не рекомендуем отказываться от него.
Для управления отдельными запросами вы можете использовать свойство 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'
Примечание: Кэш данных в настоящее время доступен только на страницах/маршрутах, а не в middleware. Все запросы
fetch
внутри middleware по умолчанию не кэшируются.
Vercel Data Cache
Если ваше приложение Next.js развёрнуто на Vercel, мы рекомендуем ознакомиться с документацией Vercel Data Cache для лучшего понимания особенностей, специфичных для Vercel.
Полный кэш маршрута
Связанные термины:
Вы можете встретить термины Автоматическая статическая оптимизация, Статическая генерация сайта или Статический рендеринг, используемые взаимозаменяемо для обозначения процесса рендеринга и кэширования маршрутов вашего приложения во время сборки.
Next.js автоматически рендерит и кэширует маршруты во время сборки. Это оптимизация, которая позволяет обслуживать кэшированный маршрут вместо рендеринга на сервере для каждого запроса, что приводит к более быстрой загрузке страниц.
Чтобы понять, как работает полный кэш маршрута, полезно посмотреть, как React обрабатывает рендеринг и как Next.js кэширует результат:
1. Рендеринг React на сервере
На сервере Next.js использует API React для организации рендеринга. Работа по рендерингу разделяется на части: по отдельным сегментам маршрута и границам Suspense.
Каждая часть рендерится в два этапа:
- React рендерит Server Components в специальный формат данных, оптимизированный для потоковой передачи, называемый React Server Component Payload.
- 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. Гидратация (Hydration) и согласование (Reconciliation) React на клиенте
Во время запроса на клиенте происходит следующее:
- HTML используется для мгновенного отображения быстрого неинтерактивного предварительного просмотра клиентских и серверных компонентов.
- Полезная нагрузка React Server Components используется для согласования деревьев клиентских и отрендеренных серверных компонентов и обновления DOM.
- JavaScript-инструкции используются для гидратации клиентских компонентов и обеспечения интерактивности приложения.
4. Кэширование Next.js на клиенте (Кэш маршрутизатора)
Полезная нагрузка React Server Component хранится в клиентском Кэше маршрутизатора — отдельном кэше в памяти, разделенном по отдельным сегментам маршрута. Этот кэш используется для улучшения навигации, сохраняя ранее посещенные маршруты и предварительно загружая будущие.
5. Последующие переходы
При последующих переходах или предварительной загрузке Next.js проверит, хранится ли полезная нагрузка React Server Components в Кэше маршрутизатора. Если да, новый запрос на сервер отправляться не будет.
Если сегменты маршрута отсутствуют в кэше, Next.js загрузит полезную нагрузку React Server Components с сервера и заполнит Кэш маршрутизатора на клиенте.
Статический и динамический рендеринг
Будет ли маршрут закэширован во время сборки, зависит от того, является ли он статическим или динамическим. Статические маршруты кэшируются по умолчанию, тогда как динамические рендерятся во время запроса и не кэшируются.
На этой диаграмме показана разница между статическими и динамическими маршрутами с кэшированными и некэшированными данными:

Подробнее о статическом и динамическом рендеринге.
Длительность хранения
По умолчанию Full Route Cache является постоянным. Это означает, что результат рендеринга кэшируется между запросами пользователей.
Инвалидация
Есть два способа инвалидировать Full Route Cache:
- Ревалидация данных: Ревалидация Data Cache приведет к инвалидации Кэша маршрутизатора путем повторного рендеринга компонентов на сервере и кэширования нового результата.
- Передеплой: В отличие от Data Cache, который сохраняется между деплоями, Full Route Cache очищается при новых деплоях.
Отказ от кэширования
Вы можете отказаться от Full Route Cache (то есть динамически рендерить компоненты для каждого входящего запроса) следующими способами:
- Использование динамической функции: Это исключит маршрут из Full Route Cache и будет рендерить его динамически во время запроса. Data Cache при этом все еще можно использовать.
- Использование опций
dynamic = 'force-dynamic'
илиrevalidate = 0
в конфигурации сегмента маршрута: Это пропустит Full Route Cache и Data Cache. Компоненты будут рендериться, а данные загружаться при каждом запросе. Кэш маршрутизатора все равно будет применяться, так как это клиентский кэш. - Отказ от Data Cache: Если в маршруте есть
fetch
-запрос без кэширования, это исключит маршрут из Full Route Cache. Данные для такого запроса будут загружаться при каждом запросе. Другиеfetch
-запросы с кэшированием останутся в Data Cache. Это позволяет комбинировать кэшированные и некэшированные данные.
Кэш маршрутизатора (Router Cache)
Связанные термины:
Кэш маршрутизатора может называться Клиентским кэшем или Кэшем предварительной загрузки (Prefetch Cache). Prefetch Cache относится к предзагруженным сегментам маршрута, а Client-side Cache — ко всему кэшу маршрутизатора, включая посещенные и предзагруженные сегменты. Этот кэш специфичен для Next.js и Server Components и отличается от bfcache браузера, хотя дает схожий результат.
Next.js имеет клиентский кэш в памяти, который хранит полезную нагрузку React Server Component, разделенную по сегментам маршрута, на протяжении сеанса пользователя. Это называется Кэшем маршрутизатора.
Как работает Кэш маршрутизатора

Когда пользователь переходит между маршрутами, Next.js кэширует посещенные сегменты и предзагружает маршруты, по которым пользователь может перейти (на основе компонентов <Link>
в области просмотра).
Это улучшает навигацию для пользователя:
- Мгновенный переход назад/вперед, так как посещенные маршруты закэшированы, и быстрая навигация на новые маршруты благодаря предзагрузке и частичному рендерингу.
- Нет полной перезагрузки страницы между переходами, сохраняются состояние React и состояние браузера.
Разница между Кэшем маршрутизатора и Full Route Cache:
Кэш маршрутизатора временно хранит полезную нагрузку React Server Component в браузере на протяжении сеанса пользователя, тогда как Full Route Cache постоянно хранит полезную нагрузку и HTML на сервере между запросами пользователей.
Full Route Cache кэширует только статически рендеренные маршруты, а Кэш маршрутизатора применяется и к статическим, и к динамическим маршрутам.
Длительность хранения
Кэш хранится во временной памяти браузера. Два фактора определяют, как долго он сохраняется:
- Сеанс: Кэш сохраняется между переходами, но очищается при обновлении страницы.
- Период автоматической инвалидации: Кэш для лэйаутов и состояний загрузки автоматически инвалидируется через определенное время. Длительность зависит от того, как ресурс был предзагружен, и был ли он статически сгенерирован:
- Стандартная предзагрузка (
prefetch={null}
или не указана): не кэшируется для динамических страниц, 5 минут для статических. - Полная предзагрузка (
prefetch={true}
илиrouter.prefetch
): 5 минут для статических и динамических страниц.
- Стандартная предзагрузка (
Обновление страницы очищает все закэшированные сегменты, тогда как автоматическая инвалидация влияет только на отдельные сегменты с момента их предзагрузки.
Полезно знать: Экспериментальная опция
staleTimes
позволяет настроить время автоматической инвалидации.
Инвалидация
Есть два способа инвалидировать Кэш маршрутизатора:
- В Server Action:
- Ревалидация данных по пути с помощью (
revalidatePath
) или по тегу кэша с помощью (revalidateTag
) - Использование
cookies.set
илиcookies.delete
инвалидирует Кэш маршрутизатора, чтобы маршруты с куками (например, аутентификацией) не устаревали.
- Ревалидация данных по пути с помощью (
- Вызов
router.refresh
инвалидирует Кэш маршрутизатора и делает новый запрос к серверу для текущего маршрута.
Отказ от кэширования
Отказаться от Кэша маршрутизатора невозможно. Однако его можно инвалидировать с помощью router.refresh
, revalidatePath
или revalidateTag
(см. выше). Это очистит кэш и загрузит свежие данные с сервера.
Также можно отказаться от предзагрузки, установив проп prefetch
компонента <Link>
в false
. Однако сегменты маршрута временно сохранятся на 30 секунд для мгновенной навигации между вложенными сегментами (например, табами) или переходами назад/вперед. Посещенные маршруты все равно будут кэшироваться.
Взаимодействие кэшей
При настройке разных механизмов кэширования важно понимать их взаимодействие:
Data Cache и Full Route Cache
- Ревалидация или отказ от Data Cache инвалидирует Full Route Cache, так как результат рендеринга зависит от данных.
- Инвалидация или отказ от Full Route Cache не влияет на Data Cache. Можно динамически рендерить маршрут с кэшированными и некэшированными данными. Это полезно, когда большая часть страницы использует кэшированные данные, но некоторые компоненты требуют данных, загружаемых во время запроса.
Data Cache и клиентский Кэш маршрутизатора
- Ревалидация Data Cache в Route Handler не инвалидирует сразу Кэш маршрутизатора, так как Route Handler не привязан к конкретному маршруту. Кэш маршрутизатора будет обслуживать старые данные до принудительного обновления или истечения периода инвалидации.
- Для немедленной инвалидации Data Cache и Кэша маршрутизатора используйте
revalidatePath
илиrevalidateTag
в Server Action.
API
В таблице ниже приведен обзор влияния API Next.js на кэширование:
API | Кэш маршрутизатора | Full Route Cache | Data Cache | React Cache |
---|---|---|---|---|
<Link prefetch> | Кэширует | |||
router.prefetch | Кэширует | |||
router.refresh | Инвалидирует | |||
fetch | Кэширует | Кэширует | ||
fetch options.cache | Кэширует или пропускает | |||
fetch options.next.revalidate | Инвалидирует | Инвалидирует | ||
fetch options.next.tags | Кэширует | Кэширует | ||
revalidateTag | Инвалидирует (Server Action) | Инвалидирует | Инвалидирует | |
revalidatePath | Инвалидирует (Server Action) | Инвалидирует | Инвалидирует | |
const revalidate | Инвалидирует или пропускает | Инвалидирует или пропускает | ||
const dynamic | Кэширует или пропускает | Кэширует или пропускает | ||
cookies | Инвалидирует (Server Action) | Пропускает | ||
headers , searchParams | Пропускает | |||
generateStaticParams | Кэширует | |||
React.cache | Кэширует | |||
unstable_cache |
<Link>
По умолчанию компонент <Link>
автоматически предзагружает маршруты из Full Route Cache и добавляет полезную нагрузку React Server Component в Кэш маршрутизатора.
Чтобы отключить предзагрузку, установите проп prefetch
в false
. Но это не отключит кэш полностью — сегмент маршрута все равно закэшируется на клиенте при посещении.
Подробнее о компоненте <Link>
.
router.prefetch
Опция prefetch
хука useRouter
позволяет вручную предзагрузить маршрут. Это добавит полезную нагрузку React Server Component в Кэш маршрутизатора.
См. документацию хука useRouter
.
router.refresh
Опция refresh
хука useRouter
позволяет вручную обновить маршрут. Это полностью очищает Кэш маршрутизатора и делает новый запрос к серверу. refresh
не влияет на Data Cache и Full Route Cache.
Результат рендеринга будет согласован на клиенте с сохранением состояния React и браузера.
См. документацию хука useRouter
.
fetch
Данные, возвращаемые fetch
, автоматически кэшируются в Data Cache.
// Кэшируется по умолчанию. `force-cache` можно опустить.
fetch(`https://...`, { cache: 'force-cache' })
См. документацию fetch
для дополнительных опций.
fetch options.cache
Можно исключить отдельные fetch
-запросы из кэширования, установив опцию cache
в no-store
:
// Исключить из кэширования
fetch(`https://...`, { cache: 'no-store' })
Так как результат рендеринга зависит от данных, cache: 'no-store'
также исключит маршрут из Full Route Cache. Маршрут будет рендериться динамически при каждом запросе, но другие кэшированные запросы в том же маршруте останутся.
См. документацию fetch
для дополнительных опций.
fetch options.next.revalidate
Опция next.revalidate
в fetch
позволяет установить период ревалидации (в секундах) для отдельного запроса. Это ревалидирует Data Cache, что, в свою очередь, ревалидирует Full Route Cache. Будут загружены свежие данные, и компоненты перерендерятся на сервере.
// Ревалидировать не чаще чем раз в час
fetch(`https://...`, { next: { revalidate: 3600 } })
См. документацию fetch
для дополнительных опций.
fetch options.next.tags
и revalidateTag
Next.js имеет систему тегирования кеша для детализированного кэширования и ревалидации данных.
- При использовании
fetch
илиunstable_cache
вы можете пометить записи кеша одним или несколькими тегами. - Затем вы можете вызвать
revalidateTag
, чтобы очистить записи кеша, связанные с этим тегом.
Например, вы можете установить тег при получении данных:
// Кэширование данных с тегом
fetch(`https://...`, { next: { tags: ['a', 'b', 'c'] } })
Затем вызовите revalidateTag
с тегом, чтобы очистить запись кеша:
// Ревалидация записей с определенным тегом
revalidateTag('a')
Есть два места, где можно использовать revalidateTag
, в зависимости от того, чего вы хотите достичь:
- Обработчики маршрутов (Route Handlers) — для ревалидации данных в ответ на событие от стороннего сервиса (например, вебхук). Это не приведет к немедленной инвалидации кеша маршрутизатора, так как обработчик маршрута не привязан к конкретному маршруту.
- Серверные действия (Server Actions) — для ревалидации данных после действия пользователя (например, отправки формы). Это приведет к инвалидации кеша маршрутизатора для связанного маршрута.
revalidatePath
revalidatePath
позволяет вручную ревалидировать данные и перерендерить сегменты маршрута ниже указанного пути в одной операции. Вызов метода revalidatePath
ревалидирует кеш данных, что, в свою очередь, инвалидирует полный кеш маршрута.
revalidatePath('/')
Есть два места, где можно использовать revalidatePath
, в зависимости от того, чего вы хотите достичь:
- Обработчики маршрутов (Route Handlers) — для ревалидации данных в ответ на событие от стороннего сервиса (например, вебхук).
- Серверные действия (Server Actions) — для ревалидации данных после взаимодействия пользователя (например, отправки формы, нажатия кнопки).
Подробнее см. в справочнике API revalidatePath
.
revalidatePath
vs.router.refresh
:Вызов
router.refresh
очистит кеш маршрутизатора и перерендерит сегменты маршрута на сервере без инвалидации кеша данных или полного кеша маршрута.Разница в том, что
revalidatePath
очищает кеш данных и полный кеш маршрута, тогда какrouter.refresh()
не изменяет кеш данных и полный кеш маршрута, так как это клиентский API.
Динамические функции
Динамические функции, такие как cookies
и headers
, а также проп searchParams
в страницах (Pages) зависят от информации входящего запроса во время выполнения. Их использование исключит маршрут из полного кеша маршрута, другими словами, маршрут будет рендериться динамически.
cookies
Использование cookies.set
или cookies.delete
в серверном действии инвалидирует кеш маршрутизатора, чтобы предотвратить устаревание маршрутов, использующих куки (например, для отражения изменений аутентификации).
Подробнее см. в справочнике API cookies
.
Опции конфигурации сегментов
Опции конфигурации сегментов маршрута (Route Segment Config) могут использоваться для переопределения значений по умолчанию или когда вы не можете использовать API fetch
(например, клиент базы данных или сторонние библиотеки).
Следующие опции конфигурации сегментов исключат маршрут из кеша данных и полного кеша маршрута:
const dynamic = 'force-dynamic'
const revalidate = 0
Другие опции см. в документации Route Segment Config.
generateStaticParams
Для динамических сегментов (например, app/blog/[slug]/page.js
) пути, предоставленные generateStaticParams
, кэшируются в полном кеше маршрута во время сборки. Во время запроса Next.js также кэширует пути, которые не были известны во время сборки, при первом посещении.
Вы можете отключить кэширование во время запроса, используя опцию export const dynamicParams = false
в сегменте маршрута. При использовании этой опции будут обслуживаться только пути, предоставленные generateStaticParams
, а другие маршруты вернут 404 или будут сопоставлены (в случае catch-all сегментов).
Подробнее см. в справочнике API generateStaticParams
.
Функция React cache
Функция 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
})
import { cache } from 'react'
import db from '@/lib/db'
export const getItem = cache(async (id) => {
const item = await db.item.findUnique({ id })
return item
})