Next.js 16.4 вышел в stable 6 октября 2026 - и для тех, кто хостит Next.js на собственном железе, это триггер к обновлению, а не рутинный релиз.[1] Security-обновление (07.11.2026): четыре из семи адвизори ноябрьского security-релиза Next.js бьют по Cache Components / use cache (одно High - утечка данных между пользователями) - если Cache Components включены, нужна v16.4.5 или новее; подробности в нашем гайде по ноябрьскому релизу.[9] Главное - шаг, который зреет всю линейку 16.x: Cache Components теперь рекомендованный дефолт, включённый из коробки в каждом новом проекте create-next-app; дефолтом для всех приложений он станет в Next.js 17.[1] Поверх этого 16.4 поставляет React 19.3, тратит меньше памяти и диска в development, собирает меньшие прод-бандлы и добавляет команду next upgrade --agent, которая автоматизирует миграцию существующих App Router-кодбазов.[1]

Большинство гайдов по Next.js останавливаются на «что в релизе». Этот читается с точки зрения того, кто крутит сервер: что на самом деле делает новая модель кэширования по умолчанию, что меняется на маленьком VPS за nginx и PM2, как перейти на 16.4 не сломав рабочее приложение, и где новые примитивы кэширования важны именно вам. Полный путь деплоя на VPS мы уже разобрали в отдельном гайде - здесь речь именно о том, что 16.4 меняет поверх него.

Главное: кэширование становится явным, декларативным и дефолтным

Если вы на App Router начиная с 15, вы знаете его репутацию: неявное, сюрпризное и труднообъяснимое кэширование - страницы переключаются между статикой и динамикой без очевидного сигнала. Cache Components - это чистый разрыв. Вместо того чтобы Next.js молча решал, что кэшировать, вы это помечаете через 'use cache', а Next.js кэширует UI отмеченного компонента в браузере при клиентских навигациях и, опционально, на сервере при рендере или на этапе сборки.[1]

Ключевая фраза разработчиков: Cache Components заменяет «неявное поведение кэширования предыдущих версий App Router».[1] Это также модель, которую команда теперь рекомендует для каждого приложения - важная веха, ведь до 16.4 они намеренно не рекомендовали её универсально, потому что в некоторых случаях она не достигала тех же гарантий по стоимости и производительности. Новые фичи 16.4 закрывают эти разрывы.[1]

Для 16.4 новые проекты получают это по умолчанию. create-next-app включает Cache Components при создании, так что greenfield-приложения переходят на новую модель без единой правки миграции.[1] Если стартуете с нуля - это дефолт, на котором вы будете работать с первого дня.

Три примитива, которые стоит знать: use cache, cacheLife, cacheTag

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

'use cache' помечает роут, компонент или функцию как кэшируемую. Ставится в начале файла (все экспорты) или инлайн в начале async-функции или компонента:

export async function Projects({ userId }) {
  'use cache';
  cacheLife('hours');

  const projects = await db.query.projects.findMany({
    where: eq(projectsTable.userId, userId),
  });

  return (
    <div>
      {projects.map((project) => (
        <p key={project.id}>{project.name}</p>
      ))}
    </div>
  );
}

Думайте о нём как о версии заголовка Cache-Control на уровне компонента.[1] Кэшируемые функции и компоненты должны быть async, а их аргументы и возвращаемые значения - сериализуемыми.[1]

cacheLife задаёт, сколько живёт кэшированный вывод, через три таймера:[2]

  • stale - как долго клиент может использовать кэш, не проверяя сервер (дефолт: 5 минут).
  • revalidate - как часто сервер перегенерирует контент в фоне (дефолт: 15 минут).
  • expire - максимальный возраст, после которого сервер обязан перегенерировать контент синхронно (дефолт: никогда).

Next.js поставляет готовые профили, которые передаются по имени - seconds, minutes, hours, days, weeks, max, - значения которых можно переопределить в next.config.ts, плюс свои кастомные профили.[2] На практике на self-hosted-приложении cacheLife('hours') или cacheLife('days') для дорогого дашборд-запроса или фида - это разница между ударами по базе на каждый запрос и отдачей готового рендера из кэша.

cacheTag вешает метки на записи кэша для инвалидации по требованию. Теги добавляются внутри кэшируемого скоупа, затем очищаются из Server Function или Route Handler, не трогая другие записи:[3]

async function getPostContent(slug: string) {
  'use cache'
  const post = await fetchPost(slug)
  cacheTag(`post-${slug}`)
  return post.data
}

Один вызов cacheTag принимает до 128 тегов, каждый до 256 символов - записи сверх этих лимитов отбрасываются с предупреждением в консоли.[3] Это примитив, который делает возможным «инвалидировать ровно то, что изменилось», вместо сноса всего роута или ожидания TTL.

