Оптимизация критического CSS для 1С-Битрикс
Типичная картина: Битрикс-сайт подключает три-четыре CSS-файла суммарным весом 300–600 КБ. Браузер блокирует рендер до загрузки всего CSS — это называется render-blocking. В результате FCP достигает 3–5 с на мобильном соединении даже при кэше. Мы решаем эту проблему выделением критического CSS и inline-встраиванием. Оцените свой проект — свяжитесь с нами для консультации.
Почему в Битриксе возникает render-blocking CSS?
Битрикс формирует список CSS-файлов через CMain::AddCSS() и выводит их в <head> как <link rel="stylesheet">. Все файлы блокируют рендер. Встроенный комбайнер (/bitrix/cache/css/) объединяет CSS, но не отделяет критический от некритического. Компоненты вроде bitrix:catalog.section добавляют собственные стили через $APPLICATION->SetAdditionalCSS(). Всё это попадает в blocking-путь. В итоге даже при кэше первый экран отрисовывается с задержкой.
Что такое критический CSS на практике?
Критический CSS — стили, необходимые для контента выше линии сгиба без дополнительных запросов. Для Битрикс-сайта это: сброс (box-sizing, базовые отступы), сетка шапки и первого блока, типографика H1–H2, навигационное меню, стили hero-баннера. Остальное — карточки товаров, корзина, фильтры, футер — загружаем асинхронно. Инлайн критического CSS сокращает FCP на 40–60%, что подтверждает измерение Google на Web.dev.
Техника инлайнинга критического 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. Объединённый результат — файл 15–40 КБ.
Шаг 2: Интеграция в шаблон Битрикс
В header.php шаблона:
<?php $criticalCss = file_get_contents(__DIR__ . '/critical.css'); ?> <style><?= $criticalCss ?></style> <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" с переключением через onload — стандартный паттерн LoadCSS. <noscript> — фоллбек для браузеров без JavaScript.
Шаг 3: Работа с CSS-комбайнером Битрикс
Если включён комбайнер (BX_COMPOSITE_BUFFER_ON_CSS), он перехватывает вывод <link>. Нужно либо отключить его для контролируемых файлов:
define('BX_COMPOSITE_BUFFER_ON_CSS', false); Либо через событие OnEndBufferContent заменить блокирующие <link> на асинхронные.
PurgeCSS и PostCSS: сокращение CSS на 60–80%
На проектах с Gulp или Webpack добавляем:
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-темах CSS cжимается с 250 КБ до 30–60 КБ. Инлайн критического CSS в сочетании с PurgeCSS даёт наилучший результат — по данным MDN, FCP снижается в среднем на 1–2 с.
Кейс: корпоративный портал на Битрикс24 (из нашей практики)
Портал компании с ~300 сотрудниками: главная страница подключала 7 CSS-файлов (480 КБ). FCP в Lighthouse (Desktop, Fast 3G) — 4,2 с. Задача — довести до 1,5 с без смены шаблона. Наш инженер со стажем более 5 лет выполнил:
- Запуск
criticalдля главной, раздела новостей и документов — три разных набора критического CSS. - В
header.phpдобавлена логика определения типа страницы и подключения соответствующего inline-CSS. - Остальные CSS-файлы переведены на
preload+ асинхронное подключение. - PurgeCSS убрал ~60% неиспользуемых правил из
template_styles.css.
Результат: FCP — 1,3 с, суммарный вес CSS «выше сгиба» — 18 КБ inline, остальные 90 КБ асинхронно после отрисовки.
Как автоматизировать обновление критического CSS?
Критический CSS требует обновления при каждом изменении дизайна. Встраиваем в деплой:
#!/bin/bash node ./scripts/generate-critical.js php artisan cache:clear Скрипт generate-critical.js (Puppeteer) генерирует критический CSS для списка ключевых страниц и записывает файлы в папку шаблона.
Диагностика эффективности
В Chrome DevTools → Coverage (Shift+Ctrl+P → Coverage) видно процент неиспользуемого CSS. Показатель >70% на первом экране — сигнал к оптимизации. В Lighthouse метрика «Reduce unused CSS» показывает потенциальную экономию в КБ. Гарантируем: после нашей оптимизации неиспользуемый CSS сокращается до 10–15%.
Что входит в услугу «под ключ»
| Компонент | Детали |
|---|---|
| Аудит текущего CSS | Проверка Coverage, определение render-blocking файлов |
| Извлечение критического CSS | Для 3–5 типовых страниц с разными viewport |
| Интеграция в шаблон | Инлайн в header.php, асинхронная загрузка остального |
| PurgeCSS (опционально) | Настройка в пайплайне, удаление неиспользуемых правил |
| Тестирование | Проверка FCP, LCP, CLS на реальных устройствах |
| Документация | Инструкция по обновлению критического CSS при изменениях |
Сроки и стоимость
| Масштаб | Состав | Срок |
|---|---|---|
| Базовый | Ручное выделение CSS + инлайн в header.php | 2–3 дня |
| Средний | Автоматизация через critical + async link + деплой | 4–6 дней |
| Полный | PurgeCSS в сборке, несколько наборов critical CSS под разные типы страниц, CI-интеграция | 7–10 дней |
Пример кода для генерации критического CSS через Puppeteer
const puppeteer = require('puppeteer'); const critical = require('critical'); async function generateCritical(url, cssPath, outputPath) { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto(url, { waitUntil: 'networkidle0' }); const css = await critical.generate({ inline: false, css: [cssPath], width: 1300, height: 900, }); require('fs').writeFileSync(outputPath, css); await browser.close(); } Закажите оптимизацию критического CSS для вашего Битрикс-сайта. Наши сертифицированные специалисты (опыт 5+ лет, 50+ проектов) доведут FCP до 1,5 с. Получите консультацию — напишите нам!