Веб-разработка

Next.js 15: что изменилось на самом деле и как проверить это на своем проекте

Turbopack, кэширование fetch по умолчанию, асинхронные params и то, что из этого действительно доходит до посетителя. Плюс четыре команды для проверки собственного проекта.

1 августа 2026 г.
3 мин чтения

О Next.js 15 писали в основном в жанре «революция». Дальше – без этого. Разберем, что именно изменилось в релизе, какие изменения ломают рабочий код молча, и как за пол часа проверить, получает ли ваш проект вообще из новой версии что-то, кроме номера в package.json.

Turbopack: скорее, но не там, где вы думаете

Turbopack получил стабильный статус для next dev – это зафиксировано в официальных release notes Next.js. Вместо полной перестройки графа модулей после каждой правки он перебирает только то, что изменилось, и держит результат в памяти между сборниками.

Как быстрее станет лично у вас – зависит от количества модулей, глубины импортов, набора CSS-обработчиков и скорости диска. Сравнительной таблицы «было/столо» здесь не будет: цифры с чужого ноутбука на чужом проекте ничего не говорят о вашем. Замерьте сами - time перед запуском dev-сервера, затем переключите флажок и повторите на том же коде.

И главное, о чем обычно молчат. Скорость dev-сервера не имеет никакого отношения к тому, как скоро сайт откроется у посетителя. Turbopack работает на вашей машине при разработке. Посетитель видит продакшн-сборник, отданный с сервера в другой стране, по мобильной сети, на телефоне пятилетней давности. Это два разных мира, и ускорение первого не улучшает второй ни на миллисекунду.

Что действительно влияет на скорость у посетителя

Между щелчком и появлением контента человек не видит ничего. Чем длиннее эта пауза, тем большая часть людей закрывает вкладку — и эти люди не увидят ни товара, ни цены, ни формы. Скорость не продает. Она определяет, скольким людям ваше предложение вообще покажут.

Технически здесь два рычага: TTFB (время до первого байта – кэширование, запросы к базе, настройка сервера) и вес HTML, который браузер должен загрузить в первый рендер. Next.js помогает с обоими, но работу за вас не делает.

Наши замеры на живых сайтах сделаны внешне через curl 31.07.2026:

  • корпоративный одностраничный сайт консалтинговой компании на Next.js - TTFB 254 мс, полный документ за 342,6 мс, HTML 102,1 КБ;
  • SaaS-платформа для рерайта описаний товаров – TTFB 220,6 мс при 141 КБ HTML.

Это наше измерение, и это состояние сервера, а не бизнес-показатель клиента. Честный предел здесь таков: TTFB – только серверная часть. Полное время до интерактивности у настоящего посетителя зависит еще от его устройства, сети, веса картинок и посторонних скриптов, которые подключили уже после нашего замера. И еще важнее: сайт, открывающийся за 200 мс, просто быстрее покажет человеку причину уйти, если цена выше рынка или товара нет налицо. Скорость убирает техническую утрату. Спроса она не создает.

Кэширование: fetch больше не кэшируется по умолчанию

Самая тихая смена релиза. У Next.js 14 результат fetch() по умолчанию кэшировался, у 15-й – нет. То же с GET-обработчиками в Route Handlers и с клиентским кэшем роутера.

Ломается это без ошибок. Код работает, тесты проходят, а сервер начинает ходить в API по каждому запросу вместо одного раза в минуту. Замечают обычно по счету от хостинга или по TTFB, выросшему втрое после обновления.

Что делать при миграции: пройтись по всем fetch() в серверных компонентах и ​​проставить намерение явно.

Теги

Next.jsReactTypeScriptPerformance

🤔Вам понравилась статья?

Ваше мнение помогает нам создавать лучший контент

Поделитесь с друзьями

Нашли что-нибудь полезное? 🚀

Помогите другим узнать это — поделитесь статьей в социальных сетях

https://lionex.com.ua/blog/nextjs-15-new-features

💚 Спасибо, что помогаете нам расти

