Размер бандла: анализ состава и сокращение

Прямой ответ

Объём сборки определяется составом зависимостей и способом их включения. Анализ показывает, какие модули занимают объём, поэтому сокращение выполняется по фактическому составу.

# Сборка с анализом состава
npx vite build --mode analyze

# Проверка дубликатов версий
npm ls lodash

Анализ состава выполняется после каждой сборки, поскольку добавление зависимости изменяет объём. О разделении кода — в статье про code splitting.

Дубликаты зависимостей и замена тяжёлых библиотек

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

Дубликаты версий. Одна библиотека может быть включена в нескольких версиях, если зависимости требуют разные диапазоны. Каждая версия занимает объём, поэтому согласование версий сокращает сборку.

Тяжёлая зависимость ради одной функции. Библиотека, подключаемая ради одной функции, включается целиком, если удаление неиспользуемого кода не применимо. Замена на лёгкую библиотеку либо собственная реализация сокращает объём.

Практическое следствие: объём сокращается по фактическому составу, поэтому анализ выполняется до принятия решения о замене.

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

Три признака избыточного объёма.

Одна зависимость занимает значительную долю. Библиотека включена целиком, при этом используется малая часть её возможностей.

Несколько версий одной библиотеки. Зависимости требуют разные диапазоны, поэтому каждая версия включена отдельно.

Отсутствие минификации. Файл содержит форматирование и имена, не требуемые в среде выполнения.

О настройке сборщика — в статье про сборку фронтенда; о влиянии объёма на повторные загрузки — в статье про кэширование браузера.

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

Контроль объёма при изменении зависимостей

Объём сборки изменяется при обновлении зависимостей, поэтому контроль выполняется автоматически.

Проверка при сборке. Превышение установленного предела объёма обнаруживается на этапе сборки, поэтому изменение не попадает в рабочую версию без внимания.

Сравнение с предыдущей сборкой. Различие объёма показывает влияние изменения, поэтому добавление тяжёлой зависимости обнаруживается сразу.

Учёт сжатия при передаче. Объём передаваемого файла меньше объёма собранного, поскольку применяется сжатие, поэтому предел устанавливается по передаваемому объёму.

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

Отдельный аспект — влияние на кэш. Изменение состава частей инвалидирует кэш браузера, поэтому стабильные части изменяются реже, а изменяющиеся выносятся отдельно.

Влияние объёма на время загрузки и кэш

Объём сборки определяет время первоначальной загрузки и поведение при повторных посещениях.

Первоначальная загрузка. Браузер получает весь объём части, поэтому время загрузки растёт с объёмом. Сокращение объёма сокращает время получения ресурса.

Повторное посещение. Ресурсы из кэша не передаются повторно, поэтому объём влияет только на первое посещение. Изменение состава частей инвалидирует кэш.

Сжатие при передаче. Объём передаваемого файла меньше объёма собранного, поэтому предел устанавливается по передаваемому объёму.

Практическое следствие: сокращение объёма влияет на первое посещение, а стабильность состава частей — на повторные.

Практика: анализ и сокращение объёма сборки

1. Выполните анализ состава. Фактический состав показывает, какие модули занимают объём, а не предполагаемый перечень.

2. Проверьте дубликаты версий. Одна библиотека в нескольких версиях занимает объём повторно, поэтому версии согласуются.

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

4. Включите минификацию. Форматирование и имена исходного кода не требуются в среде выполнения.

5. Убедитесь в удалении неиспользуемого кода. Модуль с побочными эффектами не исключается, поэтому состав проверяется.

6. Сравнивайте объём между сборками. Изменение может увеличить объём незаметно, поэтому сравнение выполняется регулярно.

7. Фиксируйте предел объёма. Превышение предела при изменении указывает на добавление тяжёлой зависимости.

Рекомендации:

1. Различайте объём исходного кода и передаваемого файла. Минификация и сжатие при передаче сокращают объём, получаемый браузером.
2. Учитывайте кэширование. Изменение состава частей инвалидирует кэш, поэтому стабильные части изменяются реже.
3. Проверяйте влияние замены библиотеки. Лёгкая замена может не покрывать требуемые возможности, поэтому поведение проверяется.
4. Не сокращайте объём в ущерб читаемости кода. Собственная реализация вместо библиотеки требует сопровождения.
5. Пересматривайте состав при обновлении зависимостей. Новая версия может изменить объём, поэтому анализ повторяется.

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

Контекст: объём первоначальной загрузки вырос заметно после обновления одной зависимости.

1. Диагностика. Анализ состава показал, что обновлённая версия библиотеки включала дополнительные модули, которые не использовались. Удаление неиспользуемого кода не применилось, поскольку модули имели побочные эффекты при загрузке.
2. Причина. Новая версия изменила структуру модулей, поэтому исключение неиспользуемого кода перестало работать. Объём вырос, при этом фактическое использование библиотеки не изменилось.
3. Действия. (а) Выполнили анализ состава и определили модули, добавившие объём; (б) объявили отсутствие побочных эффектов для модулей, которые их не имеют, чтобы неиспользуемые исключались; (в) заменили тяжёлую зависимость на лёгкую для части функций; (г) согласовали версии зависимостей, чтобы исключить дубликаты; (д) установили предел объёма и проверку при сборке.
4. Результат. Объём сборки вернулся к прежнему уровню, а превышение предела обнаруживается при сборке.

Вывод: обновление зависимости может увеличить объём сборки незаметно. Анализ состава и контроль предела объёма обнаруживают рост до попадания изменения в рабочую сборку.

FAQ

Как узнать, что занимает объём в сборке? Анализом состава, который показывает модули и их размер. Предполагаемый состав может отличаться от фактического.

Почему одна библиотека включена в нескольких версиях? Зависимости требуют разные диапазоны версий, поэтому каждая версия включается отдельно. Согласование диапазонов сокращает объём.

Всегда ли удаляется неиспользуемый код? Нет, модуль с побочными эффектами не исключается, поскольку эффект выполняется независимо от использования экспортов.

Как контролировать объём при изменении? Сравнением сборок и проверкой предела объёма при сборке. Превышение указывает на добавление тяжёлой зависимости.

Источники: Vite guide, Rollup introduction, MDN JavaScript — ссылки в шапке.