Сайт на 1С-Битрикс грузится 4–8 секунд? LCP >4 с, CLS >0.2, INP >200 мс — типичная картина для магазинов на этой CMS. Google учитывает Core Web Vitals при ранжировании, а пользователи уходят при задержке больше 3 секунд. Мы проводим аудит и оптимизацию под ключ: от диагностики до финального тестирования с гарантией прохождения PageSpeed Insights. Опыт — 5+ лет, более 50 проектов. Недавно мы работали с интернет-магазином автозапчастей на Битрикс: LCP составлял 6.2 с, CLS 0.3, INP 250 мс. После оптимизации — LCP 1.8 с, CLS 0.05, INP 120 мс. Конверсия выросла на 22%, отказы снизились на 25%. Инвестиции в оптимизацию окупаются за 3–6 месяцев за счёт роста конверсии и снижения отказов.
Почему Core Web Vitals критичны для сайта на Битрикс?
Google использует эти метрики для оценки пользовательского опыта. Плохие Core Web Vitals снижают конверсию на 20–40% и ухудшают позиции. Для Битрикс-сайтов основные источники проблем:
- LCP: медленный TTFB + большие изображения в главном баннере
- CLS: изображения без width/height, шрифты без font-display, динамические блоки (корзина, баннеры)
- INP: тяжёлый JavaScript, блокирующие скрипты в head
На практике каждый второй магазин на Битрикс не проходит оценку Google. Мы решаем эти проблемы с гарантией результата.
Согласно рекомендациям Google, LCP должен быть менее 2.5 секунд, CLS — менее 0.1, INP — менее 200 миллисекунд.
Что входит в оптимизацию Core Web Vitals?
Диагностика
Используем Chrome DevTools Lighthouse для синтетики и PageSpeed Insights для данных реальных пользователей (CrUX). Оцениваем TTFB, размер JS/CSS, изображения, настройки кэша. Результат — детальный отчёт с приоритетами.
LCP: критический путь рендеринга
LCP-элемент в Битрикс-магазине — обычно главный баннер или первое изображение. Проблема: изображение подгружается через JS после рендеринга. Решение — preload с fetchpriority="high":
<link rel="preload" as="image" href="/upload/banners/main.webp"
imagesizes="100vw" fetchpriority="high">
Добавляется в <head> через AddHeadString() компонента. Слайдеры — главный враг: Swiper.js добавляет 100–300 КБ JS. Оптимизация: первый слайд в статичном HTML, JS-инициализация через defer или requestIdleCallback.
CLS: смещения макета
CLS ненулевой в Битрикс из-за:
-
Изображения без размеров. Стандартные компоненты часто выводят
<img> без width/height. Добавляем размеры:
// В template.php компонента catalog.element
$width = $arItem['PREVIEW_PICTURE']['WIDTH'] ?? 300;
$height = $arItem['PREVIEW_PICTURE']['HEIGHT'] ?? 300;
echo '<img src="' . $arItem['PREVIEW_PICTURE']['SRC'] . '" '
. 'width="' . $width . '" height="' . $height . '" '
. 'loading="lazy" decoding="async" alt="' . htmlspecialchars($arItem['NAME']) . '">';
JavaScript: блокировка рендеринга и INP
В Битрикс в <head> часто подключаются 10–20 JS-файлов через CJSCore::Init(). Переводим на defer:
<script src="/bitrix/js/main/core.js" defer></script>
В настройках модуля «Производительность» включаем перенос скриптов в конец страницы. INP диагностируем через DevTools Performance.
Изображения: WebP и lazy loading
Настраиваем модуль resize_image в /bitrix/.settings.php:
'resize_image' => [
'value' => [
'webp' => true,
'webp_quality' => 80,
],
],
Lazy loading для изображений вне экрана: loading="lazy" decoding="async". LCP-изображение — без lazy. WebP сжимает изображения на 30-50% лучше JPEG без потери качества, что ускоряет загрузку.
CSS: критический путь
Встраиваем критический CSS в <style> в <head>, остальное загружаем асинхронно через <link rel="preload" as="style" onload="this.rel='stylesheet'">. Используем PurgeCSS для удаления неиспользуемых стилей.
Как оптимизировать LCP пошагово?
- Определите LCP-элемент через Chrome DevTools.
- Убедитесь, что это изображение предзагружено с
fetchpriority="high".
- Оптимизируйте изображение: WebP с качеством 80%, размер не более 200 КБ.
- Настройте кэширование TTFB: используйте тегированное кэширование Битрикс.
- Перенесите блокирующие скрипты в footer или используйте
defer.
Как тегированное кэширование влияет на TTFB?
Тегированное кэширование в Битрикс позволяет сбрасывать кэш только у тех блоков, которые изменились, вместо полного сброса. Это снижает TTFB до 50 мс против 200-400 мс без кэша. Настройка ведётся через файл /bitrix/.settings.php и компоненты с поддержкой кэширования.
Типичные ошибки при оптимизации
- Забывают про TTFB: без настройки сервера и кэша LCP не улучшится.
- Используют
loading="lazy" на LCP-изображении — это ухудшает LCP.
- Не резервируют место под динамические блоки (корзина, слайдеры) — CLS остаётся высоким.
Пример расчёта экономии
При среднем чеке 2 000 руб. и конверсии 3%, снижение отказов на 25% даёт дополнительно 30 заказов в месяц с 10 000 посетителей. Итого +60 000 руб. выручки ежемесячно.
Что вы получаете после оптимизации?
| Метрика |
До |
После |
Улучшение |
| LCP |
4–8 с |
<2.5 с |
в 2–3 раза |
| CLS |
0.2–0.5 |
<0.1 |
в 2–5 раз |
| INP |
>200 мс |
<200 мс |
>30% |
Сравнение методов оптимизации изображений
| Метод |
Сжатие |
Качество |
Поддержка |
| WebP |
30-50% |
высокое |
все современные браузеры |
| JPEG |
10-20% |
среднее |
универсальная |
| PNG |
без потерь |
высокое |
универсальная |
Почему выбирают нас?
- 5+ лет опыта с Битрикс
- 50+ выполненных проектов
- Сертифицированные специалисты
- Гарантия прохождения PageSpeed Insights
Закажите аудит и получите детальный отчёт с рекомендациями. Свяжитесь с нами для консультации — оценим ваш сайт и предложим план оптимизации Core Web Vitals.
Подробнее о метриках: официальная страница Core Web Vitals. Дополнительная информация по настройке кэша: документация 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, поиск узких мест.
Результат тестирования — объективная картина, где реально тормозит, а не где «кажется». После оптимизации прогоняем повторно — фиксируем улучшения.
Результаты
| Метрика |
До |
После |
| TTFB |
800–2000 мс |
50–200 мс |
| Полная загрузка |
4–8 сек |
1.5–2.5 сек |
| PageSpeed (мобильный) |
30–50 |
80–95 |
| Одновременные пользователи |
50–100 |
500–2000+ |
Что входит в работу?
-
Аудит текущей производительности — анализ slow-запросов, профилирование PHP, проверка кэширования, CDN, серверных настроек.
-
Настройка серверной части — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
-
Оптимизация кэширования — управляемый кэш, композитный сайт, настройка TTL, тегированное кэширование.
-
Работа с БД — создание индексов, партиционирование, очистка, реорганизация EAV-таблиц.
-
Фронтенд — изображения (WebP/AVIF), CSS/JS (минификация, deferred), шрифты (preload, subsetting).
-
CDN — подключение, настройка правил кэширования.
-
Нагрузочное тестирование — сценарии реальных пользователей, отчёт по метрикам.
-
Документация — описание всех изменений, рекомендации по дальнейшему обслуживанию.
-
Гарантия — поддержка в течение 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 проектов по оптимизации скорости сайта.
