Сборка CSS и JS в 1С-Битрикс: ускорение загрузки сайта

Сборка CSS и JS в 1С-Битрикс: ускорение загрузки сайта

Мы часто берём проекты, которые развивались годами, и обнаруживаем хаос из CSS и JS. Типичный случай: на странице каталога 60-120 запросов к стилям и скриптам. Даже с HTTP/2 каждый новый запрос тратит время на DNS, TCP и TLS. На мобильных сетях это убивает производительность. Наш опыт показывает: объединение файлов может сократить количество запросов в 10-20 раз и ускорить загрузку на 40-70%.

Почему объединение CSS и JS ускоряет сайт?

Браузер ограничивает количество одновременных соединений к одному домену (обычно 6). Если файлов много, они загружаются последовательно. Объединение в один файл уменьшает количество запросов, что особенно заметно на мобильных сетях. Также снижается overhead на DNS, TCP и TLS для каждого запроса. Подробнее про HTTP/2.

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

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

Какие проблемы решаем?

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

Inline-стили и скрипты. Многие компоненты (например, bitrix:news.list) выдают рендер прямо в HTML. Это не объединяется. Для кастомных решений заменяем echo '<style>' на $this->addExternalCSS() — тогда файл попадает в общий бандл и кэшируется.

Дубли и конфликты версий. На одном проекте мы нашли 12 одинаковых normalize.css и три версии jQuery (1.9, 2.1, 3.6) на одной странице. Аудит через перехват AddCSSLink() и логирование помог унифицировать библиотеки. Tree shaking и code splitting — ваш следующий шаг.

Как мы это делаем: Vite и Webpack

Для современных проектов встроенные средства Битрикс недостаточны. Мы используем Vite или Webpack.

Пример структуры с 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 подключаем бандлы через CMain::AddCSSLink() — так они кэшируются Битрикс. Vite обеспечивает HMR во время разработки, tree shaking для продакшена.

Почему Vite лучше встроенного механизма?

Vite поддерживает SCSS, TypeScript, автоматический code splitting. Встроенное объединение Битрикс этого не умеет. Мы на практике добиваемся уменьшения веса бандла на 30-50% за счёт удаления мёртвого кода. Сравнение:

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

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

Что сделали:

• Аудит всех подключений через перехват 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.
• Скорость загрузки страницы упала с 4.2 с до 1.1 с (по Lighthouse).

Процесс работы:

1. Аналитика — собираем логи всех подключений, выявляем дубли, конфликты, неиспользуемый код.
2. Проектирование — определяем архитектуру бандлов: критический, страничные, отложенные.
3. Реализация — переносим подключения на API, настраиваем сборку (Vite/Webpack), пишем конфиги.
4. Тестирование — проверяем каждую страницу на корректность отображения и функциональность JS.
5. Деплой — заливаем на боевой сервер, проверяем кэширование.

Тегированное кэширование Битрикс сбрасывает кэш при изменении данных. При объединении файлов важно, чтобы кэш CSS/JS инвалидировался корректно. Настраиваем через $arParams["CACHE_TAGS"].

Что входит в работу:

• Полный аудит текущих подключений с отчётом.
• Унификация библиотек и удаление дублей.
• Настройка сборщика (Vite или Webpack) под ваш шаблон.
• Интеграция с тегированным кэшированием Битрикс.
• Документация по процессу сборки и подключению.
• Обучение команды работе с новой архитектурой.
• Пост-релизная поддержка неделю.

Сроки и стоимость

Стоимость рассчитывается индивидуально после аудита. Закажите консультацию — мы предложим оптимальное решение. Гарантируем результат: ускорение загрузки минимум в 2 раза, подтверждённое тестами. Свяжитесь с нами для оценки вашего проекта.

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

Почему вёрстка сайтов на 1С-Битрикс требует профессионализма?

Открываете template.php у предыдущего подрядчика — а там SQL-запросы, бизнес-логика и inline-стили в одном файле. На каждом втором проекте, который берём на поддержку, код шаблонов выглядит как свалка: кэш не работает, добавить новую фичу — переписывай всё. Средняя стоимость исправления такой вёрстки сайтов — 15 000–30 000 рублей только на отладку, а потерянная выручка из-за сломанной корзины в пик сезона может уходить в миллионы. Наша команда с 10-летним опытом строго разделяет: логика — в result_modifier.php или component_epilog.php, представление — в template.php. Никакого CIBlockElement::GetList в шаблоне. Это сокращает время правок на 30–40% и исключает типовые ошибки, которые ломают кэш. Аналогичную проблему исправляли клиенту, который месяц не мог обновить блок «Акции» — после настройки тегированного кэша правки вставали за минуту, а не за день.

Как правильно организовать шаблоны компонентов?

Кастомный шаблон — это не один файл, а структура из пяти-шести файлов:

