Четыре кеша Next.js — и почему ваши данные не обновляются

Четыре слоя: от самого внутреннего к ближайшему к пользователю

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

Request Memoization (мемоизация запросов) — это React, а не инфраструктура: одинаковые вызовы fetch (тот же URL, те же опции, GET) в рамках одного серверного прохода рендера выполняются один раз; остальные получают мемоизированный результат. Срок жизни: один запрос — таблица мемоизации умирает вместе с окончанием рендера. Поэтому layout и страница могут оба вызвать getUser() без двойного похода в базу, и поэтому пропсы из layout в page не протаскивают. Мемоизация дедуплицирует только внутри одного рендера; второму запросу она не отдаёт ничего. Для не-fetch работы (прямой запрос в БД) ту же пер-запросную мемоизацию даёт React.cache().

Data Cache — серверное хранилище ответов fetch, с ключом URL плюс опции. Его определяющее — и самое неожиданное — свойство: он персистентен между входящими запросами и между деплоями. Выкат нового кода его не очищает; пятничный баг с ценой живёт именно здесь. Управление — на каждый fetch: next: { revalidate: 3600 } для протухания по времени, next: { tags: ['products'] } для точечной очистки через revalidateTag, cache: 'no-store' — полный обход. В Next 14 и раньше ответы fetch кешировались здесь по умолчанию (force-cache); в Next 15 умолчание перевернулось на «не кешировать» — об этом ниже.

Full Route Cache — отрендеренный результат статически рендеримых маршрутов: RSC-payload плюс HTML, произведённые на этапе сборки или в фоне после ревалидации. Именно он позволяет статическому маршруту отвечать за единицы миллисекунд, не выполняя ваши компоненты. Область: сервер; срок жизни: до ревалидации, и, в отличие от Data Cache, он сбрасывается каждым деплоем. Маршруты, использующие динамические API — cookies(), headers(), чтение searchParams в странице или dynamic = 'force-dynamic', — выходят из него целиком и рендерятся на каждый запрос.

Router Cache живёт в памяти браузера: он хранит RSC-payload посещённых сегментов на время сессии, поэтому навигация назад/вперёд мгновенна, а префетченные ссылки открываются без похода на сервер. Это единственный клиентский слой — и единственный, который ваш сервер не может сбросить напрямую: он очищается жёсткой перезагрузкой, router.refresh() или когда серверный экшен вызывает revalidatePath/revalidateTag либо ставит cookie.

// Один fetch, три решения о кешировании:
const res = await fetch('https://cms.example.com/api/products/42', {
  next: {
    revalidate: 3600,        // Data Cache: протухает через 1ч, обновляется в фоне
    tags: ['products', 'product-42'], // Data Cache: можно сбросить по требованию
  },
});

// В серверном экшене, редактирующем товар:
import { revalidateTag } from 'next/cache';

export async function updateProduct(formData: FormData) {
  'use server';
  await db.product.update(/* ... */);
  revalidateTag('product-42'); // очищает записи Data Cache → Full Route Cache
                               // перегенерируется → клиентский Router Cache сбрасывается
}

Компромисс: каждый слой меняет свежесть на свою цену. Мемоизация — бесплатная корректность. Data Cache экономит нагрузку на источник, но может отдавать данные, которых больше не существует, — через деплои. Full Route Cache даёт латентность уровня CDN, но только маршрутам, отказавшимся от данных на каждый запрос. Router Cache делает навигацию нативной по ощущению — но это значит, что сервер уже починен, а вкладка пользователя всё ещё показывает баг.

Инвалидация: revalidate, теги и выход из кеша

Ревалидация по времени (revalidate: 3600 или export const revalidate = 3600 на уровне сегмента) работает как stale-while-revalidate: первый запрос после истечения всё ещё получает протухшую запись, перезапрос происходит в фоне, и свежие данные видит уже следующий запрос. Этот «ещё один протухший хит» удивляет тех, кто ждал жёсткого TTL.

