Розуміння компонентів кешу та часткового попереднього завантаження в Next.js 16.3
Пояснює, як функція Instant Navigations у Next.js 16.3 використовує спільні шелли маршрутів та чіткі рішення щодо стрімінгу, щоб зробити додатки, які генеруються на сервері, миттєво реагуючими.
App Router вже давно має незначну недолік у порівнянні зі спрощеними SPA, які обробляються виключно на клієнті.
Коли все виконується у браузері, переміщення між маршрутами — це просто оновлення стану, тож за визначенням воно відбувається миттєво. Рендеринг спочатку на сервері позбавляє нас цього миттєвого відчуття, але замість цього зменшує початковий об’єм даних.
Проте ви платите за цей компроміс пізніше: кожна навігація після першої означає необхідність знову взаємодіяти з сервером.
Next.js 16.3 прямо бореться саме з цією проблемою.
Ця функція називається Instant Navigations та ґрунтується на двох основних механізмах: Кешування компонентів та часткове попереднє завантаження.
Кожна функція навігації, яку коли-небудь випускав цей фреймворк, виглядала чудово на MacBook.
То що ж вона насправді робить?
Ця ідея була запозичена майже безпосередньо з дизайну односторінкових додатків. На відміну від попередніх версій, які завантажували повну копію цільової сторінки для кожного посилання заздалегідь,
Next.js тепер завантажує шаблон, який є спільним для кожного маршруту та зберігає його у кеші на клієнті. Як тільки ви натискаєте на посилання, цей шаблон відразу ж відображається, тоді як сервер передає решту контенту.
Цей шаблон свідомо залишається простим. Це макет, навігаційна рамка, заголовки та основна структура — по суті все те, що виглядає однаково незалежно від того, на яку конкретну сторінку цього маршруту ви потрапляєте. Оскільки він ніколи не змінюється, його можна безпечно зберегти в кеші та використовувати знову для десятків посилань, які всі ведуть на один і той самий маршрут.
Його можна увімкнути за допомогою двох параметрів конфігурації:
const nextConfig: NextConfig = {
cacheComponents: true,
partialPrefetching: true,
};
Очікується, що обидві прапорці стануть значеннями за замовчуванням у якійсь майбутній основній версії. Увімкнення їх сьогодні дозволяє вам бути попереду цих змін, а не опинитися у якомусь експериментальному глухому куті.
Чому це більше, ніж просто „попереднє завантаження, але швидше“
Справжня зміна тут полягає не стільки у чистій швидкості, скільки у змусі до чіткого рішення для кожного маршруту.
Next.js 16.3 вводить новий інструмент розробки під назвою Instant Insights, який автоматично позначає у вашому середовищі розробки будь-яку навігацію, яка не є миттєвою. Щоб прибрати цю позначку, кожен маршрут тепер повинен чітко вказати, що має відбутися, коли його дані ще не готові. Існує рівно три допустимі варіанти відповіді:
Транслюйте їх потоком. Обгорніть повільну частину коду в <Suspense>, щоб під час завершення роботи сервера відображалося вікно завантаження.
Збережіть у кеші. Позначте це тегом 'use cache', щоб замість очікування можна було надати раніше створену версію.
Навмисно заблокуйте це. Використовуйте export const instant = false для маршрутів, де очікування є правильною поведінкою, наприклад для підтвердження оплати, коли відображення застарілих даних буде гіршим, ніж змусити користувача трохи почекати.
Цей третій підхід заслуговує уваги. Він перетворює фразу «цей маршрут повільний» з непоміченого випадку на свідоме, задокументоване рішення. Фреймворк не вимагає, щоб кожен маршрут був миттєвим. Він стверджує, що відтепер повільність має бути навмисною, а не стандартною.
Де це справді приносить користь
Найбільш яскравим прикладом є те, де є довгий список посилань, наприклад, скринька підтримки з сорока рядками заявок. Кожна окрема сторінка заявки, ймовірно, має однакову панель інструментів, сітку метаданих та структуру розмови. Якщо завантажувати окрему сторінку для кожного посилання, доведеться завантажувати цю ідентичну спільну структуру сорок разів. Часткове завантаження наперед дозволяє завантажити цю спільну структуру один раз, використовувати її для кожного посилання, що веде до цього маршруту, та передавати лише ту частину, яка є справді унікальною — контент конкретної заявки.
Це конкретне та значуще покращення, яке добре узгоджується з тим, як насправді будуються багато панелей керування типу SaaS.
Те, що більшість оглядів пропускають
Один розробник переніс свій особистий блог на прев’ю версії 16.3 у окремій гілці, повністю впровадивши компоненти кешування та часткове попереднє завантаження, а також підтримав це набором з 19 тестів у Playwright, спрямованих саме на перевірку миттєвості навігації. Усі тести пройшли.
Після тижня постійного використання обох версій вони не змогли виявити жодної справжньої різниці.
Пояснення виявилося майже розчаровуюче простим.
Сайт вже був повністю статичним: кожна сторінка була попередньо отримана під час створення та передавалася безпосередньо з CDN. Не залишалося жодних подорожей сервером, які можна було б усунути, тож у функції миттєвої навігації не було жодних прогалин для усунення.
Те, що насправді робило сайт швидшим, було щось зовсім інше: скорочення об’єму JavaScript у форматі gzip на 341 КБ.
Це застереження, яке потрібно пам’ятати перед впровадженням цієї функції. Instant Navigations усуває затримку між натисканням посилання та переглядом контенту саме для динамічних маршрутів, які залежать від сервера.
Якщо ваш додаток вже є статичним або вже працює швидко з інших причин, ви будете впроваджувати функцію для вирішення проблеми, якої у вашому випадку немає.
Спочатку спробуйте її на тих маршрутах, де справді відчувається повільність, а не поширюйте її на весь сайт, та вимірюйте результати на обмеженому середньої потужності Android-з’єднанні, а не на ноутбуці з швидким офісним Wi-Fi. Коментар щодо MacBook на початку варто пам’ятати: майже кожна функція навігації, яку коли-небудь запроваджував цей фреймворк, виглядала вражаюче на MacBook.
Ця платформа не вимагає, щоб кожен маршрут працював миттєво. Вона стверджує, що відтепер повільна робота має бути навмисною, а не стандартною.
Що насправді потрібно робити
Якщо ви вже використовуєте Next.js 16.x та навігація здається повільною, почніть з невеликих кроків. Увімкніть функцію часткового попереднього завантаження лише для двох-трьох найбільш завантажених маршрутів, перш ніж поширювати її на інші. Більша частина користі походить від попередньої підготовки, а тестування в обмеженому діапазоні також допоможе з’ясувати, чи справді ваші лейаути були належним чином відокремлені від процесу отримання даних, що для багатьох реальних кодових баз виявляється ще кориснішим висновком.
Якщо ви все ще користуєтесь Pages Router та вагаєтесь щодо міграції, ця функція не повинна стати вирішальним фактором. Справжніми причинами для переходу є те, що Turbopack стає стандартом для розробки, а також більша стабілізація App Router. Instant Navigations — це додаткова перевага, яку ви отримуєте пізніше, а не причина починати міграцію з самого початку.
А якщо ваш додаток вже повністю статичний, просто пропустіть міграцію.
Краще шукайте свої власні 341KB.
Пов’язана література
- 20 передових патернів Next.js для додатків App Router виробничого рівня — Дізнайтеся про двадцять патернів високого рівня для Next.js, які охоплюють серверно-орієнтоване проектування, стрімінг, кешування, маршрутизацію та оптимізацію продуктивності для створення швидших та масштабованих додатків.