Оптимізація критичного 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 шаблону:
// Inline критичного 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 + inline в header.php | 2–3 дні |
| Середній | Автоматизація через critical + асинхронні link + оновлення при деплої |
4–6 днів |
| Повний | PurgeCSS у збірці, кілька наборів critical CSS за типами сторінок, інтеграція з CI | 7–10 днів |