Next.js 16 вийшов 21 жовтня 2025 року: Turbopack став бандлером за замовчуванням, з'явилася нова модель Cache Components на основі Partial Prerendering, а middleware.ts замінив proxy.ts (блог Next.js, 2025). Ми мігрували з Next.js 15 три продакшен-проєкти: B2B SaaS-дашборд, двомовний контентний маркетинговий сайт і e-commerce вітрину. У цьому гайді — що реально стало краще, що зламалося і план міграції, який ми тепер застосовуємо на кожному клієнтському проєкті.

Коротко: чи варто оновлюватися з Next.js 15 на 16?

Так, для більшості проєктів на App Router. Апгрейд зазвичай займає один-два робочі дні, а виграш у часі білду та швидкості локальної розробки помітний уже в перший тиждень. Основні винятки — застосунки з важкою кастомною конфігурацією webpack, код, що досі покладається на синхронний доступ до params чи cookies(), і проєкти, які використовували експериментальний прапорець PPR на canary-версії Next.js 15.

Область Next.js 15 Next.js 16
Бандлер за замовчуванням webpack (Turbopack опційно) Turbopack, --webpack для відмови
Модель кешування Неявне кешування в App Router Явне через "use cache" і cacheComponents
Перехоплення запитів middleware.ts proxy.ts на Node.js runtime
params, cookies(), headers() Async із синхронною сумісністю Тільки async
Лінтинг next lint, запускається в next build ESLint або Biome напряму
Мінімальна версія Node.js 18.18 20.9

Що дійсно стало краще

Turbopack за замовчуванням і швидші білди

Turbopack — бандлер, написаний на Rust, — стабільний і для next dev, і для next build і тепер вмикається за замовчуванням у кожному проєкті. Vercel заявляє про прискорення продакшен-білдів у 2–5 разів і Fast Refresh до 10 разів (реліз-нотатки Next.js 16). Наші цифри вкладаються в цей діапазон:

  • Холодний продакшен-білд скоротився на 35–60% у всіх трьох проєктах
  • Hot reload у проєкті з 1200+ файлами реагує за 200–400 мс
  • Файловий кеш зберігає артефакти компілятора на диску, тож перезапуск next dev у великому репозиторії більше не означає повної перекомпіляції (Turbopack FileSystem Caching)

Якщо якийсь плагін додає webpack-конфіг, next build тепер навмисно падає, а не ігнорує його мовчки. Тимчасово запускайте next build --webpack, поки переносите конфіг в опції turbopack (гайд з оновлення).

Cache Components нарешті роблять PPR придатним до використання

Partial Prerendering (PPR) дозволяє одному маршруту миттєво віддати статичний скелет і потоково довантажувати динамічні зони всередині <Suspense>. У Next.js 16 це частина Cache Components: ви вмикаєте cacheComponents: true і явно позначаєте, що можна кешувати, директивою "use cache". Усе інше за замовчуванням виконується під час запиту (документація Cache Components).

// next.config.ts
import type { NextConfig } from "next"

const nextConfig: NextConfig = {
  cacheComponents: true,
}

export default nextConfig

// app/products/[id]/page.tsx
import { Suspense } from "react"
import { cacheLife, cacheTag } from "next/cache"

async function ProductInfo({ id }: { id: string }) {
  "use cache"
  cacheLife("hours")
  cacheTag(`product-${id}`)
  const product = await db.product.findUnique({ where: { id } })
  return <ProductCard product={product} />
}

export default async function Page({ params }: PageProps<"/products/[id]">) {
  const { id } = await params
  return (
    <>
      <ProductInfo id={id} />           {/* кешується, частина статичного скелета */}
      <Suspense fallback={<StockSkeleton />}>
        <LiveStock id={id} />           {/* динамічна зона, стрімиться на кожен запит */}
      </Suspense>
    </>
  )
}

Головна зміна — у мисленні. Кешування більше не відбувається «саме собою»: ви вмикаєте його явно для кожної функції чи компонента. Це прибрало більшість тікетів «чому сторінка показує застарілі дані?», які ми регулярно отримували на Next.js 14 і 15.

