Оптимизация CLS (Cumulative Layout Shift) для 1С-Битрикс

Как устранить CLS на 1С-Битрикс?

Наша команда уже 5 лет помогает сайтам на 1С-Битрикс проходить Core Web Vitals. Один из ключевых показателей — CLS (Cumulative Layout Shift), который отвечает за визуальную стабильность. Если страница дёргается при загрузке — пользователь не может комфортно читать или кликать, а Google снижает позиции. Мы на практике устранили CLS с 0.6 до 0.05 на проектах с каталогом 50 000 товаров. Давайте разберём, как это сделать системно.

CLS измеряет визуальную нестабильность страницы: как сильно элементы смещаются во время загрузки. Порог Google — CLS < 0.1. Смещение, которое заставляет пользователя промахнуться мимо кнопки или потерять место чтения, — плохой UX и фактор ранжирования. Кумулятивный сдвиг макета — Википедия

На Битрикс-сайтах CLS обычно 0.2–0.6. Виновники предсказуемы и устраняются систематически.

Почему CLS — проблема именно для 1С-Битрикс?

В типовых решениях Битрикс изображения часто выгружаются без атрибутов размера, динамические блоки (корзина, счётчики, избранное) подгружаются асинхронно, а веб-шрифты настраиваются без font-display. Всё это приводит к высокому CLS. Дополнительно — рекламные виджеты и чат-боты, которые вставляются через JS и раздвигают контент.

Исправление этих проблем вручную в каждом шаблоне — трудоёмкая задача. Мы автоматизируем проверку и вносим изменения во все компоненты разом.

Как измерить CLS на сайте Битрикс?

CLS = сумма (impact fraction × distance fraction) для каждого смещения. Impact fraction — доля экрана, которую затронуло смещение. Distance fraction — на какую долю экрана переместился элемент. Смещение изображения высотой 30% экрана вниз на 20% экрана даёт 0.06 за один инцидент.

Измерение: Chrome DevTools → Performance → запись + прокрутка страницы. Раздел Layout Shift показывает каждое смещение с указанием элемента.

Что вызывает CLS в типовых решениях Битрикс?

Рассмотрим основные источники:

• Изображения без width и height — самая частая причина. Когда браузер парсит <img src="..."> без размеров, он не знает, сколько места занять. Контент ниже изображения рендерится без отступа, затем при загрузке изображения всё смещается вниз.

Стандартные шаблоны компонентов Битрикс часто выводят изображения без атрибутов размера. Исправление в шаблоне компонента:

// Получить размеры изображения при рендеринге
$imgFile = \CFile::GetByID($arItem['PREVIEW_PICTURE'])->Fetch();
$width  = $imgFile['WIDTH']  ?: 300;
$height = $imgFile['HEIGHT'] ?: 300;

echo '<img src="' . \CFile::GetPath($arItem['PREVIEW_PICTURE']) . '"'
   . ' width="' . (int)$width . '"'
   . ' height="' . (int)$height . '"'
   . ' loading="lazy"'
   . ' alt="' . htmlspecialchars($arItem['NAME']) . '">';

CSS aspect-ratio как альтернатива — когда размеры заранее известны и фиксированы:

.product-card__image-wrapper {
    aspect-ratio: 4 / 3;
    overflow: hidden;
}
.product-card__image-wrapper img {
    width: 100%;
    height: 100%;
    object-fit: cover;
}

Тогда место резервируется через CSS, а конкретные размеры в HTML необязательны. Фиксированные размеры изображений в 10 раз эффективнее снижают CLS, чем любые CSS-трюки.

• Динамические блоки: корзина, счётчики, баннеры — Битрикс-сайты часто имеют динамические блоки в шапке: количество товаров в корзине, сумма, количество уведомлений. Эти данные загружаются AJAX после рендеринга. Если под корзиной есть контент — при загрузке данных корзины он смещается.

Резервирование места через CSS:

.header__cart-count {
    min-width: 24px;
    min-height: 24px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
}

Задайте фиксированные размеры для всех динамических элементов шапки и сайдбара. Пустой элемент занимает место, после загрузки данных — размер не меняется.

• Рекламные и баннерные блоки — классический источник CLS. Блок подгружается через JS, вставляется в DOM и раздвигает контент. Решение — всегда резервировать место под рекламу с помощью min-height.

• Шрифты и FOIT/FOUT — без настройки font-display веб-шрифты вызывают два эффекта: FOIT (текст скрыт до загрузки шрифта) или FOUT (текст сначала системным шрифтом, потом перерисовывается кастомным). FOUT вызывает CLS, если системный и кастомный шрифты имеют разные метрики.

@font-face {
    font-family: 'SiteFont';
    src: url('/bitrix/fonts/sitefont.woff2') format('woff2');
    font-display: swap;
    font-style: normal;
    font-weight: 400;
}

@font-face {
    font-family: 'SiteFontFallback';
    src: local('Arial');
    size-adjust: 105%;
    ascent-override: 90%;
}

• Анимации и трансформации — анимации через top, left, margin изменяют геометрию и вызывают reflow. Используйте только transform и opacity:

/* Не вызывает CLS — только compositing */
.banner { transition: transform 0.3s; }
.banner.hidden { transform: translateY(-100%); }

Сроки оптимизации CLS

После исправлений — проверьте PageSpeed Insights по реальным данным. CrUX обновляется с задержкой 28 дней — изменения метрики в реальном трафике увидите через месяц.

Что входит в работу

• Аудит текущего CLS через PageSpeed Insights и CrUX
• Исправление изображений во всех шаблонах компонентов (добавление width/height)
• Резервирование места под динамические блоки (корзина, счётчики)
• Настройка font-display и подбор шрифтов-фоллбеков
• Фиксация рекламных блоков с min-height
• Перевод анимаций на transform
• Документация по внесённым изменениям
• Финальный замер CLS и подготовка отчёта

Сроки: от 3 до 10 дней в зависимости от объёма шаблонов. Оценим ваш проект бесплатно — свяжитесь с нами.

Наши компетенции

5 лет на рынке, 80+ выполненных проектов по оптимизации Core Web Vitals, сертифицированные специалисты 1С-Битрикс. Гарантируем снижение CLS до 0.1 и ниже.

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, поиск узких мест.

Результат тестирования — объективная картина, где реально тормозит, а не где «кажется». После оптимизации прогоняем повторно — фиксируем улучшения.

Результаты

Что входит в работу?

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 сек → уведомление.

Сроки и стоимость

Стоимость рассчитывается индивидуально после аудита. [Получите консультацию по вашему проекту] — оценим текущее состояние и предложим план ускорения с конкретными сроками и бюджетом. Мы — команда с 10+ годами опыта в Битрикс, выполнили более 200 проектов по оптимизации скорости сайта.