Почему дефолт важен именно на self-hosted VPS

Вот часть, которую пропускает большинство релизных обзоров: где живёт кэш, зависит от того, где вы запускаете приложение. Рантайм-кэш за 'use cache' по умолчанию - это in-memory LRU-хранилище, и его поведение чётко делится между serverless и self-hosted.[4]

  • Serverless: записи кэша обычно не переживают запросы (каждый запрос может попасть на другой инстанс), так что рантайм-кэширование без удалённого хранилища ненадёжно.
  • Self-hosted: записи кэша переживают запросы, потому что это один долгоживущий процесс - ровно та модель, которую даёт ваш PM2-управляемый node .next/standalone/server.js.[4]

Это структурное преимущество, которое у вас уже есть. Каждый экземпляр сервера Next.js держит свой in-memory-кэш, который по умолчанию составляет 50 МБ, настраивается через cacheMaxMemorySize.[5] Опция задаёт размер двух кэшей: серверный кэш (предварительно отрендеренные страницы, ответы route handler, оптимизированные изображения) и встроенный обработчик за 'use cache'.[5]

Два следствия для небольшой машины:

  • Память теперь - рычаг настройки. Кэш по умолчанию - 50 МБ на инстанс сервера, лежит в том же процессе, что и приложение. На VPS на 1–2 ГБ это реальный, предсказуемый же след; при нескольких PM2-инстансах он умножается. Если одна страница или тяжёлый скоуп 'use cache' начинают давить на инстанс - cacheMaxMemorySize это то место, где вы его зажимаете, а cacheMaxMemorySize: 0 отключает оба in-memory-кэша целиком.[5]
  • Вам нужен дефолт, а не serverless-костыль. В документации прямо сказано, что self-hosted 'use cache' со встроенным in-memory-обработчиком может быть достаточен, тогда как serverless-приложениям обычно нужен 'use cache: remote' (Redis/KV, с платой платформы), чтобы рантайм-кэширование переживало запросы.[4] На своём VPS вы получаете персистентное рантайм-кэширование бесплатно - без удалённой инфры.

Так что когда в нотах 16.4 читаете «меньше RAM в dev», помните: у продовой стороны тоже есть конкретный, настраиваемый пол - 50 МБ на инстанс по умолчанию, вверх или вниз по вкусу, при этом dev-сервер держит собственный in-memory-кэш независимо от опции.[5]

Переход на 16.4 через next upgrade --agent

История с тулингом действительно новая. next upgrade существует с 16.1.0;[6] новый флаг --agent в 16.4 нацелен прямо на проблему миграции.[1] По словам релиз-нот, next upgrade --agent «проверяет установленную версию, выбирает целевой релиз и готовит гайды по миграции, нужные codemod’ы и шаги верификации для вашего агента» - агент применяет обновление, решает проблемы и проверяет, что приложение работает.[7]

Две практические заметки для запуска самому:

  • Оно целится в последний релиз и управляется агентом. Можно запустить next upgrade --agent с аргументом-директорией или позволить агенту вести весь процесс - в том числе на next@canary ради новейшего тулинга, даже если ваше приложение на более старой версии Next.[7]
  • Оно не замажет сдвиг Cache Components. Включение cacheComponents - не переименование. Гайд по апгрейду прямо говорит, что оно «может всплыть ошибками сборки для некэшируемых данных вне <Suspense>» и требует принятия модели.[8] Иначе говоря: после прогона --agent ждите, что сборка выдаст вам чек-лист путей с некэшируемыми данными, которым теперь нужна явная граница 'use cache' - это инструмент честно говорит, а не падает.

Перед тем как что-то трогать, один жёсткий пол для всей линейки 16.x: минимум Node.js 20.9+ (Node 18 больше не поддерживается), плюс TypeScript 5.1+.[8] Проверяйте рантайм до codemod’ов, а не после.

Что 16.4 делает с вашим билдом и диском

Self-hosting означает, что артефакт, который вы собираете и копируете на сервер, - и есть главное. 16.4 поставляет несколько улучшений «из коробки», которые меняют этот артефакт:

  • Меньше дисковый кэш Turbopack. Дисковый кэш компилятора занимает на 20–25% меньше пространства без изменения конфига.[1] На VPS, где .next и повторные сборки съедают диск, это измеримо.
  • Общий рантайм в одном чанке. Turbopack теперь поставляет рантайм одним чанком, общим для всех роутов, что уменьшает размер скачивания и повышает cache-hit rate.[1] Меньше полезной нагрузки вашим пользователям и меньше раунд-трипов к CDN или вашему nginx-кэшу.
  • React 19.3. Стабильные View Transitions и Fragment Refs, плюс новый API browser().[1] Версионно чувствительно, если вы на старой версии React - апгрейд тянет его за собой.
  • Экспериментальный Rust React Compiler. Опционально, но работа над компилятором в 16.4 урезала потребление памяти React Compiler на 30% и время компиляции на 15% - стоит почитать, если собираете на ограниченном железе.[1]

