Next.js 16.3 вышел. Обновляйтесь — но главную фичу пока не включайте

Вышел Next.js 16.3, и это самый крупный релиз 16 версии с прошлого ноября. Я прочитал ченджлог два раза: первый - как разработчик, у которого зачесались руки, второй - как человек, который потом будет отвечать на вопрос «а почему прод лежит».

И вот что я вам скажу: обновляться надо. Прямо сегодня. А флагманскую фичу - не трогать.

Сейчас объясню, почему это не противоречие.

Что вы получите бесплатно, ничего не переписывая

Самое приятное в этом релизе - то, что работает само, без единой строчки изменений в вашем коде.

Дев-сервер перестал жрать память. Turbopack получил вытеснение из памяти и дисковый кэш по умолчанию - до 90% меньше RAM в next dev. Vercel показывает свои цифры на собственной панели: было 21,5 ГБ, стало 2 ГБ. На сайте nextjs.org - 4600 МБ против 840 МБ.

Вот тут я хочу остановиться. 21,5 гигабайта. На дев-сервере. Я много лет замечал, что «ноутбук греется, потому что фронтенд» - это не шутка, а диагноз индустрии. Мы дошли до того, что средой разработки для сайта стал инструмент, которому нужно больше памяти, чем моему первому серверу с базой на несколько миллионов записей. То, что Vercel это наконец починил, - отличная новость. То, что до этого дошло, - по-прежнему повод задуматься.

Сборки на CI ускорились. Дисковый кэш теперь работает и для next build. Разброс честный, и мне нравится, что его не спрятали: nextjs.org - 21 с против 9,2 с, vercel.com/home - 66 с против 46 с, а вот vercel.com/geist - 30 с против 5,5 с, те самые «5,5×» из заголовков. То есть маркетинговая цифра взята с самого удачного проекта, а ваш реальный выигрыш, скорее всего, ближе к полутора-двум разам. Всё равно хорошо.

SSR стал быстрее на четверть. В App Router web streams заменили на нативные Node.js streams - убрали конвертацию между двумя мирами при рендере. До 22% больше запросов под нагрузкой. Опять же: без изменений в коде.

TypeScript 7 подключается одной строкой. pnpm add -D typescript@^7 - и next build использует нативный порт, который у Microsoft заявлен как десятикратно более быстрый.

Плюс по мелочи, но приятной: import.meta.glob в Turbopack (наконец-то можно нормально читать папку с markdown в серверном компоненте), root params - можно достать [lang] из любого серверного компонента без пробрасывания пропсов через восемь уровней, и кастомные error boundaries с catchError, которые больше не ломают notFound и redirect и умеют ретраить серверные компоненты.

Вот за это всё - обновляйтесь. Риск близок к нулю, выгода измерима.

А теперь про то, что трогать рано

Главная витрина релиза - Instant Navigations. Набор из пяти штук (Instant Insights, Partial Prefetching, новый ISR, Navigation Inspector, хелпер для Playwright), который должен дать серверному Next.js отзывчивость нормального SPA. Включается двумя флагами:

const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};

Идея хорошая и, судя по всему, правильная - Vercel прямо пишет, что это поведение станет дефолтным в следующей мажорной версии. 'use cache' наконец-то доводят до состояния, когда он закрывает и серверный кэш, и клиентский, а не только половину задачи.

Проблема в том, что «правильная идея» и «готово к вашему проду» - это две разные даты в календаре.

Из того, что уже всплыло:

• Static export несовместим с Partial Prefetching. Если вы собираете статику - просто мимо.
• Глобальные стили styled-jsx протекают между роутами. Классика: включили ускорение навигации, получили баг вёрстки, который воспроизводится только при переходе по ссылке и только вторым кликом.
• На self-hosted cacheComponents может уронить серверный рендер целиком. Вот это - прямо в меня. Мы не на Vercel. Мы почти никогда не на Vercel.

И вот тут вылезает вещь, о которой стоит говорить чаще, чем про сами фичи. Next.js - фреймворк, который делает компания, зарабатывающая на хостинге этого фреймворка. Это не заговор и не повод бежать на Astro. Но это значит, что «протестировано в продакшене» у Vercel и «протестировано в продакшене» у вас - про разные продакшены. Их путь всегда будет обкатан лучше вашего. Всегда.

Как я это делаю у себя

Формулировка, которая ходит по обсуждениям, звучит примерно так: обновляйтесь ради дефолтов, а Instant Navigations включайте по одному роуту за раз. Подписываюсь.

Мой план на ближайший спринт:

1. Поднять 16.3 на ветке, прогнать тесты, убедиться, что дефолты не сломали ничего. Это дёшево и почти наверняка пройдёт.
2. Померить. Не «ощущается быстрее», а конкретные цифры: пиковая память дев-сервера, время холодной и тёплой сборки на CI, RPS под нагрузкой. Если релиз обещает 22% - я хочу увидеть свои 22%, а не чужие.
3. TypeScript 7 - отдельной задачей, отдельным PR. Не смешивать.
4. Instant Navigations - не в этом спринте. Максимум: включить на одном второстепенном роуте в стейджинге и посмотреть, что скажет Instant Insights.

Отдельно отмечу штуку, которую я, кажется, утащу вне зависимости от всего остального: хелпер instant() для Playwright. Он позволяет написать тест, который падает, когда навигация перестала быть мгновенной. Кто-то добавил cookies() в общий хедер, роут де-оптимизировался - и вы узнаёте об этом от CI, а не от пользователя через полгода. Перформанс-регрессии, за которые отвечает тест, а не чья-то бдительность, - это ровно то, чего мне не хватало последние лет пять.

Итого

Хороший релиз. Действительно хороший - редкий случай, когда основная ценность в том, что стало лучше без вашего участия, а не в новом способе всё переписать.

Просто разделите его на две части. Первую забирайте сегодня. Вторую - когда выйдет 16.3.4, а в issues перестанут появляться слова «self-hosted» и «broken» в одном предложении.

Тише едешь - дальше выкатишь.