• template.php — только HTML и вывод $arResult
• result_modifier.php — подготовка данных, дополнительные выборки
• component_epilog.php — код после кэширования (счётчики, динамика)
• style.css и script.js — подключаются через Asset::getInstance()->addCss() и addJs() (не через <link> — иначе ломается объединение)
• .parameters.php — параметры визуального редактора

Пример структуры для каталога:

local/templates/your_template/components/bitrix/catalog.section/.default/
├── template.php
├── result_modifier.php
├── component_epilog.php
├── style.css
├── script.js
└── .parameters.php

Типовые шаблоны, которые верстаем под ключ:

Кэширование: почему оно ломается и как чиним?

Компонентное кэширование в Битрикс ломается одной ошибкой: вывели имя пользователя внутри кэшированного каталога — все видят одно имя. Решение — component_epilog.php для динамических вставок.

Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) настраиваем обязательно. Изменили товар — очищается кэш только этого товара, а не всего раздела. На проекте с 50 000 товаров это даёт прирост скорости на 40% по сравнению с полным сбросом.

Реальный кейс. Клиент жаловался — на странице каталога у всех одна корзина. Оказалось, предыдущий разработчик вывел $_SESSION['BASKET'] внутри template.php компонента catalog.section. Компонент кэшировался на час — корзина застыла. Перенесли вывод в component_epilog.php, настроили тегированный кэш на sale.basket.basket.line. Страница не потеряла в скорости, корзина стала актуальной. Ущерб от неработающей корзины в пик сезона мог составлять миллионы, а цена исправления — в пределах 15 000 рублей. Другой клиент потерял 200 000 рублей за неделю из-за некорректного кэша формы заказа — мы вернули работоспособность за два дня.

Официальная документация Битрикс рекомендует использовать component_epilog.php для динамических вставок — подробнее в руководстве.

CSS-подходы: BEM, Tailwind или гибрид?

Для больших проектов (30+ шаблонов) используем BEM — .product-card__price, .product-card--featured. Стили изолированы, конфликтов нет. Подробнее о BEM. В Битрикс обёртки с классами bx-component не трогаем — оборачиваем свой BEM-блок внутри.

Для типовых задач (лендинги, админки) берём Tailwind 3+ с PurgeCSS — итоговый CSS 10–30 КБ вместо сотен. Дизайн-токены в tailwind.config.js фиксируют цвета, шрифты, отступы в одном месте.

На большинстве проектов применяем гибрид: BEM для структурных компонентов (каталог, карточка, чекаут), Tailwind для утилитарных вещей (отступы, flex-раскладки). Границу оговариваем с командой заранее.

Как мы достигаем Core Web Vitals?

Critical CSS — выделяем стили первого экрана через пакет critical, инлайним в <head>. Остальное грузится асинхронно через media="print" onload="this.media='all'". LCP на мобильных сокращается на 1–1.5 секунды.

Изображения — главный тормоз. Используем <picture> с WebP и JPEG-фолбэком. loading="lazy" для всего ниже первого экрана. width и height явно прописаны — CLS = 0. Обработчик в urlrewrite.php генерирует WebP на лету.

Минификация и сжатие. CSS и JS через Vite или встроенное объединение Битрикс. Brotli на nginx (brotli_comp_level 6) — на 15–20% эффективнее gzip. Кэширование статики: expires 1y + версионирование через query string.

Хотите получить подобные показатели? Свяжитесь с нами — сделаем аудит вашего проекта и предложим конкретные шаги.

Что входит в услугу вёрстки сайтов на 1С-Битрикс?

После заказа вёрстки шаблона или адаптации готового решения передаём:

• Исходники шаблонов компонентов с разделением на template.php, result_modifier.php, epilog
• CSS и JS, подключённые через Asset — без инлайн-стилей
• Настроенное кэширование с тегами
• Документацию по структуре и параметрам
• Доступ к Git-репозиторию с историей изменений
• Обучение вашего разработчика: как править шаблон без потери обновляемости

Гарантируем соответствие Core Web Vitals и кроссбраузерность. Закрепляем инженера с опытом 10+ лет — получите консультацию по вашему проекту до начала работ.

Процесс работы:

1. Анализ макетов и текущего проекта — выявляем компоненты для переработки
2. Проектирование структуры — разбиваем страницу на BEM-блоки
3. Реализация — верстаем шаблоны по схеме: template, result_modifier, epilog, CSS, JS
4. Тестирование — проверяем кэш, адаптивность, Core Web Vitals, кроссбраузерность
5. Деплой — стейджинг, приёмка, продакшен

На каждом этапе вы получаете промежуточный результат и можете внести правки. Свяжитесь с нами — оценим проект за 1–2 дня после получения макетов.

Сроки

После анализа даём разбивку по компонентам — что переиспользуется, что верстается с нуля. Закажите предварительную консультацию — посчитаем сроки и бюджет индивидуально.