<b>Как уменьшить бандл лендинга без магии: Tree Shaking, Split и дисциплина импорта</b>

<b>Как уменьшить бандл лендинга без магии: Tree Shaking, Split и дисциплина импорта</b>

Первое правило — не лечить симптом, пока не найден источник. Большой бандл чаще всего делают три вещи: «barrel»-импорты, тащащие за собой лишний код; общие утилиты, которые тянут целые библиотеки; и компоненты, подключенные на странице, где они не нужны.

Tree Shaking работает только когда код написан прозрачно для сборщика. Держите ES-модули, избегайте побочных эффектов в файлах с экспортами, не прячьте нужную функцию за индексными re-export’ами без необходимости. Если библиотека экспортирует всё подряд, а вы берёте один helper, проверьте, умеет ли она реально отрезать хвост.

Code Splitting нужен не «на всякий случай», а по маршрутам и тяжелым сценариям: модалки, редакторы, галереи, карты, калькуляторы. Загружайте их по событию, а не при старте страницы. Для лендинга это часто даёт больше, чем попытка выжать ещё пару килобайт из минификации ⚙️

Смотрите не только на вес файла, но и на стоимость выполнения: маленький, но запутанный бандл может тормозить сильнее, чем чуть больший, но линейный. Полезная проверка — собрать dependency graph, убрать дубли библиотек, заменить «толстые» пакеты на точечные импорты и измерить, что реально попало в initial load.

<b>Вердикт для продакшена:</b> сначала чистим импорты и зависимости, потом дробим код по сценариям, и только после этого трогаем микрооптимизации. Если не измеряете initial chunk и не знаете, что именно грузится на первом экране, вы оптимизируете вслепую.