Об'єднання 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, типографіка) та «компонентний».

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-помилок на конкретних сторінках.