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

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

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

Tree shaking работает только если код написан как набор статических импортов и модулей без лишней магии. Если библиотека публикует CommonJS или имеет побочные эффекты при загрузке, сборщик оставит больше, чем вы ожидаете. Проверьте sideEffects, не используйте универсальные index.ts для всего подряд и не рассчитывайте, что «сборщик сам разберется».

Code splitting дает эффект, когда вы режете по маршрутам, состояниям интерфейса и тяжелым сценариям: редактор, графики, карты, модалки. Логика простая: если блок не нужен при первом экране — он не должен жить в основном чанке. Но дробить до бесконечности тоже вредно: растет число запросов, усложняется кеш и старт может стать медленнее.

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