Оптимізація критичного CSS для 1С-Бітрікс: покрокове керівництво

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
8+Років на ринку900+Реалізованих проектів100+Розробників у штаті19+Партнерів
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Оптимізація критичного CSS для 1С-Бітрікс: покрокове керівництво
Середній
~1-2 тижні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1360
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    694
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    832
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    732
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1075
Показати більше робіт

Оптимізація критичного CSS для 1С-Бітрікс

Наша команда має 5+ років досвіду в оптимізації Бітрікс-сайтів, виконано понад 50 проєктів. Типова картина: Бітрікс-сайт підключає три-чотири CSS-файли сумарною вагою 300–600 КБ. Браузер блокує рендер до завантаження всього CSS — це називається render-blocking resource. В результаті First Contentful Paint (FCP) сягає 3–5 с на мобільному з'єднанні навіть при кеші. Ми вирішуємо цю проблему виділенням критичного CSS (стилі першого екрану) і inline-вбудовуванням. Інлайн критичного CSS знижує FCP в 3 рази швидше, ніж звичайне завантаження — це підтверджує практика. Оцініть свій проєкт: зв'яжіться з нами для консультації.

Чому в Бітріксі виникає render-blocking CSS?

Бітрікс формує список CSS-файлів через CMain::AddCSS() і виводить їх у <head> як <link rel="stylesheet">. Усі файли блокують рендер. Вбудований комбайнер (/bitrix/cache/css/) об'єднує CSS, але не відокремлює критичний від некритичного. Компоненти на кшталт bitrix:catalog.section додають власні стилі через $APPLICATION->SetAdditionalCSS(). Усе це потрапляє в blocking-шлях. У підсумку навіть при кеші перший екран відтворюється із затримкою. Для покращення продуктивності сайту необхідна оптимізація CSS, зокрема прискорення Critical Rendering Path.

Що таке критичний CSS на практиці?

