Оптимизация критического CSS для 1С-Битрикс
Типичная картина: Битрикс-сайт подключает в <head> три-четыре CSS-файла суммарным весом 300–600 КБ. Браузер не начинает рендер страницы, пока не скачает и не разберёт весь CSS — это называется render-blocking. В результате FCP (First Contentful Paint) составляет 3–5 с на мобильном соединении даже при включённом кэше. Решение — выделить критический CSS (стили первого экрана) в <style> inline и отложить загрузку остального.
Откуда берётся render-blocking CSS в Битриксе
Битрикс формирует список CSS-файлов через CMain::AddCSS() и выводит их в $APPLICATION->ShowHead(). Все файлы попадают в <head> как <link rel="stylesheet"> — блокирующая загрузка по умолчанию. Модуль main умеет объединять CSS через встроенный комбайнер (/bitrix/cache/css/), но он не разделяет критический и некритический CSS.
Дополнительно: компоненты вроде bitrix:catalog.section добавляют собственные стили через $APPLICATION->SetAdditionalCSS(), а шаблоны компонентов — через style.css внутри папки компонента. Всё это попадает в blocking-путь.
Что такое критический CSS на практике
Критический CSS — это стили, необходимые для отрисовки контента выше линии сгиба без дополнительных сетевых запросов. Для Битрикс-сайта это обычно:
- сброс/нормализация (
box-sizing, базовые отступы) - сетка шапки и первого блока страницы
- типографика заголовков H1, H2 и основного текста
- стили навигационного меню
- стили hero-баннера или первого слайдера
Всё остальное — стили карточек товаров, корзины, форм фильтрации, футера — можно загружать асинхронно.
Техника инлайнинга критического CSS
Шаг 1: Извлечение критических стилей
Используем critical (Node.js) для автоматического извлечения:
npm install -g critical
critical https://example.com --width=1300 --height=900 \
--css=public/bitrix/templates/main/template_styles.css \
--inline \
--output=critical.css
Для мобильного viewport добавляем второй прогон с --width=375 --height=812. Объединяем результаты — получаем critical.css на 15–40 КБ.
Шаг 2: Интеграция в шаблон Битрикс
В header.php шаблона:
// Инлайн критического CSS
$criticalCss = file_get_contents(__DIR__ . '/critical.css');
?>
<style><?= $criticalCss ?></style>
<?php
// Асинхронная загрузка остального CSS
?>
<link rel="preload" href="/local/templates/main/template_styles.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript>
<link rel="stylesheet" href="/local/templates/main/template_styles.css">
</noscript>
rel="preload" as="style" с переключением на stylesheet через onload — стандартный паттерн LoadCSS. <noscript> — фоллбек для браузеров без JavaScript.
Шаг 3: Работа с CSS-комбайнером Битрикс
Если включён встроенный комбайнер (BX_COMPOSITE_BUFFER_ON_CSS), он перехватывает вывод <link>. Нужно либо отключить его для контролируемых файлов:
// В header.php до ShowHead()
define('BX_COMPOSITE_BUFFER_ON_CSS', false);
Либо использовать событие OnEndBufferContent для постобработки HTML и замены блокирующих <link> на асинхронные.
Работа с PostCSS и PurgeCSS
На проектах, где шаблон собирается через Gulp или Webpack, добавляем в пайплайн:
// gulpfile.js
const purgecss = require('@fullhuman/postcss-purgecss');
postcss([
purgecss({
content: ['./local/templates/**/*.php', './local/components/**/*.php'],
defaultExtractor: content => content.match(/[\w-/:]+(?<!:)/g) || []
})
])
PurgeCSS анализирует PHP-шаблоны и удаляет неиспользуемые правила. На Bootstrap/Foundation-based темах это сокращает CSS с 250 КБ до 30–60 КБ.
Кейс: корпоративный портал на Битрикс24
Портал компании с ~300 сотрудниками: главная страница подключала 7 CSS-файлов суммарным весом 480 КБ. FCP в Lighthouse (Desktop, Fast 3G) — 4,2 с. Задача — довести до 1,5 с без смены шаблона.
Что сделали:
- Запустили
criticalдля главной, раздела новостей и раздела документов — три разных набора критического CSS. - В
header.phpдобавили логику определения типа страницы и подключения соответствующего inline-CSS. - Остальные CSS-файлы переведены на
preload+ асинхронное подключение. - PurgeCSS убрал ~60% неиспользуемых правил из
template_styles.css.
Результат: FCP — 1,3 с, суммарный вес CSS «выше сгиба» — 18 КБ inline, остальные 90 КБ загружаются асинхронно после FCP.
Автоматизация обновления критического CSS
Критический CSS нужно обновлять при смене дизайна. Встраиваем в деплой-скрипт:
#!/bin/bash
# post-deploy.sh
node ./scripts/generate-critical.js
php artisan cache:clear # или bitrix/modules/main/tools/critical_css.php
Скрипт generate-critical.js запускает Chrome headless через Puppeteer, снимает критический CSS со списка ключевых страниц и записывает файлы в папку шаблона.
Диагностика
В Chrome DevTools → Coverage (Shift+Ctrl+P → Coverage) видно процент неиспользуемого CSS. Показатель выше 70–80% неиспользуемого CSS на первом экране — прямой сигнал к работе. В Lighthouse — метрика «Reduce unused CSS» с указанием потенциальной экономии в КБ.
Сроки
| Масштаб | Состав | Срок |
|---|---|---|
| Базовый | Ручное выделение критического CSS + инлайн в header.php | 2–3 дня |
| Средний | Автоматизация через critical + асинхронные link + обновление при деплое |
4–6 дней |
| Полный | PurgeCSS в сборке, несколько наборов critical CSS по типам страниц, интеграция с CI | 7–10 дней |