Оптимизация критического 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 Appointment Booking Widget for a Medical Center
    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С-Битрикс

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

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-запросов и заканчивается комплексной перестройкой инфраструктуры под ключ.

[Свяжитесь с нами для аудита] — мы определим узкие места за 2 часа и предложим конкретный план.

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

Nginx. Не просто «включили gzip». Конкретно:

  • gzip_comp_level 4-5 — выше бессмысленно, CPU сжирает больше, чем экономит трафик;
  • brotli on с brotli_static on — для предварительно сжатых файлов;
  • 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 раз.

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

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

Фронтенд

Изображения — 60–80% веса страницы:

  • WebP через CFile::ResizeImageGet() с BX_RESIZE_IMAGE_PROPORTIONAL + конвертация;
  • srcset + sizes — не грузим 3000px картинку в блок 400px;
  • loading="lazy" для всего ниже первого экрана;
  • AVIF — ещё 20–30% экономии vs WebP (подробнее: 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С Предприятие презентация