Зміст
Коротко
Turbopack у Next.js збирає клієнтський JavaScript не в один файл, а в багато фрагментів бандла: власний код, залежності й середовище виконання. У блозі Next.js пояснюють, чому «все в одному файлі» і «файл на кожен модуль» однаково погані на довгій дистанції — і як злиття фрагментів усередині групи балансує розмір завантаження та кількість мережевих запитів. У Next.js 16.3 з’явилися експериментальні важелі: розумний вибір уже завантажених шматків, налаштування під реальні маршрути, видалення невикористовуваного коду в модулях CommonJS і спільний фрагмент середовища виконання.
Що сталося
Крайнощі прості. Один величезний файл добре кешується, але тягне код усіх сторінок навіть на «легкий» маршрут. По файлу на сторінку — без зайвого коду, зате спільний <Footer /> завантажується знову й знову. По файлу на модуль — нічого зайвого й чудовий кеш, але сотні дрібних запитів: накладні витрати HTTP і гірше стиснення, ніж у великих файлів.
Turbopack об’єднує дрібні фрагменти в більші, але лише всередині групи фрагментів — набору, що завжди вантажиться разом (наприклад, усе для /home чи /blog). Так не можна «донавантажити» на сторінку код, який їй не потрібен: усередині групи він і так уже в плані завантаження. Рішення «зливати чи ні» зважує сценарії: людина відкрила одну сторінку й пішла, чи пішла далі сайтом. Злиття спільного й вузького модуля вигідне при одному заході; при переході на сторінку, де потрібен лише спільний шматок, браузер може скачати спільне повторно — бо воно вже «склеєне» з непотрібним.
На сайті nextjs.org порівняли три режими: без злиття, налаштування за замовчуванням і «все в групі в один файл». Умовчання зрізали кількість запитів більш ніж удвічі за трохи меншого обсягу коду; максимальне злиття дало ще менше запитів, але приблизно на 10% більше скачаного JavaScript на довгій сесії.
Чому це важливо
Поділ на фрагменти — не «налаштування збирача заради краси», а прямий компроміс між першим екраном, кешем і м’якою навігацією. Збірка вирішує злиття до візиту й не знає, що вже лежить у кеші браузера; алгоритм ще й вгадує частку односторінкових сесій (у статті — близько двох третин). Звідси розрив між «швидким першим заходом» і «дешевими наступними переходами».
Для команди на Next.js це пояснює, чому «просто зменште число фрагментів» або «дробить усе дрібніше» без урахування маршрутів часто погіршують картину. Нові прапорці в 16.3 якраз закривають сліпі зони: середовище виконання може обрати дешевше — злитий файл чи відсутні шматки; конфіг може підказати реальні кластери сторінок замість універсальної здогадки.
На практиці
- Оновіться до
Next.js16.3+ і читайте опції підexperimental.turbopackChunkingуnext.config.js, а не копіюйте чужі «магічні» числа. - Увімкніть
generateComponentChunks: поруч зі злитими фрагментами емітяться незлиті; під час запиту обирається дешевший варіант з урахуванням уже завантаженого. - Підставте свою аналітику:
firstPageLoadPriority(за замовчуванням0.67),priorityRoutesдля важливих URL,clusters— групи маршрутів, які ходять разом. - Для меншого обсягу клієнта:
experimental.turbopackCjsTreeShaking(видалення невикористовуваного коду вCommonJS; раніше стабільно працював переважноESM) іexperimental.turbopackSharedRuntime— один спільний фрагмент середовища виконання замість окремого на кожну сторінку (близько 10 КБ і один блокувальний запит на наступних переходах). - Міряйте на своїх сценаріях навігації: на маркетинговому сайті з високим «відскоком» вигідніше інше злиття, ніж у кабінеті з довгими сесіями.
Підсумок
Хороший поділ JavaScript — це не максимум і не мінімум файлів, а свідомий компроміс усередині груп фрагментів плюс дані про те, як люди реально ходять застосунком. Експериментальні опції Turbopack у Next.js 16.3 дають шанс наблизити збірку до кешу браузера й до вашої карти маршрутів — варто вмикати їх свідомо й перевіряти замірами, а не «наосліп на все».