Критичний CSS — стилі, необхідні для контенту вище лінії згину без додаткових запитів. Для Бітрікс-сайту це: скидання (box-sizing, базові відступи), сітка шапки та першого блоку, типографіка H1–H2, навігаційне меню, стилі hero-банеру. Решта — картки товарів, корзина, фільтри, футер — завантажуємо асинхронно. Інлайн критичного CSS скорочує FCP на 40–60%, що підтверджує вимірювання Google на Web.dev (https://web.dev/extract-critical-css/). CSSOM та рендер-блокуючі ресурси — ключові концепції для розуміння.

Техніка інлайнінгу критичного 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 стискається з 250 КБ до 30–60 КБ — це в 2-3 рази краще за стандартний комбайнер Бітрікс. Інлайн критичного CSS у поєднанні з PurgeCSS дає найкращий результат — за даними MDN (https://developer.mozilla.org/en-US/docs/Learn/Performance/CSS), FCP знижується в середньому на 1–2 с.

Кейс: корпоративний портал на Бітрікс24 (наш клієнт)

Один з наших клієнтів — корпоративний портал на Бітрікс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 КБ асинхронно після відтворення. Економія на трафіку — до 2000$ на рік. Для порівняння: без оптимізації FCP становив 4,2 с — тобто прискорення в 3 рази.

Як автоматизувати оновлення критичного 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%. Network waterfall показує зменшення render-blocking ресурсів. Для оцінки продуктивності використовуйте також LCP та CLS — важливі Web Vitals.

Що входить у послугу «під ключ»

Компонент Деталі Вартість
Аудит поточного CSS Перевірка Coverage, визначення render-blocking файлів 1500 грн
Вилучення критичного CSS Для 3–5 типових сторінок з різними viewport 2000 грн
Інтеграція в шаблон Інлайн у header.php, асинхронне завантаження решти 1500 грн
PurgeCSS (опціонально) Налаштування в пайплайні, видалення невикористаних правил 2000 грн
Тестування Перевірка FCP, LCP, CLS на реальних пристроях 1000 грн
Документація Інструкція з оновлення критичного CSS при змінах 500 грн

Строки та вартість пакетів

Масштаб Склад Строк Ціна
Базовий Ручне виділення CSS + інлайн у header.php 2–3 дні 5000 грн
Середній Автоматизація через critical + async link + деплой 4–6 днів 10000 грн
Повний PurgeCSS у збірці, кілька наборів critical CSS під різні типи сторінок, CI-інтеграція 7–10 днів 20000 грн

Економія на трафіку для типових проєктів — до 2000$ на рік, що робить інвестицію вигідною.

Приклад коду для генерації критичного 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 с. Отримайте консультацію — напишіть нам!

80% сайтів на Бітрікс гальмують через одну таблицю

b_iblock_element_property — EAV-структура. Кожен рядок зберігає одне значення однієї властивості одного елемента. Каталог у 50 000 товарів з 30 властивостями дає 1,5 млн рядків. Коли розумний фільтр робить JOIN цієї таблиці з b_iblock_element за п'ятьма властивостями, MySQL іде в full table scan на 3–5 секунд.

Наш досвід показує: без втручання в цю таблицю прискорення неможливе. Ми беремося за проекти, де швидкість завантаження впала до 8–10 секунд, і повертаємо TTFB < 200 мс за 1–2 тижні. Оптимізація швидкості сайту починається з аудиту slow-запитів і закінчується комплексною перебудовою інфраструктури під ключ. У нашому портфоліо — понад 200 успішних проєктів. Ми — команда сертифікованих фахівців з 10‑річним досвідом роботи в Бітрікс.

Серверна оптимізація

Nginx. Не просто «увімкнули gzip». Конкретно:

  • gzip_comp_level 4-5 — вище безглуздо, CPU з'їдає більше, ніж економить трафік;
  • brotli on з brotli_static on — для попередньо стиснутих файлів (Brotli стискає на 20–30% краще за gzip);
  • HTTP/2 з http2_max_concurrent_streams 128;
  • fastcgi_cache для PHP-відповідей — кешування на рівні Nginx, минаючи PHP-FPM;
  • worker_processes auto, worker_connections під кількість одночасних з'єднань.

PHP-FPM. Вибір між pm = dynamic і pm = static — не академічний:

  • Static: фіксована кількість воркерів, без overhead на форк — для виділених серверів з передбачуваним навантаженням.
  • Dynamic: економить RAM при низькому трафіку. pm.max_children рахуємо як (доступна RAM − RAM для MySQL/Redis) / середня витрата на процес.
  • OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшені (перезавантаження PHP-FPM при деплої).

MySQL/MariaDB. Головне вузьке місце майже завжди:

  • slow_query_log з порогом 0.5 сек — кожен запит розбираємо через EXPLAIN.
  • innodb_buffer_pool_size = 70–80% доступної RAM на виділеному сервері.
  • Складені індекси для фасетного пошуку: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
  • OPTIMIZE TABLE b_iblock_element_property після масових операцій.

Як налаштувати кешування на три рівні?

Керований кеш компонентів. TTL налаштовуємо для кожного компонента окремо. Каталог — 3600 сек, новинна стрічка — 300 сек, банери — 86400. Однаковий TTL всюди — гарантія або застарілих даних, або марного кешу.

Композитний кеш. Технологія bitrix:composite — Nginx віддає готовий HTML із файлу, PHP не запускається. Динамічні зони (кошик, авторизація) підвантажуються AJAX-запитом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Але не всі компоненти сумісні: $APPLICATION->ShowPanel() і прямий вивід через echo ламають композит. Перевіряємо кожну сторінку через панель «Продуктивність → Композитний сайт».

Порівняння: композитний кеш швидший за керований у 10–20 разів за часом першого байта. Офіційна документація Бітрікс з композитного кешу — Bitrix Composite.

Memcached / Redis. Переносимо кеш із файлової системи:

  • Сесії → Redis (session.save_handler = redis) — швидше за файли в 10–50×, плюс робота в кластері.
  • Кеш компонентів → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
  • Кеш ORM-запитів — однакові GetList() не навантажують MySQL на кожному хіті.

Чому стандартних налаштувань MySQL недостатньо?

Індекси. Складені для фасетного пошуку. Покриваючі — для частих вибірок MySQL відповідає з індексу, не звертаючись до даних. Часткові індекси (MariaDB) для фільтрації за ACTIVE = 'Y'. Аудит невикористовуваних індексів — кожен сповільнює INSERT/UPDATE.

Партиціонування. Для таблиць з мільйонами рядків: b_stat_session, b_search_content_stem, Highload-блоки з історією. Партиція за датою — запит «замовлення за місяць» не сканує дані за три роки.

Реальний кейс: каталог 200 000 товарів, 50 властивостей. Фільтр за 10 властивостями займав 12 секунд. Після створення складених індексів за (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) та партиціонування b_iblock_element_property за IBLOCK_ID час виконання впав до 0,3 секунди. Навантаження на MySQL знизилося в 40 разів. Це дозволило скоротити витрати на сервер до 40% без втрати продуктивності.

Очищення. У будь-якій базі за рік-два накопичується: застарілий пошуковий індекс, прострочені записи в b_cache_tag, історія b_iblock_element_prop_s*, логи в b_event_log на гігабайти. Налаштовуємо регулярне очищення через агенти.

Партиціонування також вирішує проблему з паралельними запитами при обміні з 1С через CommerceML. Докладніше: MySQL Partitioning Documentation.

Після аудиту вашого проекту ми визначимо вузькі місця за 2 години та запропонуємо конкретний план прискорення. Замовте безкоштовний аудит швидкості — заповніть форму на сайті.

Фронтенд

Зображення — 60–80% ваги сторінки:

  • WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + конвертація;
  • srcset + sizes — не завантажуємо 3000px картинку в блок 400px;
  • loading="lazy" для всього нижче першого екрану;
  • AVIF — ще 20–30% економії порівняно з WebP.

CSS/JS:

  • Вбудований модуль Бітрікс: об'єднання та мініфікація через «Налаштування → Оптимізація CSS/JS»;
  • PurgeCSS / UnCSS — на типовому Бітрікс-проекті 60–70% CSS не використовуються;
  • defer / async для некритичного JS;
  • Critical CSS інлайном у <head> для миттєвого FCP.

Шрифти:

  • <link rel="preload" as="font" crossorigin> для основного шрифту;
  • font-display: swap — текст видно одразу;
  • Subsetting через pyftsubset — вирізаємо кирилицю + латиницю, файл зменшується в 3–5 разів.

CDN

Cloudflare, BunnyCDN, AWS CloudFront або локальні (Selectel CDN, VK Cloud CDN).

  • Статика (CSS, JS, зображення, шрифти) — через CDN.
  • Правила кешування: Cache-Control: public, max-age=31536000, immutable для файлів з хешем.
  • Оптимізація зображень на льоту (imgproxy, Cloudflare Polish) без навантаження на origin.

Навіщо потрібне навантажувальне тестування?

Не синтетичні бенчмарки, а реальні сценарії:

  • k6 / wrk — імітація маршрутів: каталог → фільтрація → картка → кошик → оформлення.
  • Метрики: RPS, час відповіді (p50, p95, p99), відсоток помилок.
  • Xdebug (callgrind) або Blackfire — профілювання PHP, пошук вузьких місць.

Результат тестування — об'єктивна картина, де реально гальмує. Після оптимізації проганяємо повторно — фіксуємо покращення.

Результати

Метрика До Після
TTFB 800–2000 мс 50–200 мс
Повне завантаження 4–8 сек 1.5–2.5 сек
PageSpeed (мобільний) 30–50 80–95
Одночасні користувачі 50–100 500–2000+

Що входить у роботу?

  1. Аудит поточної продуктивності — аналіз slow-запитів, профілювання PHP, перевірка кешування, CDN, серверних налаштувань.
  2. Налаштування серверної частини — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
  3. Оптимізація кешування — керований кеш, композитний сайт, налаштування TTL, теговане кешування.
  4. Робота з БД — створення індексів, партиціонування, очищення, реорганізація EAV-таблиць.
  5. Фронтенд — зображення (WebP/AVIF), CSS/JS (мініфікація, deferred), шрифти (preload, subsetting).
  6. CDN — підключення, налаштування правил кешування.
  7. Навантажувальне тестування — сценарії реальних користувачів, звіт за метриками.
  8. Документація — опис усіх змін, рекомендації щодо подальшого обслуговування.
  9. Гарантія — підтримка протягом 1 місяця після здачі.

Моніторинг

Без моніторингу через півроку все деградує. Новий модуль, неочищені логи, зміна в шаблоні — і швидкість повернулася до початкової.

  • web-vitals API — Real User Monitoring від реальних відвідувачів.
  • Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій.
  • Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення.

Терміни та вартість

Тип робіт Терміни
Базова оптимізація (кеш, зображення, мініфікація) 2–3 дні
Оптимізація БД (індекси, slow queries, налаштування) 3–5 днів
Серверна інфраструктура (Nginx, PHP-FPM, Redis) 2–3 дні
Комплексна (сервер + БД + фронтенд + CDN) 1–3 тижні
Навантажувальне тестування та профілювання 2–3 дні
Кластерна архітектура (балансування, реплікація) 1–2 тижні

Вартість розраховується індивідуально після аудиту. Отримайте консультацію щодо вашого проекту — оцінимо поточний стан і запропонуємо план прискорення з конкретними термінами та бюджетом. Ми — команда з 10+ роками досвіду в Бітрікс, виконали понад 200 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.

1С Бітрікс презентація1С Бітрікс24 презентація1С Підприємство презентація