Next.js 16.3 срезает потребление памяти до 90%: разбор релиза, который убивает «FATAL ERROR»

Vercel выпустила Next.js 16.3: первое крупное функциональное обновление React-фреймворка с октября 2025 года, и главная цифра релиза выглядит почти неприлично: потребление памяти снижено до 90%. Команда обещает полную обратную совместимость, то есть экономию можно получить простым обновлением зависимости, без переписывания кода. О релизе 4 августа 2026 года написало издание The Register.

Ниже разберём, откуда берётся экономия памяти в Next.js 16.3, какие цифры показывают ранние пользователи и есть ли подвох. Единственное, что стоит проверить перед апгрейдом, ждёт вас в самом конце.

«FATAL ERROR»: почему Next.js упирался в память

Знакомая боль всех, кто собирал крупное React-приложение: в какой-то момент Node.js-процесс падает, оставляя на экране лаконичное FATAL ERROR. Полностью сообщение движка V8 обычно звучит так: Reached heap limit Allocation failed, JavaScript heap out of memory. JavaScript-движок исчерпал выделенную память, и рухнула вся сборка.

Классический костыль, который годами передавался из проекта в проект, вручную поднимать лимит кучи через переменную окружения NODE_OPTIONS=--max-old-space-size. Работает, но это заклеивание симптома скотчем: вы разрешаете процессу съесть ещё больше RAM, пока не упрётесь в потолок железа. Next.js 16.3 бьёт по этой проблеме и, если верить замерам, снимает необходимость в таких обходных путях.

−90% RAM: что показывают цифры потребления памяти

Самый наглядный тест от самой Vercel: инстанс приложения на 50 роутах (роут, один полный адрес-URL в приложении) теперь занимает 840 МБ против примерно 4,6 ГБ в предыдущей версии. Около 82% экономии на ровном месте.

Ранние пользователи подтверждают порядок цифр. Разработчик из агентства White Room рассказал, что память его проекта упала с ~4 ГБ до ~1,5 ГБ, по его словам, «снова как в норме». Другой пользователь сообщил о более резком падении: с ~20 ГБ до ~5 ГБ. Для команд, которые арендуют облачные серверы под сборки и SSR, это прямая экономия на тарифе: меньше RAM в инстансе означает более дешёвую машину.

Вот сводка ключевых метрик релиза:

Turbopack вместо Webpack: инкрементальная сборка по умолчанию

Львиная доля улучшений завязана на Turbopack, встроенном бандлере, который Vercel позиционирует как преемника Webpack. Написан он на Rust, а развивает его в том числе Тобиас Копперс, автор оригинального Webpack. Turbopack входит в состав Next.js с версии 13 и работает как инкрементальный сборщик: перекомпилирует только те части кода, что изменились с прошлой сборки.

В 16.3 по умолчанию включили две вещи, которые раньше были опциональными: дисковое кэширование и вытеснение из памяти.

Дисковый кэш: сборка в 2,3 раза быстрее

Дисковый кэш обкатывали ещё на версии 16.1, а дефолтом для сборки он стал только сейчас. Логика простая: перед компиляцией Turbopack читает кэш с диска и пересобирает лишь новые куски. В тесте Vercel это ускорило сборку с 21 до 9,2 секунды, в 2,3 раза.

Вытеснение из памяти в режиме разработки

Вытеснение из памяти (memory eviction) работает при next dev. Когда потребление памяти достигает порога операционной системы, неиспользуемые артефакты сбрасываются на диск, а при необходимости подгружаются обратно. Этот механизм и даёт основную экономию RAM во время разработки.

React Compiler на Rust: конец ручной мемоизации

Отдельно стоит экспериментальная фича, React Compiler, встроенный прямо в Turbopack. Раньше он был известен под именем «React Forget» от Meta и решает нудную задачу: автоматизирует мемоизацию, избавляя от ручных useMemo, useCallback и React.memo. До этого его приходилось прогонять через Babel; теперь он переписан на Rust и встроен в бандлер.

Выигрыш по времени сборки страниц оценивают в 34% на холодных сборках и до 46% на тёплых. Пока это экспериментальный режим, так что в бой на проде я бы пускал с осторожностью. Но направление понятное.

TypeScript 7 на Go: один апгрейд = 10× скорости

Ещё один источник ускорения лежит вне самого Next.js. Речь о TypeScript 7, анонсированном Microsoft нативном порте компилятора на язык Go (проект под кодовым именем «Corsa»). Цель порта: примерно десятикратное ускорение проверки типов, и команда Next.js подтверждает: простой апгрейд локальной зависимости до TS 7 в конфиге даёт около 10× прироста производительности.

Это бесплатная скорость: вы не меняете код, а меняете версию компилятора, который под капотом стал в разы быстрее за счёт переезда с JavaScript на Go.

Рендеринг: нативные потоки Node.js и +22% запросов

На стороне серверного рендеринга (SSR) команда отказалась от конвертации веб-стримов в пользу нативных потоков Node.js по всему слою рендеринга. Технически это меньше накладных расходов: нативные потоки Node.js дешевле стандартных Web Streams. Практически: +22% обрабатываемых запросов без единой правки в коде приложения.

Из более мелкого, но приятного: payload bundling сокращает число pre-fetch-запросов, а кэширование статики улучшили за счёт переиспользования неизменяемых ассетов.

Мелочи, которые важны

Помимо тяжёлой артиллерии, в релизе набралась горсть удобных инструментов. Появился отладчик Instant Navigations, который подсвечивает медленные компоненты, полезно, когда непонятно, что именно тормозит навигацию. Добавили версионированную документацию, заточенную под ИИ-агентов, кастомные error boundaries и wildcard/glob-импорты, позволяющие подтягивать сразу несколько файлов одной строкой.

Миллиард загрузок против Remix, Astro и Gatsby

Контекст для тех, кто следит за раскладом на рынке фреймворков: в этом году Next.js преодолел 1 млрд загрузок, об этом сообщил CEO Vercel Гильермо Раух. Это почти вдвое больше прошлогодних ~520 млн. Из конкурентов The Register упоминает Remix, Astro и Gatsby, но по масштабу распространения Next.js играет в отдельной лиге.

Обновляться ли на Next.js 16.3: и обещанный подвох

Тот самый нюанс, ради которого стоило дочитать: Vercel заявляет полную обратную совместимость, и это редкость для мажорных обновлений, теоретически апгрейд сводится к смене номера версии. Но самые сочные цифры (10× на проверке типов и часть ускорения сборки) завязаны на смежные обновления, TypeScript 7 и экспериментальный React Compiler. Первое требует поднять локальную зависимость, второе пока помечено как экспериментальное. «Минус 90% памяти» вы получите почти даром, а за остальными метриками придётся сходить отдельно и протестировать на своём проекте.

Если ваши сборки регулярно падают в heap out of memory, обновление на Next.js 16.3 окупается уже одной экономией RAM. Проверьте свои замеры потребления памяти до и после апгрейда: на крупном проекте разница видна невооружённым глазом.

Источники

The Register, о релизе Next.js 16.3 и снижении потребления памяти