Переход на Next.js 16 с флагом cacheComponents кардинально меняет философию работы с данными. Раньше фреймворк стремился все кэшировать и делал это неявно, а теперь по умолчанию все динамическое, и вы сами явно указываете, что хотите закэшировать.
Это переход от модели “статики по умолчанию” к “динамике по умолчанию” с полным контролем разработчика. От себя скажу, что для разработчика это хорошо, меньше магии и больше понимания того что ты делаешь.
История. Как Next.js переобулся
Next.js 14
Тут кешировалось все, что только могло кешироваться.
Фреймворк по умолчанию стремился к статической генерации страниц (SSG) во время сборки. Он переключался на динамический рендеринг (SSR) только при обнаружении «динамических» функций, таких как cookies() или headers().
// app/blog/[slug]/page.tsx
export const dynamic = 'auto' // 'auto' | 'force-dynamic' | 'error' | 'force-static'
export const dynamicParams = true // true | false
export const revalidate = 3600 // false | 0 | number (в секундах)
export const fetchCache = 'auto' // 'auto' | 'force-no-store' | 'only-cache' | ...
Все fetch-запросы по умолчанию кэшировались (аналог cache: 'force-cache'). Это означало, что если вы не указывали опции явно, данные запрашивались один раз при сборке, и все пользователи видели одну и ту же версию
// Данные будут получены один раз при сборке и закешированы навсегда.
// Опцию cache: 'force-cache' можно не указывать, это значение по умолчанию.
await fetch('https://api.example.com/posts', { cache: 'force-cache' });
Next.js 15
Самым значимым и обсуждаемым изменением в Next.js 15 стал полный пересмотр стратегии кэширования данных. Разработчики фреймворка прислушались к сообществу, которое часто сталкивалось с непредсказуемым поведением из-за агрессивного кэша в 14-й версии.
И вот теперь fetch() больше не кэширует данные.
В Next.js 15 поведение по умолчанию изменилось на cache: ‘no-store’. Это значит, что каждый запрос fetch() будет выполняться заново при каждом обращении к странице, если вы явно не укажете иное. Это делает поведение в разработке и на продакшене более предсказуемым, но требует более осознанного подхода к оптимизации.
️ GET Route Handlers также стали динамическими
Изменение коснулось и обработчиков маршрутов (Route Handlers). В 14-й версии GET-запросы кэшировались по умолчанию. В 15-й версии они также стали динамическими.
Изменения затронули и клиентскую часть.
В Next.js 14 кэш роутера на стороне клиента (Router Cache) по умолчанию сохранял посещенные страницы на 30 секунд для динамических и на 5 минут для статических страниц. В Next.js 15 клиентский кэш по умолчанию отключен для всех страниц. Теперь при переходе по страницам они будут загружаться заново, гарантируя, что пользователь всегда видит актуальную информацию. Если вам нужно ускорить навигацию и вы готовы пойти на компромисс, время жизни кэша можно настроить вручную в next.config.ts:
// next.config.ts
const nextConfig = {
experimental: {
staleTimes: {
dynamic: 30, // 30 секунд для динамических страниц
static: 180, // 3 минуты для статических страниц
},
},
};
Next.js 16
В 16-й версии Next.js добавляет флаг cacheComponents который действительно полностью меняет правила игры: он отключает всю старую модель кэширования и заменяет ее на новую, полностью явную. Всё, что вы знали о fetch, revalidate и export const dynamic раньше, больше не работает.
Это все значит, что нам опять переучиваться ( ну, нам с @kirilljsx не привывать). Новые проблемы -> новая работа -> новые вакансии 
. Об этом всем можно и поныть, но на мой субъективный взгляд, надо было изначально делать таким фреймворк, а не подстраиваться под стадо вебмакак низшего эшелона добавляю свою магию везде, где нужно и не нужно.
cacheComponents - Новая реальность
Теперь, когда старые правила отключены, все решения о кэшировании принимаются явно и на уровне кода с помощью новой директивы ‘use cache’ и сопутствующих функций. Основной принцип прост: по умолчанию не кэшируется ничего.
Директива 'use cache' — это ваш главный инструмент. Её можно применять на трех уровнях:
-
На уровне файла (страницы или компонента): Поместите директиву в самом верху файла, и все экспортируемые из него асинхронные функции будут кэшироваться.
-
На уровне компонента: Используйте директиву внутри тела компонента, чтобы закэшировать результат его рендеринга.
-
На уровне функции: Применяйте к асинхронным функциям, чтобы кэшировать возвращаемые ими данные.
cacheLife - Управление временем жизни кэша
Для управления временем жизни кэша используется функция cacheLife. Она должна вызываться внутри области действия ‘use cache’.
Вы можете использовать один из предустановленных профилей или создать свой собственный. Профили определяют три ключевых параметра: stale, revalidate и expire:
Разберем подробнее, какой параметр за что отвечает.
-
stale (Клиентский кеш)
Определяет, как долго клиент (браузер) может показывать данные из кеша, вообще не связываясь с сервером для проверки.
Пока не истечет это время, при повторном посещении страницы она загрузится мгновенно из памяти.
Параметр чисто клиентской производительности, призванный ускорить навигацию.
-
revalidate (Фоновая проверка)
Частота, с которой кеш в фоновом режиме запрашивает свежие данные с сервера.
Как только время revalidate истекает, Next.js все равно мгновенно отдает клиенту “устаревший” кеш, но в фоне запускает процесс генерации новой версии. Новые данные подготовятся к следующему запросу.
Механизм stale-while-revalidate. Пользователь всегда получает быстрый ответ, даже если данные немного устарели.
-
expire (Крайний срок)
Максимальное время, в течение которого данные могут оставаться “устаревшими” до того, как они будут считаться полностью недействительными.
Если данные в кеше находятся в состоянии “stale” (после revalidate) дольше, чем позволяет expire, Next.js больше не будет отдавать их мгновенно. Вместо этого он заблокирует ответ и заставит пользователя подождать, пока новые данные будут получены с сервера (динамический рендеринг).
Защитный механизм от показа “совсем старых” данных. expire всегда должен быть больше revalidate.
| Профиль |
stale |
revalidate |
expire |
Описание |
'seconds' |
30 сек |
1 сек |
1 мин |
Для контента, который должен обновляться почти мгновенно. |
'minutes' |
5 мин |
1 мин |
1 час |
Для часто обновляемого контента. |
'hours' |
5 мин |
1 час |
1 день |
Для контента, обновляемого несколько раз в день. |
'days' |
5 мин |
1 день |
1 неделя |
Для контента, обновляемого ежедневно. |
'weeks' |
5 мин |
1 неделя |
30 дней |
Для контента, обновляемого еженедельно. |
'max' |
5 мин |
30 дней |
1 год |
Для очень стабильного контента. |
Важно: Если вы не укажете cacheLife, будет применен профиль ‘default’, который подходит для большинства случаев.
включаем новый режим
Для активации новой модели необходимо добавить флаг cacheComponents: true в ваш файл next.config.ts. Это глобальный переключатель, который меняет поведение всего приложения:
// next.config.ts
import type { NextConfig } from 'next'
const nextConfig: NextConfig = {
cacheComponents: true,
}
export default nextConfig
Используем “use cache”
На уровне файла (страницы)
Если поместить ‘use cache’ в самом верху файла, она применяется ко всем экспортируемым асинхронным функциям в этом файле. Это удобно для кэширования целой страницы или группы связанных функций.
// app/blog/page.tsx
'use cache'; // <-- Директива на уровне всего файла
import { cacheLife } from 'next/cache';
// Эта функция тоже будет закэширована, так как она экспортируется и асинхронная
export async function getFeaturedPosts() {
// fetch без дополнительных опций, т.к. кэшированием управляет директива
const res = await fetch('https://api.example.com/featured-posts');
return res.json();
}
// Основной компонент страницы — экспортируемая асинхронная функция
export default async function BlogPage() {
cacheLife('hours'); // Устанавливаем время жизни кэша для всей страницы
const posts = await getFeaturedPosts();
return (
<main>
<h1>Блог</h1>
{posts.map((post) => (
<article key={post.id}>{post.title}</article>
))}
</main>
);
}
Важно: Если в этом же файле есть синхронные компоненты (например, function Sidebar()), они не попадают под действие ‘use cache’, потому что директива влияет только на асинхронные экспорты.
На уровне компонента
В этом случае директива помещается внутрь тела асинхронного компонента. Она кэширует результат рендеринга этого конкретного компонента.
// app/components/ProductList.tsx
import { cacheLife, cacheTag } from 'next/cache';
export async function ProductList({ category }: { category: string }) {
'use cache'; // <-- Директива внутри компонента
cacheLife('days');
cacheTag(`products-${category}`); // Тег для точечной инвалидации
const products = await fetch(
`https://api.example.com/products?category=${category}`
).then((res) => res.json());
return (
<div className="grid">
{products.map((product) => (
<div key={product.id}>{product.name}</div>
))}
</div>
);
}
Как использовать на странице:
tsx
// app/products/page.tsx
import { Suspense } from 'react';
import { ProductList } from '@/components/ProductList';
export default function ProductsPage() {
return (
<div>
<h1>Товары</h1>
{/* Этот компонент будет закэширован */}
<ProductList category="electronics" />
{/* А этот останется динамическим, так как не обёрнут в 'use cache' */}
<Suspense fallback={<p>Загрузка рекомендаций...</p>}>
<PersonalRecommendations />
</Suspense>
</div>
);
}
На уровне функции
Этот подход позволяет кэшировать результат конкретной асинхронной функции, например, запрос к базе данных. Это полезно, когда одну и ту же функцию нужно использовать в нескольких местах без повторного выполнения.
// app/lib/data.ts
import { cacheLife, cacheTag } from 'next/cache';
// Кэшируемая функция получения данных
export async function getUserProfile(userId: string) {
'use cache'; // <-- Директива на уровне функции
cacheLife('minutes');
cacheTag(`user-${userId}`);
console.log('Выполняется запрос к БД'); // Увидим только при первом вызове
const user = await db.user.findUnique({ where: { id: userId } });
return user;
}
Использование в компонентах:
// app/profile/page.tsx
import { getUserProfile } from '@/lib/data';
export default async function ProfilePage() {
const user = await getUserProfile('user-123'); // Кэшируется
return (
<div>
<h1>Привет, {user.name}!</h1>
<UserDetails user={user} />
</div>
);
}
Если getUserProfile вызвать ещё раз в другом компоненте на той же странице, запрос к БД не повторится — Next.js вернёт закэшированный результат.
Дополнительно: Комбинирование уровней
Вы можете комбинировать директивы. Например, страница закэширована целиком, но внутри есть функция, у которой свой собственный cacheLife.
// app/dashboard/page.tsx
'use cache'; // Кэшируем всю страницу
import { cacheLife } from 'next/cache';
import { getStats } from '@/lib/stats';
export default async function DashboardPage() {
cacheLife('hours'); // Основное время жизни для страницы
const stats = await getStats(); // Функция getStats может иметь свой 'use cache' и cacheLife
return <Dashboard stats={stats} />;
}
// app/lib/stats.ts
import { cacheLife } from 'next/cache';
export async function getStats() {
'use cache';
cacheLife('minutes'); // Этот кэш будет обновляться чаще, чем вся страница
const res = await fetch('https://api.example.com/stats');
return res.json();
}
В этом случае общий HTML страницы будет жить по правилам hours, а данные из getStats — по правилам minutes, но они всё равно встроены в статический каркас страницы.
Подводные камни (Важно!)
Не все так гладко, просто так включить флаг и пользоваться скорее всего не выйдет, если вы не подготовили проект к такому переходу 
Когда вы включаете cacheComponents в Next.js 16, фреймворк переходит к новой стратегии рендеринга — Partial Prerendering (PPR). В её основе лежит жёсткое требование: во время сборки (next build) должен быть сформирован мгновенно загружаемый статический “каркас” (static shell). Из-за этого асинхронное получение данных без 'use cache' и без <Suspense> приводит к ошибке сборки Uncached data was accessed outside of <Suspense>.
Причина ошибки: блокировка статического каркаса
Раньше Next.js мог “подождать” данные и отдать готовую страницу (SSR), но с cacheComponents он всегда пытается сгенерировать статическую оболочку на этапе сборки.
Проблема возникает, когда в компоненте есть асинхронный вызов (например, fetch или await params), который не может завершиться во время сборки и при этом не обрамлён. В этом случае сборка падает с ошибкой.
Если фреймворк не знает, что показывать пользователю, пока данные грузятся (нет fallback из ), он не может собрать статический каркас. Это защита от “медленной” страницы, где пользователь видит белый экран до полной загрузки всех данных на сервере.
Как исправить: два пути на выбор
У вас есть два варианта решения этой ошибки, в зависимости от ваших задач:
-
Закэшировать данные в статический каркас: Если данные меняются редко, их можно сделать частью мгновенно загружаемого каркаса. Для этого нужно добавить директиву 'use cache' прямо в асинхронную функцию. Тогда данные будут получены на этапе сборки и закэшированы.
-
Оставить данные динамическими, но с заглушкой: Если данные должны запрашиваться при каждом визите (персонализированная информация, часто меняющиеся данные), их нужно обернуть в <Suspense>. Это указывает Next.js оставить в статическом каркасе “заглушку” (fallback), а сами данные догрузить уже на клиенте в фоне.
( кейсы попробую подготовить далее в комментариях)
Как это работает?
🧱 Статический каркас (Static Shell) — что это?
Когда вы включаете cacheComponents, Next.js перестаёт генерировать страницу целиком динамически на сервере по каждому запросу. Вместо этого он во время сборки (build) пытается создать каркас страницы — мгновенно загружаемый HTML, который видит пользователь в первую секунду.
Внутри этого каркаса могут быть:
- Статический контент (заголовки, подвалы).
- Закэшированные данные.
- “Дырки” (Suspense Fallback) для тех данных, которые ещё не готовы.
️ Как именно кеш помогает отрисовать этот каркас?
Ответ кроется в том, в какой момент времени выполняется код.
Без кеша (ошибка сборки)
// ❌ Ошибка при сборке
export default async function Page() {
const data = await fetch('...'); // Запрос без 'use cache'
return <div>{data}</div>;
}
Во время сборки Next.js запускает этот компонент.
Он натыкается на await fetch. Стоп-машина. Потому что по новым правилам fetch по умолчанию динамический (no-store).
Next.js не может выполнить динамический запрос во время сборки (в окружении CI/CD нет контекста пользователя, да и смысла нет — данные же должны быть свежими при каждом запросе).
Next.js не знает, что рисовать в этом месте каркаса, и выбрасывает ошибку: “Я не могу собрать статику, потому что тут висит незавершенный асинхронный хвост”.
С кешем (успешная сборка)
// ✅ Успешная сборка
export default async function Page() {
'use cache'; // <-- Включаем кеш
const data = await fetch('...');
return <div>{data}</div>;
}
-
Выполнение во время сборки: Директива 'use cache' говорит фреймворку: "выполни этот fetch прямо сейчас, во время npm run build !!! ".
-
Сохранение результата: Next.js делает запрос к API, получает ответ и сохраняет его в кеш (на диск или в CDN).
-
Генерация HTML: Next.js берет полученные данные, рендерит их в HTML-строку
Данные из кеша
и вшивает этот HTML прямо в файл page.html.
-
Результат: Пользователь, заходя на сайт, мгновенно получает готовую страницу с уже встроенным текстом “Данные из кеша”.
Если данные нужны свежие, но каркас тоже нужен?
Тут в игру вступает <Suspense> Он позволяет обмануть сборку.
// ✅ Сборка проходит, данные свежие
import { Suspense } from 'react';
async function FreshData() {
const data = await fetch('...'); // Нет 'use cache'
return <div>{data}</div>;
}
export default function Page() {
return (
<main>
<h1>Статический заголовок</h1>
<Suspense fallback={<div>Загрузка данных...</div>}>
<FreshData />
</Suspense>
</main>
);
}
Как здесь помогает кеш? В этом примере кеша нет, но сборка всё равно проходит. Почему? Потому что физически вырезает проблемный компонент FreshData из процесса статической сборки.
Во время build:
-
Next.js рендерит <h1>Статический заголовок</h1>.
-
Доходит до . Вместо того чтобы лезть внутрь FreshData, он просто записывает в HTML строку <div>Загрузка данных...</div>(то, что в fallback).
-
Каркас готов! FreshData при сборке не вызывается вообще.
-
Когда пользователь открывает страницу, он видит “Загрузка…”, а React на клиенте (или сервере при стриминге) запускает FreshData, получает свежие данные и заменяет заглушку на реальный контент.
читаемо
