Next.js 16 вийшов восени 2025-го з новим компілятором на Rust, стабільним Partial Prerendering і нативними Server Actions з підтримкою streaming-форм. Ми мігрували три продакшен-проєкти і ділимось досвідом без маркетингового глянцю.
Що дійсно стало краще
- Час холодного білду скоротився на 35–60% завдяки Turbopack за замовчуванням
- Hot reload у проєкті з 1200+ файлами реагує за 200–400 мс
- PPR дозволяє віддавати статичний скелет миттєво і потоково підвантажувати динамічні зони
- Server Actions з useActionState прибирають 80% бойлерплейту в формах
Що зламалось
- 01next/image з зовнішніми SVG — тепер потрібен явний whitelist через remotePatterns з flag dangerouslyAllowSVG
- 02Custom server.js більше не підтримується — рефакторинг на middleware або custom route handlers
- 03Старі версії @vercel/og несумісні — потрібно оновити до 0.7+
- 04react-i18next через Server Components вимагає окремого підходу — ми перейшли на власний LanguageProvider
Що ми робимо інакше у нових проєктах
Перше — використовуємо PPR з самого старту. Це змушує думати про дані як про два потоки: статичний контекст і динамічні віджети. Структура коду стає чистішою, а Lighthouse-результати — на 8–12 пунктів вищими.
Друге — переносимо мутації на Server Actions і тримаємо API-route'и тільки для зовнішніх інтеграцій (webhook'и, callback'и платіжних шлюзів).
Next.js 16 — це перший реліз, де ми не бачимо вагомих причин залишатись на 15-й. Перформанс і DX переважують вартість міграції.
План міграції на 1–2 дні
- 01Оновити Node до 22 LTS
- 02Запустити codemod: npx @next/codemod@latest upgrade
- 03Виправити breaking changes у image, middleware і fetch-кешуванні
- 04Прогнати E2E тести і Lighthouse — фіксувати baseline до і після
- 05Деплой на staging-середовище з реальним трафіком на 24 години
Маєте подібний виклик у вашій компанії?
Розкажіть про задачу — повернемося протягом одного робочого дня з планом дзвінка.
Обговорити проєкт →