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 по актуальной ветке и разберём карту зависимостей — где дубли, где тяжёлые библиотеки, подключённые ради одной функции;
- посмотрим маршруты и точки входа: что грузится сразу, а что разумно отложить до первого действия пользователя;
- проверим конфигурацию: разбиение на части, повторное использование общих модулей, кэширование на стороне клиента;
- уточним ограничения: поддержка старых браузеров, требования к откату, обязательные проверки перед выкладкой;
- согласуем приоритеты и зафиксируем план работ с ожидаемым эффектом в измеримых величинах.
После созвона вы получаете оценку по этапам и порядок действий: что даёт результат сразу, а что требует перестройки маршрутов. Объём и сроки зависят от того, сколько веса накопилось и насколько связан код, — это мы проговариваем до старта.
- Просят «просто сжать» скрипты, не выясняя причину: уменьшение размера файла без диагностики убирает следствие, и лишний вес возвращается с первой же доработкой.
- Перекладывают на сборку чужие проблемы: медленный ответ сервера, тяжёлые изображения и сторонние виджеты остаются нетронутыми, а правят только клиентский код.
- Задают произвольный ориентир по весу файлов, не замеряя, как страница ведёт себя у реальных посетителей на слабом соединении и старом устройстве.
- Запрещают удалять «на всякий случай» неиспользуемые библиотеки и старые модули — и при этом ждут кратного сокращения объёма.
- Не публикуют карту исходников и не хранят её отдельно: после сжатия ошибки в браузере посетителя невозможно разобрать по нормальным именам.
- Считают оптимизацию разовым мероприятием: правило проверки веса при каждом выпуске не заводят, и через несколько доработок всё возвращается к прежнему объёму.
- Не дают доступ к среде или копии проекта, ограничиваясь скриншотами и пересказом со слов — диагностика идёт вслепую, сроки растягиваются.
