Next.js 16 для маркетингового сайту: огляд

Next.js 16 вийшов у жовтні 2025 року, і з ним маркетинговий сайт на Next.js простіше тримати швидким. Кешування тепер явне, Turbopack став бандлером за замовчуванням, а middleware перетворився на proxy.ts. Для більшості маркетингових сайтів результат такий: статичні сторінки з невеликими живими частинами, швидші збірки й менше несподіванок із кешем. Розбираємо, що змінилося і що це означає для команди, яка веде сайт.

Ми робимо маркетингові сайти на Next.js, тож пишемо з боку розробки. Зосереджуємося на змінах, що впливають на контент-команду, швидкість і бюджет, а не на кожному рядку changelog.

Що Next.js 16 змінює для маркетингового сайту на Next.js

У нотатках до релізу Next.js 16 багато змін. Для маркетингових сайтів найважливіші п’ять:

Cache Components. Нова модель, у якій ви позначаєте, що можна кешувати, директивою "use cache". Усе інше динамічне.
Turbopack за замовчуванням. Бандлер на Rust тепер стандартний для нових проєктів і в розробці, і в продакшн-збірках.
proxy.ts замість middleware.ts. Шар обробки запитів отримав зрозумілішу назву і працює на Node.js.
Зрозуміліша інвалідація кешу. revalidateTag приймає профіль кешу, а новий updateTag закриває сценарії, коли після запису в Server Action треба одразу бачити нові дані.
React 19.2. Разом із новим React приходять View Transitions і компонент Activity.

Є й несумісні зміни: мінімальна версія Node.js тепер 20.9, синхронного доступу до params і cookies більше немає, а команду next lint прибрали.

Схема запиту сторінки: спершу віддається закешована статична оболонка, а невелика динамічна частина довантажується потоком

Cache Components: статичні сторінки з живими частинами

Попередні версії App Router багато чого кешували неявно. Команди часто бачили застарілу сторінку або динамічну там, де чекали статичну, і мусили уважно читати документацію, щоб зрозуміти чому. Next.js 16 перевертає цю логіку. Коли увімкнено cacheComponents, ви самі вирішуєте, що кешувати, на рівні функції чи компонента.

Для маркетингового сайту схема проста. Контент із CMS кешується й отримує тег. Коли редактор публікує зміни, вебхук інвалідує тег.

import { cacheLife, cacheTag } from "next/cache";

export async function getPricingPlans() {
  "use cache";
  cacheLife("hours");
  cacheTag("pricing");
  const res = await fetch("https://cms.example.com/api/plans");
  return res.json();
}

Route handler, який приймає вебхук від CMS, викликає revalidateTag("pricing", "max"), і наступний відвідувач бачить новий контент. Частини, що залежать від конкретного запиту, наприклад повідомлення для регіону чи стан входу, стоять за межею Suspense і довантажуються після статичної оболонки.

Чому це важливо для бізнесу: оболонку сторінки можна віддавати з edge за мілісекунди, а редактори однаково бачать свої зміни без повної перезбірки. Це добре для Largest Contentful Paint, про який ми писали в тексті Core Web Vitals для маркетингового сайту.

Turbopack за замовчуванням: чому це помітять і редактори

У Next.js 15 Turbopack уже був стабільним для розробки. У 16 він за замовчуванням і для продакшн-збірок. Команда Next.js повідомляє про продакшн-збірки у 2-5 разів швидші і Fast Refresh до 10 разів швидший.

Швидкість збірки звучить як турбота розробників. Але на сайті з великою кількістю контенту вона доходить і до маркетингу. Швидші збірки означають швидші прев’ю, оперативніші виправлення в день запуску і менші витрати на CI. Якщо вебхук для якихось сторінок досі запускає повну перезбірку, чекати доведеться менше.

Проєкти з власною конфігурацією webpack поки можуть лишитися на webpack через прапорець. Ми вважаємо це тимчасовим кроком і плануємо перехід під час оновлення.

proxy.ts та інші перейменування

