Next.js 16.3 обещает разработчикам не новую философию фронтенда, а вещь куда полезнее: меньше падений из-за памяти. Команда фреймворка заявляет о сокращении потребления RAM до 90%, а в тесте приложения с 50 маршрутами расход снизился примерно с 4,6 ГБ до 840 МБ. Для команд, у которых dev-режим и сборка больших React-проектов регулярно упираются в FATAL ERROR, это уже не микрооптимизация, а прямой способ тратить меньше времени на перезапуски и апгрейды железа.
4 августа 2026 года команда выпустила первое функциональное обновление Next.js с октября 2025-го. Как пишет The Register, релиз приносит не только более экономную работу с памятью, но и ускорение рендеринга, улучшения рантайма и полную обратную совместимость. То есть Vercel пытается решить довольно земную проблему: фреймворк должен оставаться удобным для крупных приложений, не заставляя разработчика выбирать между привычным стеком и очередной планкой оперативной памяти.
Откуда взялась экономия памяти
Главный источник изменений — Turbopack, встроенный высокопроизводительный сборщик, который в экосистеме Next постепенно вытесняет Webpack. В 16.3 команда включила по умолчанию две вещи, которые раньше приходилось настраивать или ждать в следующих версиях: дисковый кэш и вытеснение объектов из памяти. Первая механика читает уже собранный кэш перед компиляцией и пересобирает только то, что реально изменилось. Вторая в режиме разработки сбрасывает редко используемые артефакты на диск, когда система подходит к заданному порогу по памяти, и подгружает их обратно по мере надобности. На бумаге это выглядит сухо, но именно из таких скучных дефолтов складывается жизнь больших фронтенд-репозиториев: меньше мусора в RAM, меньше шансов, что V8 захлебнется, а Node.js завершится с тем самым сообщением, которое никто не хочет видеть после десятой правки в компоненте.
Цифры у команды агрессивные, но уже с понятной привязкой к сценарию. Для проекта с 50 маршрутами Next.js 16.3, по данным разработчиков, укладывается в 840 МБ, тогда как предыдущая версия требовала около 4,6 ГБ. Есть и ранние отзывы пользователей. Один из разработчиков агентства White Room написал, что предрелиз сократил потребление памяти примерно с 4 ГБ до 1,5 ГБ и вернул систему «в норму». Другой ранний пользователь сообщил о падении расхода с примерно 20 ГБ до 5 ГБ. Это не академическая красота графиков: если такие значения повторяются хотя бы у части команд, релиз может снять старую боль монореп, дизайн-систем и внутренних админок, где dev-сервер нередко ест память так, будто тестирует лимиты ноутбука.
Отдельно Vercel говорит об ускорении сборки. Дисковый кэш проверяли ещё на версии 16.1, а в 16.3 сделали поведением по умолчанию для build-процесса. В собственных тестах компании проект, который раньше собирался 21 секунду, теперь укладывается в 9,2 секунды. Это примерно 2,3-кратный прирост. Важно, что речь не про экзотический переписанный проект, а про вполне бытовой сценарий инкрементальной разработки: открыл ветку, поменял несколько файлов, не хочешь ждать полминуты каждый раз. Для команд с CI, локальной сборкой и постоянными предпросмотрами такие секунды быстро превращаются в часы, а часы — в вполне осязаемую стоимость разработки.
Не только память и сборка
Но релиз не сводится к памяти. В пакет попала ранняя, пока экспериментальная версия React Compiler, написанная на Rust и встроенная прямо в Turbopack. Идея простая: меньше ручной возни с мемоизацией и меньше завязки на отдельный прогон через Babel. По оценке команды, такой компилятор может сократить время холодной сборки страниц на 34%, а тёплой — на 46%. Отдельным бонусом идёт TypeScript 7, где часть прироста производительности связана с переходом на Go. Формально это заслуга не Next.js, но проект честно забирает себе часть аплодисментов, потому что обновление локальной зависимости до этой версии в конфигурации Next, по его оценке, даёт примерно десятикратный выигрыш в связанных операциях. Здесь, впрочем, лучше держать голову холодной: речь не о том, что весь проект внезапно станет в десять раз быстрее, а о заметном ускорении в типичных сценариях работы с TypeScript.
Есть и улучшения на стороне рантайма. Команда убрала преобразование web streams и перешла на нативные Node.js streams по всему слою server-side rendering. Итог, по её данным, — до 22% больше обслуженных запросов без изменений в коде приложения. Плюс идут более приземлённые, но полезные вещи: упаковка payload-ов для сокращения числа prefetch-запросов, повторное использование неизменяемых ассетов для лучшего кэширования статики, инструмент Instant Navigations для поиска медленных компонентов, versioned docs для AI-агентов, custom error boundaries и glob-импорты. Набор разношёрстный, но в сумме он показывает, куда Vercel толкает фреймворк: меньше ручной настройки, меньше скрытых штрафов по производительности, больше автоматизации на уровне платформы.
На фоне разговоров о том, что Next.js теряет хватку под давлением Astro, Remix и Gatsby, релиз выглядит как ответ не на пикировки в соцсетях, а на метрики. По словам CEO Vercel Гильермо Рауха, в 2026 году Next.js перевалил за 1 млрд загрузок против примерно 520 млн годом ранее. Это не доказывает, что конкуренты не откусывают свою долю, но показывает другое: у Next всё ещё слишком большая инсталляционная база, чтобы позволить себе роскошь игнорировать проблемы памяти и скорости. Для русскоязычных продуктовых команд и аутсорсеров это тоже практичный сигнал. Если фреймворк действительно стал заметно экономнее без ломки обратной совместимости, обновление можно рассматривать не как ещё один минорный релиз, а как способ отложить дорогой рефакторинг или переезд на другой стек.
Главная интрига теперь не в самом анонсе, а в том, повторятся ли эти цифры на живых монорепах с десятками пакетов, legacy-компонентами и неидеальной дисциплиной зависимостей. Если обещания Next.js 16.3 подтвердятся хотя бы у среднего слоя проектов, рынок получит редкий для фронтенда случай: релиз, который не продаёт новую идеологию, а просто убирает из дня разработчика лишнюю нервотрёпку. Исходные детали и цифры собрал .