Bundle analyzer: знаходимо причину роздутого бандла
Типова картина: продукт розвивається, можливостей стає більше — і стартовий пакет зростає швидше, ніж сама функціональність.
Перший екран вантажиться довше, на слабкому мобільному з’єднанні користувач іде до відмальовування, а частка відмов на вході в застосунок зростає разом з обсягом завантажуваного коду.
Причини при цьому майже ніколи не лежать на поверхні.
У вихідниках — охайні модулі та невеликі компоненти, а в зібраний пакет потрапляють дві версії однієї бібліотеки, що прийшли транзитивно; важка утиліта, з якої використовується одна функція; повні набори локалей і поліфілів, потрібні лише частині аудиторії. За кодом цього не видно: розмір зростає не там, де ви правили.
Bundle analyzer відповідає на інше питання — не «стало більше», а «що саме займає частку і хто це притягнув». Інструмент будує карту модулів, де площа блока пропорційна його внеску в розмір пакета, і поруч із вашою кодовою базою опиняються залежності, яких ви не писали.
webpack-bundle-analyzer і source-map-explorer дивляться на завдання з двох боків: перший показує структуру зібраних чанків і зв’язки між ними, другий розгортає готовий файл назад до вихідних модулів за картами коду.
Разом вони відокремлюють розрослу залежність від вашої власної логіки, а заодно знаходять дублювання.
Далі починається оптимізація збірки: розділення за маршрутами, винесення рідкісних блоків у відкладене завантаження, точкові імпорти замість цілих бібліотек, заміна важких пакетів на легкі аналоги.
Порядок робіт підказує сама карта — спочатку те, що дає найбільшу частку, бо саме там час завантаження скорочується найпомітніше. Розбираємо, як це влаштовано і що отримує продукт на виході.
Що дає оптимізація бандла: швидкість, конверсія, підтримка
Оптимізація бандла починається з відповіді на питання, що саме йде в браузер.
Інструменти на кшталт bundle analyzer показують дерево модулів і вагу кожної гілки, тому рішення ухвалюються за цифрами: де дублюються залежності, де підключено цілу бібліотеку заради однієї функції, що не використовується в робочій версії.
Що бачить замовник: швидкість, Core Web Vitals, конверсія
Прибираємо дублі залежностей, дробимо код за маршрутами, рідко потрібне виносимо окремими частинами й підвантажуємо на вимогу.
Обсяг передаваних файлів падає в 1,5–3 раза, перше відмальовування на мобільних прискорюється на 30–60%, а Core Web Vitals переходять у зелену зону замість балансування на межі.
З конверсією зв’язок прямий: кожен зайвий крок завантаження втрачає частину відвідувачів, і повернути їх дорожче, ніж один раз охайно розкласти завантаження за етапами. Форми, каталог і кошик встигають відмалюватися раніше, ніж користувач піде до конкурента.
Що бачить команда: сервер і підтримка
Менше байтів у віддачі — нижче навантаження на сервер і канал, статика довше живе в кеші, пікові звернення проходять без розширення потужностей.
Підтримка спрощується: межі модулів видно, зростання ваги помітне на кожному релізі, а регрес через один пакет знаходиться за хвилини, а не за день пошуку.
Кожен реліз залишає звіт щодо складу збірки, тому вага не зростає непомітно, а спірні рішення знімаються цифрами.
Способи аналізу та оптимізації бандла: порівняння
Візуальна карта збірки й карта вихідників відповідають на одне питання по-різному. Перша показує, що займає місце в графі модулів, друга — що реально поїхало користувачу після оптимізації. Тому їх застосовують разом, а не обирають одне замість іншого.
Візуальний аналіз збірки
webpack-bundle-analyzer читає статистику збірки й малює ієрархію чанк → модуль → залежність: це швидкий спосіб зрозуміти, чому бандл виріс після чергової зміни.
Обмеження — карта відображає стан до фінальної оптимізації, і код, вирізаний tree shaking, усе ще видно в ній як зайвий.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Візуальна карта збірки | Регулярна перевірка після релізів, пошук великих залежностей | Стан до фінальної оптимізації: вирізаний код виглядає як зайвий |
| Аналіз карти вихідників | Розбір продакшн-збірки: що доставлено користувачу | Потрібні коректні source map, структура чанків не видна |
| Ручний аудит залежностей | Підозра на дублікати версій і важкі транзитивні пакети | Повільно, без автоматизації в збірці не масштабується |
Карта вихідників і аудит залежностей
source-map-explorer рахує внесок кожного вихідного модуля в готовий артефакт — тільки так видно, що видалення невикористовуваного коду справді спрацювало.
Ручний аудит залежностей закриває решту: обхід дерева пакетів виявляє кілька версій однієї бібліотеки й транзитивні модулі, що тягнуть за собою весь пакет. Порядок роботи — візуальна карта як швидкий зріз, карта вихідників для перевірки гіпотез, аудит там, де причина неочевидна.
Як ми проводимо оптимізацію бандла: етапи робіт
Оптимізація йде від вимірювань, а не від смакових правок у конфігурації збірки. Поки немає карти залежностей і цифр із завантаження, будь-яка зміна залишається здогадом, який неможливо ні захистити, ні повторити.
Аудит і план оптимізації
Знімаємо метрики на збірці, близькій до продакшн: розмір основного й відкладених фрагментів, частка сторонніх бібліотек, час до першого відмальовування на мобільній мережі.
Потім будуємо карту залежностей через bundle analyzer і звіряємо її з source-map-explorer — другий показує вихідні модулі, а не лише пакети, і саме на цій розбіжності спливають дублі версій однієї бібліотеки.
План оптимізації — це список правок, відсортований за тим, скільки кожна знімає з критичного шляху завантаження.
- Аудит бандла: шукаємо дублі, мертвий код і бібліотеки, підключені цілком заради однієї функції.
- Пріоритизація: сортуємо знахідки за ефектом і вартістю правки — у план потрапляє те, що дає вимірюваний результат.
- Упровадження: ділимо збірку на фрагменти, виводимо важкі модулі у відкладене завантаження, замінюємо невиправдано великі залежності.
- Контроль за кроками: після кожної правки звіряємо метрики з точкою відліку й відкочуємо те, що не зняло регрес.
- Перевірка результату: прогін на тестовому середовищі й порівняння до/після за розміром фрагментів і часом до першого відмальовування.
- Передача: правила в конфігурації й пороги в перевірках збірки, щоб розмір не відростав назад.
На виході залишається не разова правка, а керований розмір завантаження: карта залежностей, зрозуміла команді розробки, і пороги, які ловлять регрес на етапі збірки, а не в продакшені.
Що ви отримуєте на руки після оптимізації
Після оптимізації в команди залишається не «стало швидше», а набір артефактів, за якими стан збірки можна перевірити й відтворити.
Звіт щодо бандла й карта залежностей лежать поруч із кодом, конфігурація описана словами, а правила підтримки зафіксовані в регламенті — результат живе довше за один реліз і не розсипається під час наступних правок.
Що залишається в проєкті
- Звіт щодо бандла — знімки bundle analyzer до й після правок: обсяг модулів, склад початкового завантаження, винесені частини.
- Карта залежностей — граф зв’язків із позначкою дублів і бібліотек, які тягнуться двома версіями одразу.
- Оновлена конфігурація збірки — правила розбиття на частини, стиснення, видалення невикористовуваного коду, точки динамічного підвантаження.
- Коментарі до параметрів — що дає кожен режим і що зламається, якщо його прибрати.
Що фіксуємо в регламенті
- Поріг обсягу початкового завантаження, після якого збірка вважається деградованою.
- Команда запуску аналізатора перед релізом і місце, куди складається звіт для порівняння.
- Документація архітектури завантаження: які частини застосунку вантажаться одразу, які на вимогу.
- Інструкція для нового інженера: де відкрити звіт і як відрізнити нормальне зростання обсягу від регресу.
Такий набір знімає головну проблему підтримки — знання залишається в репозиторії, а не в голові одного розробника. Перевірити деградацію можна за один запуск, відкотити невдалу зміну — за конкретним списком винесених частин, а не методом перебору.
Кейс: скорочення бандла й прискорення завантаження
Проєкт — інтернет-магазин із каталогом на кілька тисяч позицій.
Бандл зростав від релізу до релізу: на перший екран ішло близько 2,9 МБ стисненого коду, час до інтерактивності на середньому мобільному пристрої тримався в районі 6 секунд, а частина відвідувачів ішла, не дочекавшись відмальовування каталогу.
Що показав розбір
Зібрали карту бандла через webpack-bundle-analyzer і звірили її з вихідними картами через source-map-explorer.
Картина виявилася типовою: дві копії бібліотеки маршрутизації, повний пакет дат заради двох функцій форматування й весь каталог із фільтрами в одному чанку разом із кодом головної. За вихідниками було видно, що недосяжний код займає близько третини загального обсягу.
Що змінили
Важкі маршрути — картку товару, оформлення замовлення, особистий кабінет — перевели на динамічний імпорт, частина віджетів підвантажується за дією користувача. Дублі звели до однієї копії, замість повного пакета дат підключили точкові функції.
Спільний вендорний код винесли в окремий чанк із тривалим кешуванням, щоб він не перекачувався за кожного релізу.
У результаті бандл скоротився з 2,9 МБ до 980 КБ, критичний шлях першого екрана — до 480 КБ, час до інтерактивності на мобільних упав з 6 до 2 секунд, частка відмов на етапі завантаження скоротилася втричі.
«Віддача зросла майже одразу, а команда перестала боятися додавати нові блоки», — зазначає технічний директор замовника.
Bundle analyzer: чим відрізняється від інших методів аналізу?
Bundle analyzer працює не з вихідним кодом, а зі зібраним артефактом: він розбирає карту модулів усередині чанків і показує, що саме обтяжує збірку.
Видно, які бібліотеки потрапили одразу в кілька чанків, де один модуль продубльований під різними шляхами і скільки важить кожна частина до й після стиснення. Це відповідь на питання «з чого складається те, що завантажує браузер».
Статичний аналіз дивиться в інший бік — на вихідники й граф імпортів до збірки. Він знаходить залежності, підключені заради однієї функції, експорти, які ніхто не викликає, і ланцюжки, що тягнуть за собою половину дерева модулів. В артефакті такий код уже злитий із робочим, тому bundle analyzer покаже слід, але не причину.
Профілювання — єдиний метод, який дивиться на поведінку під час виконання. Воно показує, скільки часу йде на розбір і виконання скриптів під час першого показу, які модулі спрацьовують до відмальовування й де виникають довгі завдання, що блокують інтерфейс. Ці цифри про відчуття користувача, а не про вагу файлів.
Порівняння методів зводиться до різних питань: аналіз бандла — «що лежить у чанку», статика — «чому це там опинилося», профілювання — «що з цього реально болить».
Починаємо з профілювання за скаргою на повільне завантаження, bundle analyzer підтверджує склад і обсяг, статичний аналіз доводить до правки у вихідниках. Жоден крок не замінює решту — розбір іде ланцюжком, а не одним інструментом.
Часті технічні питання щодо оптимізації бандла
Оптимізацію збірки відкладають частіше не через складність, а через сумніви: чи не поїде вже працюючий продукт, коли чекати ефекту й що робити з динамічними розділами. На кожне з цих питань є інженерна відповідь.
Правки збірки не зламають поточний реліз?
Спочатку фіксуємо вихідну картину аналізатором: вагу фрагментів, дублі залежностей, найважчі модулі. Правки йдуть окремими кроками — від безпечних (усунення дублів бібліотек, винесення вендорів у спільний фрагмент) до тих, що зачіпають порядок завантаження.
Кожен крок перевіряється за ключовими сценаріями до викату, а відкат — це повернення попередньої збірки.
Коли буде видно ефект?
Розмір артефактів змінюється одразу після правок конфігурації — це видно у звіті аналізатора на кожній збірці.
На швидкість завантаження в реальних відвідувачів впливають кеш браузерів і різна якість зв’язку, тому рішення ухвалюємо за вимірами за один-два тижні, а не за одним вдалим прогоном.
Що робити з динамічними модулями?
Динамічний імпорт переносить вагу з першого завантаження на момент, коли відвідувач відкриває розділ. Ризик тут один: спільна бібліотека потрапляє одразу в кілька фрагментів, і сумарна вага зростає. Аналізатор показує такі перетини, а налаштування спільних груп їх розводить.
Чи потрібно публікувати карти коду в продакшені?
Публічний доступ до них — зайва поверхня для розбору застосунку ззовні. Карти йдуть у закрите сховище й підключаються до системи збору помилок: стек викликів залишається читабельним для інженерів, а відвідувачу віддається лише зібраний код.
Обговорімо оптимізацію вашого бандла
Збірка — це місце, де інженерні рішення видно в цифрах: скільки важить початковий файл, що потрапляє на перший екран, які залежності дублюються між частинами застосунку. Щоб говорити предметно, а не «на око», перший дзвінок ми будуємо як розбір вашого проєкту разом із вами. Опишіть завдання — повернемося з оцінкою та планом робіт.
На дзвінку ми:
- знімемо поточні метрики збірки: вагу початкового файлу, час до першого екрана, кількість окремих частин;
- прогонимо bundle analyzer і source-map-explorer по актуальній гілці та розберемо карту залежностей — де дублі, де важкі бібліотеки, підключені заради однієї функції;
- подивимося маршрути й точки входу: що вантажиться одразу, а що розумно відкласти до першої дії користувача;
- перевіримо конфігурацію: розбиття на частини, повторне використання спільних модулів, кешування на боці клієнта;
- уточнимо обмеження: підтримка старих браузерів, вимоги до відкату, обов’язкові перевірки перед викладкою;
- узгодимо пріоритети та зафіксуємо план робіт з очікуваним ефектом у вимірюваних величинах.
Після дзвінка ви отримуєте оцінку за етапами й порядок дій: що дає результат одразу, а що потребує перебудови маршрутів. Обсяг і строки залежать від того, скільки ваги накопичилося й наскільки пов’язаний код, — це ми проговорюємо до старту.