Ничто из этого не меняет механику деплоя из прошлого гайда: вы так же собираете с output: 'standalone', так же запускаете node .next/standalone/server.js под PM2 и так же проксируете через nginx. Меняется то, почему дефолтное кэширование ощущается иначе после запуска - тот же процесс, та же машина, теперь с декларативным кэшем, который можно крутить.

Стоит ли переходить на Cache Components сейчас

Если вы на greenfield или небольшом приложении - по сути да: это дефолт, который получают новые проекты, так что вопрос лишь в том, как быстро вы его осваиваете. Для существующего App Router-приложения пусть next upgrade --agent прогонит механическую часть, а затем относитесь к всплывшим ошибкам «uncached data outside <Suspense>» как к настоящей работе миграции.

Практический выигрыш на self-hosting - концентрация там, где нужно: при self-hosted 'use cache', персистентном в памяти между запросами, часто запрашиваемая дорогая страница перестаёт пере-рендериться против вашей базы целиком, на инфре, которую вы уже оплачиваете.[4] Заложите дефолт 50 МБ на инстанс в свою арифметику памяти и крутите cacheMaxMemorySize, когда один инстанс тесен или когда решаете размазаться по нескольким процессам PM2.

Коротко

Next.js 16.4 (stable, 6 октября 2026) делает Cache Components рекомендованной моделью и дефолтом для новых проектов create-next-app (дефолт для всего фреймворка - в Next.js 17): помечаем кэш через 'use cache', таймим через cacheLife, инвалидируем по требованию через cacheTag.[1][2][3] Особенно для self-hosters рантайм-кэш переживает запросы в одном долгоживущем процессе - реальное преимущество над serverless - и по умолчанию составляет 50 МБ на инстанс, настраивается через cacheMaxMemorySize.[4][5] Новые проекты получают его из create-next-app; существующие кодбазы мигрируют через next upgrade --agent.[1][7] Он ужимает дисковый кэш Turbopack на 20–25%, делит один рантайм-чанк между роутами и несёт React 19.3.[1] Сначала проверьте, что на Node 20.9+, запустите апгрейд --agent и будьте готовы дать каждому некэшируемому пути явную границу 'use cache'.[8]

Источники

  1. Next.js - релиз-пост «Next.js 16.4» (6 октября 2026: Cache Components дефолт в create-next-app, next upgrade --agent, React 19.3, дисковый кэш меньше на 20–25%, общий рантайм-чанк, Rust React Compiler −30% памяти / −15% времени компиляции, ensureStatic, navigation()/prefetch()). https://nextjs.org/blog/next-16-4 - проверено 2026-10-08
  2. Next.js - справочник cacheLife (пресет-профили, таймеры stale/revalidate/expire, значения дефолтного профиля). https://nextjs.org/docs/app/api-reference/functions/cacheLife - проверено 2026-10-08
  3. Next.js - справочник cacheTag (инвалидация по требованию, лимит 128 тегов / 256 символов каждый). https://nextjs.org/docs/app/api-reference/functions/cacheTag - проверено 2026-10-08
  4. Next.js - директива «use cache» (соображения рантайм-кэширования: serverless vs self-hosted персистентность; in-memory LRU по умолчанию). https://nextjs.org/docs/app/api-reference/directives/use-cache - проверено 2026-10-08
  5. Next.js - справочник конфига cacheMaxMemorySize (дефолт 50 МБ; тарифицирует серверный кэш и обработчик 'use cache'; 0 отключает оба). https://nextjs.org/docs/app/api-reference/config/next-config-js/cacheMaxMemorySize - проверено 2026-10-08
  6. Next.js - справочник CLI next (команда next upgrade добавлена в v16.1.0). https://nextjs.org/docs/app/api-reference/cli/next - проверено 2026-10-08
  7. Next.js - релиз-пост «Next.js 16.4», секция «New agent features → Agent upgrades». https://nextjs.org/blog/next-16-4 - проверено 2026-10-08
  8. Next.js - гайд «How to upgrade to version 16» (минимум Node.js 20.9+; cacheComponents - не переименование и всплывает ошибками сборки для некэшируемых данных вне <Suspense>). https://nextjs.org/docs/app/guides/upgrading/version-16 - проверено 2026-10-08
  9. Next.js - «November 2026 Security Release» (2026-11-03: v16.4.5 / v15.5.29; семь адвизори, четыре в Cache Components / use cache, GHSA-mfr8-8qww-v76h High). https://nextjs.org/blog/november-2026-security-release - проверено 2026-11-07