Инвалидация по требованию — точный инструмент: revalidateTag('products') вычищает каждую запись Data Cache с этим тегом и инвалидирует Full Route Cache маршрутов, собранных из неё; revalidatePath('/products') делает то же по маршруту. Вызванные внутри серверного экшена, они инвалидируют и клиентский Router Cache затронутых путей — пользователь, сделавший мутацию, видит результат сразу. Вызванные из route handler (скажем, вебхук CMS — правильный фикс пятничного бага), они чинят серверные кеши, но до браузеров дотянуться не могут; открытые вкладки догонят при следующей жёсткой навигации или перезагрузке.

Выход из кеша — по слоям: cache: 'no-store' пропускает Data Cache для одного fetch; export const dynamic = 'force-dynamic' заставляет весь маршрут рендериться на каждый запрос (мимо Full Route Cache); cookies() или headers() делают то же неявно. Заметьте асимметрию: некешируемый fetch внутри в остальном статического маршрута делает маршрут динамическим — но динамичность маршрута не мешает его fetch-ам пользоваться Data Cache. Кеширование маршрута и кеширование данных — независимые оси.

Диагностика «мои данные не обновляются» — слой за слоем

Это самый частый production-баг Next.js, и он поддаётся упорядоченному обходу — сначала сервер, потом клиент.

Шаг 1 — маршрут статический? Смотрите вывод сборки: кружок — статический, ƒ — динамический. Если он статический, а данные нужны на каждый запрос, Full Route Cache отдаёт HTML времён сборки, и никакая опция fetch не спасёт — маршруту нужен dynamic = 'force-dynamic' или динамический API. Если он должен быть статическим, но периодически свежим — задайте revalidate.

Шаг 2 — fetch кешируется? На Next 14 голый fetch по умолчанию force-cache: вашей записи может быть несколько месяцев, и деплой её не берёт. Определите реальный контракт свежести: окно revalidate, теги плюс revalidateTag из вебхука или no-store, если данные действительно на каждый запрос.

Шаг 3 — мутация инвалидирует? Серверный экшен, который пишет в базу, но не вызывает revalidatePath/revalidateTag, оставляет все кеши нетронутыми — запись прошла, просто кешам не сказали. Это самое частое упущение.

Шаг 4 — протухло только в одной вкладке? Сервер по curl отвечает свежим, а пользователь видит старые данные при навигации назад: это Router Cache. Если протухание следует за мутацией — фикс относится к шагу 3 (экшены инвалидируют и Router Cache); для свежести «данные изменились где-то ещё» варианты — router.refresh() или осознанно принятая сессионная протухлость.

Вместе эти четыре шага означают, что виновник всегда известен до того, как вы трогаете код: протухает после деплоя — Data Cache; только одна вкладка — Router Cache; кружок в выводе сборки — Full Route Cache. Без шага 1 можно потратить час на добавление no-store к fetch внутри статически рендеримого маршрута, где fetch на каждый запрос вообще не выполняется.

Дисциплина в том, чтобы назвать слой до того, как тянуться за фиксом. Рассыпанный везде no-store «работает», схлопывая все четыре слоя, — и утраивает нагрузку на источник; именно так пятничный хотфикс уронил p95.

Next 15 перевернул умолчания — версионируйте свои советы

Всё выше — механика, общая для обоих мажоров, но умолчания в Next 15 изменились существенно, и половина советов в интернете молча предполагает не те. В Next 15: fetch больше не кешируется по умолчанию (семантика no-store, пока не включите явно через cache: 'force-cache' или опцию revalidate), GET route handlers больше не кешируются по умолчанию, и Router Cache больше не переиспользует сегменты страниц по умолчанию (staleTime 0 для страниц — свежая навигация перезапрашивает страницу, тогда как восстановление назад/вперёд и layout по-прежнему берутся из кеша; настраивается конфигом staleTimes). Full Route Cache и статический рендеринг остаются умолчанием для маршрутов без динамических API.

Практически: на кодовой базе Next 15 пятничный баг в рассказанном виде с голым fetch почти невозможен — но он возвращается, как только кто-то добавляет force-cache ради производительности и забывает инвалидационную половину сделки. А команды, апгрейдящиеся с 14, видят зеркальный инцидент: трафик на источник подскакивает после апгрейда, потому что каждый прежде кешируемый по умолчанию fetch теперь бьёт в источник на каждый запрос. Прежде чем отлаживать любое кеш-поведение, выполните next --version — один и тот же код имеет разную семантику по разные стороны этой границы.