middleware.ts застарів, на зміну йому прийшов proxy.ts. Функція всередині тепер називається не middleware, а proxy. Поведінка близька до звичної: редиректи, rewrite, визначення мови й зміна заголовків до того, як запит дійде до сторінки.

import { NextResponse, type NextRequest } from "next/server";

export function proxy(request: NextRequest) {
  if (request.nextUrl.pathname === "/old-pricing") {
    return NextResponse.redirect(new URL("/pricing", request.url), 308);
  }
  return NextResponse.next();
}

Нова назва чесніше описує, що робить цей шар. Це гарний привід переглянути, що саме ваш middleware виконує на кожен запит: кожна мілісекунда тут стоїть перед кожним переглядом сторінки.

Інші зміни, які варто внести в план оновлення:

Зображення. Змінилися налаштування next/image за замовчуванням, зокрема довший мінімальний час кешу і вужчий список якостей. Перевірте свої налаштування зображень.
Маршрутизація. Дедуплікація layout і поступовий prefetch зменшують обсяг даних, які сторінка завантажує, коли відвідувач наводить курсор на багато посилань. Найбільше виграють великі меню.
React Compiler. Підтримка стабільна, але вмикається вручну. Вона зменшує потребу в ручній мемоізації. Вмикайте після того, як оновлення стабілізувалося, а не під час нього.

Чи підходить Next.js 16 для вашого маркетингового сайту?

Для багатьох маркетингових сайтів так. Next.js підходить, коли потрібен індивідуальний дизайн без обмежень шаблону, висока швидкість, кілька мов і headless CMS, яку редагує ваша команда. І ще коли маркетинговий сайт ділить компоненти з продуктом на React.

Це не єдиний добрий варіант. Невеликому сайту, який рідко змінюється, може вистачити хостингового конструктора. Команда з глибоким досвідом WordPress і купою плагінів може захотіти лишитися на ньому. Наше порівняння WordPress і Next.js, посилання на яке є в кінці тексту, розкладає компроміси пліч-о-пліч.

Якщо ви переходите з візуального конструктора, шлях міграції той самий, що й раніше, і наш гайд з міграції з Webflow на Next.js досі актуальний. Версія 16 лише спрощує правильне кешування результату.

Хронологія оновлення з Next.js 15 до 16: аудит, codemod, перегляд кешування, тестування і реліз

Оновлення з Next.js 15: що спланувати

Для типового маркетингового сайту на Next.js 15 з App Router оновлення є обмеженим за обсягом проєктом. Наш звичний порядок:

Перевірте середовище. Node.js 20.9 або новіший у CI і на хостингу.
Запустіть codemod. npx @next/codemod@canary upgrade latest бере на себе більшість перейменувань і змін в асинхронних API.
Перенесіть middleware у proxy. Перейменуйте файл і функцію, потім перевірте кожен редирект і правило мов.
Перегляньте кешування. Вирішіть, які дані кешуються, задайте профілі й теги, підключіть вебхуки CMS до revalidateTag.
Протестуйте зображення й маршрути. Порівняйте відрендерені зображення і перевірте кожну сторінку на тестовому деплої.
Виміряйте. Порівняйте час збірки й Core Web Vitals до і після.

Сайтам на Pages Router або на Next.js 13 чи 14 потрібно більше часу. Такі проєкти ми оцінюємо після короткого аудиту коду, щоб оцінка спиралася на ваш код.

Сплануйте свій маркетинговий сайт на Next.js

Корпоративні сайти ми будуємо на Next.js. Розробка корпоративного сайту коштує від 8 500 $ за 8 шаблонів сторінок і зазвичай триває 4-5 тижнів. Headless CMS, яку редагує ваша команда, і 2 раунди правок уже входять у ціну. Сайт із 10 шаблонами коштує 9 400 $. Розробка охоплює статичний рендеринг і налаштування кешу, описане вище.

Якщо ви ще обираєте платформу, почніть із нашого порівняння WordPress чи Next.js. Якщо вже обрали, надішліть нам перелік сторінок і мов, і ми відповімо протягом 4 робочих годин, з понеділка по п’ятницю, за київським часом.