Минимизация бандла: где реально режется вес, а где только шум

Минимизация бандла: где реально режется вес, а где только шум

Давайте разберем под капотом. Tree shaking убирает неиспользуемый код только если модуль отдает ESM и побочные эффекты не мешают анализу. Если импортируете «всё подряд», а потом выбираете одну функцию — сборщик не спасет. Проверьте, что:
— нет общего index.js с агрессивными реэкспортами;
— пакет помечает sideEffects: false там, где это правда;
— не тянете тяжелые утилиты ради пары строк.

Code splitting полезен, когда разносит по маршрутам, а не дробит приложение без смысла. Критерий простой: если блок нужен только после действия пользователя, он не должен быть в первом экране. Модалки, редакторы, графики, карты, валидаторы — хорошие кандидаты на динамический импорт. Плохой кандидат — 20 микрофайлов, которые грузятся отдельно и создают лишние запросы.

Что по производительности? Смотрите не только на размер архива, но и на парсинг, выполнение и число чанков. Иногда минус 30 КБ gzip почти не заметен, а лишние зависимости и асинхронные переходы дают лаги сильнее. Полезная привычка: сравнивать bundle analyzer, покрытие кода и реальный стартовый экран, а не только отчет сборщика 📦

Вердикт для продакшена: сначала уберите мертвые импорты и дубли библиотек, затем проверьте tree shaking, и только потом режьте приложение на чанки. Хороший бандл — это не минимальный бандл, а тот, который быстро дает первый полезный экран.