Объединение CSS и JS файлов 1С-Битрикс

Объединение CSS и JS файлов 1С-Битрикс

На проекте, который разрабатывался несколько лет несколькими командами, типична ситуация: каждый модуль, каждый компонент, каждый виджет подключает собственные CSS и JS файлы. Chrome DevTools → Network показывает 60–120 запросов только к стилям и скриптам. Даже при HTTP/2 (который теоретически мультиплексирует запросы) это создаёт overhead на DNS lookup, TCP handshake, TLS negotiation для каждого домена и приоритизацию запросов. На мобильных сетях 100 мелких запросов всегда хуже, чем 5 крупных.

Встроенный механизм объединения Битрикс

Битрикс предоставляет два инструмента для объединения файлов: через CMain::AddCSSLink() / CMain::AddHeadScript() с включённой минификацией (Настройки → Производительность → Сжатие), и через компонент bitrix:main.include с параметрами пакетирования.

При включённой минификации Битрикс группирует CSS в один файл /bitrix/cache/css/<hash>.css и JS — в /bitrix/cache/js/<hash>.js. Ключевое ограничение: объединяются только файлы, зарегистрированные через PHP-API до вызова ShowHead(). Файлы, подключённые через <link> в шаблонах напрямую, не войдут в пакет.

Проблемы и их решение

Порядок подключения. При объединении порядок CSS-правил меняется, что ломает стили, основанные на специфичности каскада. Решение: явно контролировать порядок через \Bitrix\Main\Page\Asset::addCss() с приоритетами, или разбить на два бандла — «базовый» (reset, grid, typography) и «компонентный».

Inline-стили и скрипты. Многие компоненты Битрикс генерируют <style> и <script> теги прямо в HTML — они не объединяются автоматически. Для кастомных компонентов это переносится в файлы через $this->addExternalCSS() и $this->addExternalJS().

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

Webpack/Vite как альтернатива встроенным инструментам

Для проектов с активным фронтендом встроенного механизма объединения Битрикс недостаточно. Современный подход — сборка через Webpack или Vite с отдельным webpack.config.js для битрикс-шаблона. Преимущества: tree shaking (удаление неиспользуемого кода), code splitting, обработка SCSS/LESS, транспиляция TypeScript.

Пример структуры для Vite + Битрикс-шаблон:

local/templates/mytemplate/
├── src/
│   ├── css/
│   │   ├── main.scss
│   │   └── components/
│   ├── js/
│   │   ├── app.js
│   │   └── pages/
├── dist/       ← сюда собирает Vite
│   ├── app.[hash].css
│   └── app.[hash].js
├── header.php  ← подключает dist/
└── vite.config.js

header.php подключает файлы из dist/ через CMain::AddCSSLink() — так они попадают в общий механизм кеширования Битрикс.

Кейс: портал с несколькими командами разработки

B2B-портал, 5 лет в разработке, три команды сменились. На странице каталога: 47 CSS-запросов (суммарно 890 KB без сжатия), 68 JS-запросов (суммарно 1,4 MB). Аудит показал: 12 CSS файлов дублировались (одни и те же нормализаторы подключены в разных компонентах), 8 JS-библиотек загружались в нескольких версиях одновременно (jQuery 1.9, 2.1 и 3.6 на одной странице).

Что сделали:

• Аудит всех подключений через перехват CMain::AddCSSLink() и AddHeadScript() с логированием
• Унификация библиотек: jQuery единая версия, удаление дублей
• Перенос всех прямых <link> в API Битрикс
• Настройка сборки через Vite для нового кода, упаковка legacy в единый бандл
• Code splitting: критический бандл + 4 страничных бандла

Результат: 47 CSS-запросов → 3, 68 JS-запросов → 5. Суммарный вес CSS+JS (после gzip) снизился с 850 KB до 210 KB за счёт удаления дублей и tree shaking.

Сроки

Нагрузочное тестирование после объединения обязательно — в редких случаях порядок загрузки скриптов важен, и его нарушение приводит к JS-ошибкам на конкретных страницах.