Анализ бандла через rollup-plugin-visualizer

Разбор итогового бандла является ключевым этапом оптимизации современных фронтенд-приложений, особенно при использовании инструментов сборки наподобие Vite, где сборка production-артефактов основана на Rollup. Одним из наиболее информативных способов визуального анализа структуры бандла выступает использование плагина rollup-plugin-visualizer, который позволяет получить детализированную карту зависимостей и распределения кода по чанкам.

Плагин строится на анализе графа модулей, формируемого Rollup в процессе сборки. Каждый импортируемый модуль рассматривается как узел графа, а зависимости между ними — как рёбра. После завершения сборки плагин агрегирует данные о размерах модулей, их включении в конкретные чанки и степени вложенности.

Результатом работы становится интерактивный отчёт в одном из визуальных форматов:

  • treemap (дерево прямоугольников)
  • sunburst (радиальная диаграмма)
  • network (граф связей)

Каждый формат отражает одни и те же данные, но с разной степенью акцента на структуру или пропорции.

Установка и подключение в Vite-проекте

Так как Vite использует Rollup для production-сборки, интеграция осуществляется через конфигурационный файл vite.config.js или vite.config.ts.

Основная зависимость:

npm install rollup-plugin-visualizer -D

Подключение выполняется внутри конфигурации сборки:

import { defineConfig } from 'vite'
import { visualizer } from 'rollup-plugin-visualizer'

export default defineConfig({
  plugins: [
    visualizer({
      filename: 'dist/stats.html',
      open: true,
      gzipSize: true,
      brotliSize: true,
    })
  ]
})

Параметр filename определяет путь к итоговому отчёту. При включённой опции open отчёт автоматически открывается после сборки. Включение gzipSize и brotliSize позволяет оценить реальный размер ассетов после сжатия, что критически важно для анализа сетевой нагрузки.

Структура отчёта и интерпретация данных

Отчёт представляет собой HTML-файл с интерактивной визуализацией. Основной элемент — блоки, пропорциональные размеру модулей.

Treemap-структура

В treemap-режиме каждый модуль отображается в виде прямоугольника, площадь которого соответствует его размеру в бандле. Иерархия вложенности отражается через группировку:

  • верхний уровень — чанки
  • внутри чанков — зависимости
  • внутри зависимостей — вложенные импорты

Ключевая особенность заключается в визуальном выявлении «тяжёлых» модулей, которые занимают непропорционально большую часть бандла.

Анализ повторяющихся зависимостей

Одной из наиболее ценных функций является выявление дублирующихся библиотек. Например, разные части приложения могут импортировать различные подмодули одной и той же библиотеки, что приводит к частичному дублированию кода.

Визуализатор позволяет обнаружить такие случаи по повторяющимся сегментам дерева. Это особенно актуально при работе с:

  • lodash и его модульными импортами
  • moment.js или date-fns
  • UI-библиотеками с глубокой модульностью

Влияние code splitting на визуализацию

При использовании динамического импорта (import()) структура бандла становится более фрагментированной. В отчёте это выражается в появлении множества отдельных чанков.

Каждый чанк отображается как самостоятельный блок, что позволяет оценить:

  • корректность разбиения по маршрутам или компонентам
  • наличие чрезмерно крупных lazy-loaded модулей
  • баланс между initial bundle и async chunks

Если основной чанк остаётся слишком большим, это сигнализирует о недостаточной декомпозиции кода.

Работа с внешними зависимостями

Vite по умолчанию оптимизирует зависимости через esbuild и Rollup, но визуализатор позволяет оценить, какие пакеты оказывают наибольшее влияние на итоговый размер.

Типичная картина:

  • UI-библиотеки (React, Vue, Svelte runtime) занимают значительную долю
  • utility-библиотеки часто оказываются неоправданно крупными
  • polyfills могут незаметно увеличивать базовый слой

Особое внимание уделяется анализу tree-shaking. Если библиотека поддерживает tree-shaking корректно, в отчёте будут отсутствовать неиспользуемые части. Если нет — можно наблюдать включение целых модулей без необходимости.

Gzip и Brotli как инструмент реальной оценки

Размер исходного бандла не отражает фактическую нагрузку на сеть. Визуализатор позволяет учитывать сжатие:

  • gzip — стандартное HTTP-сжатие
  • brotli — более эффективный алгоритм, используемый современными CDN

Разница между raw size и compressed size часто составляет 60–80%. Это позволяет корректнее оценивать влияние оптимизаций.

Например, модуль размером 500 KB может после сжатия занимать 120 KB, что существенно меняет приоритет оптимизации.

Определение проблемных зон

Визуальный анализ позволяет выделить несколько типичных проблем:

Крупные единичные модули

Если один модуль занимает непропорционально большую часть бандла, это сигнал к его декомпозиции или замене альтернативой.

Глубокая вложенность зависимостей

Чрезмерно сложная цепочка импортов усложняет tree-shaking и увеличивает итоговый размер.

Дублирование функциональности

Несколько библиотек, решающих одну задачу (например, разные утилиты для работы с датами), часто приводят к избыточному коду.

Использование в CI/CD процессе

Визуализатор может быть интегрирован в pipeline сборки для автоматического контроля роста бандла. В таком сценарии отчёт генерируется на каждом билде и сохраняется как артефакт.

Это позволяет отслеживать:

  • постепенное увеличение размера бандла
  • влияние новых зависимостей
  • деградацию оптимизации после изменений кода

При необходимости можно дополнительно сравнивать отчёты между версиями, выявляя конкретные изменения в структуре сборки.

Связь с архитектурными решениями

Данные визуализатора напрямую отражают архитектуру приложения. Монолитная структура компонентов приводит к плотному и малоразделённому бандлу. Модульная архитектура с чётким разделением ответственности формирует более равномерное распределение.

Особенно хорошо это видно в приложениях, где:

  • используются feature-based директории
  • разделены UI и бизнес-слои
  • применяется lazy loading по маршрутам

В таких случаях treemap становится визуальным подтверждением корректной архитектуры.

Практическая интерпретация изменений

При внесении изменений в проект визуализатор позволяет оценивать их влияние не абстрактно, а количественно:

  • добавление новой библиотеки → увеличение конкретного сегмента
  • рефакторинг импортов → уменьшение дублей
  • внедрение динамических импортов → перераспределение чанков

Это превращает оптимизацию из интуитивного процесса в измеряемую процедуру, основанную на данных.

Оглавление