Владислав Чистяков

Пишет о том, что делает руками: интернет-магазины на OpenCart, приложения на Next.js, интеграции и скорость сайтов. В статьях — замеры и проверки, которые читатель может повторить на своём проекте, а не общие советы. Коммерческая разработка с 2015 года.

Частые вопросы

Ответы на популярные вопросы по теме

Само по себе обновление не делает сайт быстрее для посетителя — это смена инструмента, а не результата. Веский повод появляется тогда, когда вы упираетесь во что-то конкретное: долгие сборки, потребность в возможностях React 19 или зависимость, которая больше не поддерживает старую версию. Если ничего из этого нет, спокойно оставайтесь на 14 и планируйте переход на время, когда он никому не помешает.

Нет. Turbopack ускоряет сборку проекта у разработчика — холодный старт и перезагрузку после правки. На то, что видит посетитель, он не влияет вовсе: в браузер едет результат сборки, а не инструмент, которым её сделали. Скорость страницы решают другие вещи — время ответа сервера, вес изображений, количество скриптов.

Две вещи. Первая — params, searchParams, cookies и headers стали асинхронными, и код, читавший их напрямую, тихо перестаёт работать. Вторая и более коварная — fetch больше не кешируется по умолчанию: страницы, которые раньше отдавались из кеша, начинают ходить в базу на каждый запрос. Сайт при этом не падает, он просто становится медленнее, и связь с обновлением замечают не сразу.

Версия фреймворка не является фактором ранжирования, и обещать здесь нечего. Влияние возможно лишь косвенное: если после перехода страницы стали отдаваться быстрее, это видно в показателях скорости, которые Google действительно учитывает. Но тот же результат достигается и без миграции, а неудачное обновление способно скорость ухудшить.

За полчаса и без сторонних сервисов: посмотреть, не читаются ли params синхронно, проверить, какие запросы идут в базу на каждый рендер, и сравнить время ответа страницы до и после. В статье это расписано по шагам. Если после проверки остались сомнения — напишите, посмотрим вместе; разбор задачи бесплатный.

Получайте лучшие статьи на почту

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

Мы уважаем вашу конфиденциальность. Отписаться можно в любой момент.

Похожие статьи

Все статьи
Сертификаты продлеваются сами: TLS на 116 сайтах и один, который не продлился
Веб-разработка

Сертификаты продлеваются сами: TLS на 116 сайтах и один, который не продлился

22 сентября 2026 года мы проверили HTTPS-сертификаты на 116 сайтах, которые уже измеряли для рыночных исследований, и для 104 из них сравнили состояние с августовским. Все 116 прошли проверку, 108 стоят на 89- и 90-дневных бесплатных сертификатах, и только у одного сайта сертификат до сих пор не продлился, хотя при типичных настройках уже должен был. Разбираем замеры, границы метода и показываем, как проверить свой сайт одной командой.

9 мин
22 сент.
Читать дальше
Healthcheck дал 60 % запросов приложения: что показали первые сутки метрик
Веб-разработка

Healthcheck дал 60 % запросов приложения: что показали первые сутки метрик

21 сентября 2026 года, в первые сутки учёта запросов по маршрутам, служебный /api/health получил 13 666 запросов — 60 % трафика приложения, и каждый шёл в общую базу. Рассказываем, какие две настройки это убрали, какую цену мы за них платим и как проверить свой healthcheck.

9 мин
22 сент.
Читать дальше
154 ошибки типов, которые выбрасывала сборка: что в них нашлось
Веб-разработка

154 ошибки типов, которые выбрасывала сборка: что в них нашлось

21 сентября 2026 года проверка типов на нашем сайте показала 154 ошибки, хотя сборка каждый раз была зелёной: результат проверки просто выбрасывался. Внутри нашлись нули в статистике ссылок и в экспорте аналитики, сортировка, которая не сортировала, и тесты, которые не запускались. Рассказываем, как разбирали, что изменили и как проверить свой проект.

9 мин
22 сент.
Читать дальше