Next.js 16 уже не «новый», но в продакшне его аккуратно катают, а не запрыгивают. Мы перевели четыре проекта - два на чистый Next 16 + React 19, два гибридом - и собрали список того, что стоит обсудить с командой перед миграцией. Не маркетинг, а конкретные грабли.
Главное, что поменялось по факту
- Cache Components заменили большую часть ручной работы с fetch-кэшем - модель стала предсказуемее, но требует переписать половину утилит.
- Server Functions окончательно вытеснили Server Actions из документации и API; старый импорт работает, но deprecation-варнинг включён по умолчанию.
- Turbopack теперь дефолт и для prod-сборки, не только для dev. Webpack-конфиги нужно мигрировать или удалять.
- React Compiler v1 включён по умолчанию в новых проектах. Для существующих - opt-in, но эффект на bundle ощутимый.
- Middleware переехал в Node.js runtime; edge-варианты остались как отдельный флаг.
Что ломается чаще всего
Самая частая регрессия - кэширование. В Next 13–15 многие команды накопили обходные пути с unstable_cache, revalidateTag и ручными ключами. В Next 16 модель Cache Components другая: вы декларируете кэшируемость на уровне компонента и используете use cache. Если просто переименовать вызовы - половина данных начинает кэшироваться вечно или не кэшироваться вообще.
Второй частый кейс - несовместимые сторонние библиотеки. Часть React-библиотек 2022–2023 годов опирается на старое поведение useId и контекста; в React 19 они тихо ломают гидрацию. Перед миграцией прогоните полный e2e и проверьте hydration warnings - они теперь ошибка, а не warn.
Compiler v1: что реально даёт
На двух наших проектах после включения React Compiler bundle уменьшился на 9% и 14%, а число useMemo/useCallback в коде команда сократила примерно на 60%. Это разовая чистка, но она даёт более читаемый код. Главное - не пытайтесь вручную «помогать» компилятору; он сам решит, что мемоизировать.
Порядок миграции, который у нас сработал
- Зафиксируйте baseline: bundle size, LCP, время сборки, размер cache hit ratio.
- Обновите все зависимости React/Next до последних минорных версий 15.x.
- Прогоните codemod next-codemod cache-components и руками пройдите оставшиеся unstable_cache.
- Включите Compiler сначала на одном изолированном маршруте, через неделю - на разделе.
- Снесите webpack.config, мигрируйте кастомные лоадеры на Turbopack-плагины.
- Проведите hydration-аудит: hydration warnings в Next 16 не падают тихо.
- Сравните baseline-метрики через две недели. Если ухудшилось - у вас Cache Components сломаны.
Что пока не трогаем
Server Functions для платежей и операций с побочными эффектами держим, но не превращаем в основной API-слой. У нас остаётся отдельный backend, и Server Functions - это удобный способ вызвать его из RSC, а не замена. Тимлидам, которые хотят «всё переписать на Server Functions», советуем притормозить хотя бы на квартал - там ещё догоняется observability и rate-limiting.
По маленьким лендингам и контентным сайтам - мигрируйте сразу. По крупному SaaS - спланируйте квартал, не неделю.