Сайт на 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']) . '">';
-
Корзина и счётчики. Резервируем место через CSS:
min-width: 40px; min-height: 40px. -
Шрифты. Используем
font-display: swap.
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С-Битрикс.