Зрозуміліші API інвалідації кешу

revalidateTag() тепер приймає другим аргументом профіль cacheLife і віддає застарілий контент, поки оновлює його у фоні. Для форм, де користувач має одразу побачити свою зміну, з'явився updateTag(): він інвалідовує і перечитує дані в межах того самого запиту.

"use server"
import { revalidateTag, updateTag } from "next/cache"

export async function publishArticle(id: string) {
  await db.article.publish(id)
  revalidateTag("articles", "max") // читачі отримають свіжі дані при наступному візиті
}

export async function updateProfile(userId: string, data: Profile) {
  await db.user.update(userId, data)
  updateTag(`user-${userId}`)      // автор бачить зміни одразу
}

Server Actions прибирають більшість бойлерплейту у формах

Server Actions разом із React-хуком useActionState замінили приблизно 80% нашого рукописного коду форм: без API-маршруту, без клієнтської обгортки над fetch, без ручного стану завантаження. Також Next.js 16 постачається з можливостями React 19.2 — View Transitions і useEffectEvent (анонс React 19.2).

Менший обсяг prefetch-запитів

Роутер переписали з дедуплікацією layout'ів та інкрементальним prefetch: сторінка з 50 посиланнями на товари завантажує спільний layout один раз, а не 50 (реліз-нотатки Next.js 16). У DevTools запитів стане більше, але сумарний обсяг трафіку — значно менший.

Що зламалося під час наших міграцій

Більшість змін описана в офіційному гайді з оновлення. Ось пункти, які реально забрали в нас час.

  1. Синхронних request API більше немає. params, searchParams, cookies(), headers() і draftMode() потрібно чекати через await. Основний codemod upgrade цього не виправляє — окремо запустіть npx @next/codemod@canary next-async-request-api . і використайте npx next typegen, щоб отримати типізовані хелпери PageProps.
  2. middleware.ts став proxy.ts. Перейменуйте файл і експортовану функцію на proxy. proxy завжди працює на Node.js, тож якщо вам потрібен Edge runtime — поки залиште middleware.ts: він deprecated, але не видалений (документація proxy).
  3. Змінилися дефолти next/image. images.qualities тепер за замовчуванням [75], тож quality={90} мовчки перетворюється на 75, доки ви явно не додасте 90 у список. minimumCacheTTL зріс із 60 секунд до 4 годин, локальні зображення з query-рядком вимагають images.localPatterns, а images.domains застарів на користь remotePatterns. Зовнішні SVG, як і раніше, потребують dangerouslyAllowSVG разом зі строгим contentSecurityPolicy (довідник по Image).
  4. next lint видалено. next build більше не запускає лінтер, тому додайте окремий крок ESLint або Biome у CI. Codemod npx @next/codemod@canary next-lint-to-eslint-cli . переносить скрипт, а ESLint-плагін Next.js тепер за замовчуванням використовує flat config.
  5. Parallel routes вимагають default.js. Кожен слот потребує явного default.js, що повертає null або викликає notFound(), інакше білд падає.
  6. Runtime config видалено. serverRuntimeConfig і publicRuntimeConfig більше немає: читайте process.env на сервері та використовуйте змінні з префіксом NEXT_PUBLIC_ на клієнті.
  7. i18n у Server Components. Бібліотеки, побудовані на React-контексті, як-от react-i18next, не працюють усередині Server Components. Ми перейшли на словники, що завантажуються на сервері, і невеликий LanguageProvider для клієнтських компонентів — це патерн з гайду з інтернаціоналізації Next.js.

Кастомний Node.js-сервер у Next.js 16 досі працює (документація custom server), але вимикає частину оптимізацій. У двох із трьох проєктів ми замінили його на proxy.ts і route handlers і позбулися зайвого процесу.

Що ми робимо інакше в нових проєктах

Cache Components з першого дня. Це змушує розділяти кожну сторінку на кешований скелет і динамічні острівці. Структура коду стає чистішою, а в наших проєктах показник Lighthouse Performance зріс на 8–12 пунктів — здебільшого завдяки швидшому Largest Contentful Paint (web.dev: LCP).

Мутації — у Server Actions, API-маршрути — тільки для зовнішнього світу. Route handlers залишаємо для webhook'ів, callback'ів платіжних шлюзів і публічних API, а все, що запускає UI, переносимо в Server Actions з updateTag().

React Compiler на новому коді. Вбудована підтримка стабільна з Next.js 16, а сам компілятор досяг версії 1.0 (React Compiler v1.0). Він прибирає більшість ручних useMemo і useCallback ціною повільніших білдів, бо працює через Babel. На нових проєктах вмикаємо reactCompiler: true, на існуючих — оцінюємо окремо.

Міряємо реальних користувачів, а не вивід білду. Next.js 16 прибрав колонки size і First Load JS з виводу next build, бо для Server Components вони були неточними. Натомість ми відстежуємо Core Web Vitals у продакшені (Core Web Vitals).

Next.js 16 — перший реліз, де ми не бачимо вагомих причин залишатися на 15-й. Перформанс і DX переважують вартість міграції.

План міграції на 1–2 дні

  1. Оновіть Node.js. Next.js 16 вимагає Node.js 20.9 або новішу. Ми одразу переходимо на актуальну LTS-гілку — Node.js 22 або 24 (графік релізів Node.js) — і TypeScript 5.1+.

  2. Зафіксуйте baseline. Запишіть час білду, оцінки Lighthouse і Core Web Vitals для ключових сторінок до будь-яких змін.

  3. Запустіть codemod'и.

    npx @next/codemod@canary upgrade latest
npx @next/codemod@canary next-async-request-api .
npx next typegen

  4. Виправте breaking changes: proxy.ts, конфіг зображень, default.js для parallel routes, крок лінтингу в CI і кастомізації webpack.

  5. Вирішуйте щодо Cache Components окремо. Увімкнення cacheComponents — не просто перейменування: воно виявляє помилки білду для некешованих даних поза <Suspense>. Робіть це за гайдом з міграції в окремому PR.

  6. Прогоніть E2E-тести та Lighthouse і порівняйте з baseline. Наш шаблон пайплайна — у статті CI/CD без болю: GitHub Actions для команди до 20 розробників.

  7. Задеплойте на staging з реальним трафіком на 24 години і стежте за рівнем помилок, cache hit ratio і навантаженням CPU від оптимізації зображень.

Пов'язані гайди

Після оновлення міряйте те, що відчувають користувачі, за польовими даними — див. Core Web Vitals у 2026 році, — і перевірте метадані, sitemap і hreflang за статтею Технічне SEO для Next.js. Якщо розглядаєте застосунок, що встановлюється, порівняйте варіанти у статті PWA чи нативний застосунок.

Додаєте AI-асистента в застосунок на Next.js? Див. AI-чат на Next.js.

FAQ

Чи достатньо стабільний Next.js 16 для продакшену? Так. Turbopack, інтеграція React Compiler і нові API кешування стабільні; у статусі beta чи alpha на старті були лише файловий кеш для білдів і Build Adapters API (реліз-нотатки Next.js 16).

Чи обов'язково використовувати Turbopack? Ні. next dev --webpack і next build --webpack залишають webpack, але нові можливості з'являються спершу в Turbopack.

Чи працює Pages Router? Так. Застосунки на Pages Router теж оновлюються, але Cache Components, Server Actions і патерни з proxy — це можливості App Router.

Що буде з моїм middleware.ts? Він продовжить працювати з попередженням про застарілість. Перейменуйте його на proxy.ts, якщо вам не потрібен Edge runtime.

Джерела

  1. Vercel (2025). Next.js 16. Анонс релізу.
  2. Документація Next.js. How to upgrade to version 16.
  3. Документація Next.js. cacheComponents і Migrating to Cache Components.
  4. Документація Next.js. Proxy.
  5. Документація Next.js. updateTag, cacheLife.
  6. Документація Next.js. Image component.
  7. Команда React (2025). React 19.2 і React Compiler v1.0.
  8. Node.js. Графік релізів.
  9. web.dev. Core Web Vitals.