Как ускорить сайт на Битрикс: чек-лист Core Web Vitals

Коротко

Сайт на 1С-Битрикс ускоряют по приоритетам: включают композитный сайт и автокэширование, оптимизируют изображения и каталог, подключают CDN, отключают лишние модули и переходят на актуальную версию PHP. Эти шаги напрямую улучшают Core Web Vitals — LCP, INP и CLS — и позиции в поиске.

80% ускорения Битрикса дают три вещи: композитный кэш, оптимизация изображений и актуальный PHP. Остальные шаги добирают оставшееся и закрывают частные проблемы: тяжёлый каталог, лишние скрипты, слабый хостинг.

Целевые значения Core Web Vitals, к которым стоит стремиться:

Метрика	Что измеряет	Хорошее значение	Главный рычаг на Битриксе
LCP	Скорость появления основного контента	≤ 2,5 с	Композитный кэш, изображения, CDN
INP	Отзывчивость на действия пользователя	≤ 200 мс	Меньше тяжёлого JS, минификация
CLS	Стабильность вёрстки при загрузке	≤ 0,1	Размеры изображений, резерв места под блоки

Основная мысль

Битрикс не медленный сам по себе: медленным его делают выключенное кэширование, тяжёлые картинки, неоптимизированный каталог и устаревшее серверное окружение, поэтому ускорение начинается не с покупки сервера, а с настройки того, что в платформе уже есть.

В 1С-Битрикс из коробки есть композитный сайт, управляемый и тегированный кэш, объединение и сжатие CSS и JS, панель производительности. На многих проектах эти инструменты либо выключены, либо включены частично, либо сломаны доработками шаблона. Поэтому первый шаг — не переписывать сайт, а проверить базовые настройки.

Второй важный момент — порядок работ. Если начать с тонкой настройки JS, а композитный кэш так и не включить, результат будет едва заметен. Если сначала закрыть крупные проблемы, мелкие правки дают уже ощутимый прирост. Ниже разберём шаги именно в порядке их влияния на скорость.

Третий момент — измерение. Без замеров до и после невозможно понять, какой шаг сработал, а какой только добавил сложности. Поэтому каждую группу изменений проверяют отдельно и фиксируют результат.

Чек-лист ускорения по приоритетам

Короткая версия чек-листа, с которой удобно начинать аудит любого сайта на Битриксе:

Включите «Композитный сайт» — кэширование готовых страниц, самый большой эффект на LCP.
Настройте автокэширование компонентов и тегированный кэш.
Оптимизируйте изображения: сжатие, современные форматы (WebP), нужные размеры, lazy-load.
Оптимизируйте каталог: индексы БД, ограничение выборок, кэш умного фильтра.
Подключите CDN для статики (картинки, CSS, JS).
Объедините и минифицируйте CSS/JS, уберите render-blocking ресурсы.
Перейдите на актуальную версию PHP и включите OPcache.
Отключите неиспользуемые модули и лишние обработчики.
Проверьте результат в PageSpeed Insights и «Скорости сайта» в Вебмастере.

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

Кэширование: композитный сайт и кэш компонентов

Что даёт композитный сайт

Композитный сайт отдаёт заранее собранную статическую версию страницы, а динамические части — корзину, имя пользователя, персональные цены — подгружает отдельно. Посетитель видит контент почти сразу, не дожидаясь, пока сервер выполнит все запросы к базе данных. Именно поэтому композит сильнее всего влияет на LCP.

Включается композит в административной части, в разделе настроек производительности. Но просто поставить галочку мало. Нужно проверить, какие блоки шаблона помечены как динамические, и убедиться, что после включения ничего не сломалось: корзина показывает правильное число товаров, формы отправляются, авторизованный пользователь видит свои данные.

Автокэширование и тегированный кэш

Помимо композита, у каждого компонента Битрикса есть собственный кэш. Автокэширование компонентов включается глобально, а тегированный кэш позволяет сбрасывать кэш точечно: изменили товар — сбросился кэш только связанных с ним блоков, а не всего сайта.

Типичная проблема — доработанные компоненты, в которых кэш отключён параметром или сброшен вызовами в шаблоне. Такие места находят через панель отладки: она показывает, какие компоненты работают без кэша и сколько запросов к базе они делают.

Где кэш ломается чаще всего

Кастомные компоненты, написанные без поддержки кэша.
Вывод случайных товаров или «рекомендуемого» блока, который каждый раз строится заново.
Персонализированные блоки в шапке, из-за которых композит не может отдать страницу.
Слишком частый сброс кэша при обмене с 1С, когда выгрузка каждый раз очищает всё.

Пример сценария

Интернет-магазин после смены шаблона стал медленнее. При проверке оказалось, что новый шаблон выводит в шапке блок с персональными данными без пометки динамической области, из-за чего композит перестал работать. Разметка блока как динамического вернула кэширование страниц, и время появления основного контента снова уложилось в норму.

Изображения: самый частый источник медленного LCP

Что делать с картинками

На большинстве сайтов основной элемент первого экрана — это изображение: баннер, фото товара, иллюстрация. Поэтому LCP почти всегда упирается в картинки. Что стоит сделать:

Сжать изображения без видимой потери качества.
Перевести в WebP — современный формат с меньшим весом при том же качестве.
Отдавать нужный размер: не грузить огромное исходное фото в маленькую карточку товара.
Включить lazy-load для изображений ниже первого экрана.
Не откладывать загрузку главного изображения первого экрана — наоборот, его стоит загружать как можно раньше.

Изображения и CLS

Картинки влияют не только на скорость, но и на стабильность вёрстки. Если у изображения не заданы размеры, браузер не знает, сколько места под него оставить, и контент «прыгает» при загрузке. Это напрямую ухудшает CLS. Решение — указывать ширину и высоту или соотношение сторон, а также резервировать место под баннеры и рекламные блоки.

Как организовать процесс

Оптимизировать изображения вручную на сайте с тысячами товаров нереально. Обычно настраивают автоматическое создание уменьшенных копий и перевод в WebP при загрузке, а старые изображения обрабатывают пакетно. Контент-менеджерам дают простое правило: не загружать фото прямо с камеры без подготовки.

Каталог и база данных

Почему каталог тормозит

Каталог — самая нагруженная часть магазина на Битриксе. Каждая страница раздела делает выборку товаров, цен, остатков и свойств, а умный фильтр добавляет ещё запросы. Если в базе нет нужных индексов, а выборки не ограничены, страница собирается долго, и это видно по времени ответа сервера.

Что оптимизируют

Индексы БД по полям, которые участвуют в фильтрации и сортировке.
Ограничение выборок: запрашивать только нужные поля и свойства, а не всё подряд.
Кэш умного фильтра и фасетный индекс, чтобы фильтр не пересчитывался при каждом запросе.
Постраничный вывод вместо загрузки сотен товаров на одну страницу.
Разделение тяжёлых операций: пересчёт остатков и цен после обмена с 1С лучше выполнять в фоне.

Сценарий из практики

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

Если каталог требует доработки кода, а не только настроек, такую работу лучше делать вместе с общей доработкой сайта на 1С-Битрикс, чтобы не сломать обмен с 1С и логику цен.

Фронтенд: CSS, JavaScript и сторонние скрипты

Объединение и минификация

В Битриксе есть встроенное объединение и сжатие CSS и JS. Оно уменьшает число запросов и вес файлов. Но включать его нужно аккуратно: на сайтах с доработанным шаблоном порядок подключения скриптов иногда важен, и после объединения что-то может перестать работать. Поэтому после включения проверяют корзину, формы, фильтр и слайдеры.

Render-blocking ресурсы

Ресурсы, блокирующие отрисовку, — это CSS и JS, без которых браузер не начинает показывать страницу. Чем их больше, тем позже пользователь видит контент. Что помогает:

переносить некритичные скрипты в конец страницы или загружать их отложенно;
выделять критичные стили первого экрана, а остальное подгружать позже;
убирать неиспользуемые библиотеки, которые остались от старых версий шаблона.

INP и тяжёлый JavaScript

INP показывает, как быстро страница реагирует на клик, ввод или открытие меню. Если основной поток браузера занят выполнением тяжёлых скриптов, реакция запаздывает. Меньше тяжёлого JS и аккуратная минификация — главный способ уложиться в норму INP ≤ 200 мс.

Сторонние скрипты

Десятки счётчиков, чатов, виджетов обратного звонка и пикселей в шапке сайта — одна из самых недооценённых причин медленной работы. Каждый такой скрипт загружается с чужого сервера, и сайт не может ускорить его сам. Полезно регулярно проверять список: какие из подключённых сервисов реально используются, а какие остались от прошлых рекламных кампаний.

Сервер, PHP, CDN и модули

Версия PHP и OPcache

Устаревшая версия PHP заметно медленнее актуальной. Переход на свежую поддерживаемую версию и включение OPcache ускоряют выполнение кода без изменения самого сайта. Перед переходом нужно проверить совместимость модулей и доработок: старый код иногда требует правок.

Хостинг

Дешёвый хостинг, не рассчитанный на Битрикс и нагрузку, может свести на нет всю оптимизацию. Для Битрикса важны достаточный объём памяти, быстрые диски и правильно настроенная связка веб-сервера и базы данных. Хорошим ориентиром служит окружение, подготовленное под Битрикс.

CDN для статики

CDN раздаёт картинки, CSS и JS с серверов, расположенных ближе к посетителю, и снимает нагрузку с основного сервера. Особенно это заметно, если аудитория сайта находится в разных регионах. В Битриксе есть встроенная поддержка CDN, но её тоже нужно настроить и проверить, что все ресурсы действительно отдаются через неё.

Нужен ли отдельный сервер

Не всегда. Часто достаточно включить кэш, оптимизировать изображения и каталог и перейти на актуальный PHP. Отдельный или более мощный сервер нужен при действительно высокой нагрузке, когда настройки уже сделаны, а ресурсов всё равно не хватает.

Неиспользуемые модули

За годы работы на сайте накапливаются модули, которые когда-то поставили для теста или разовой задачи. Многие из них подключают свои обработчики событий и выполняются на каждой странице. Отключение неиспользуемых модулей и лишних обработчиков снижает нагрузку без потери функций.

Агенты и фоновые задачи

Агенты Битрикса по умолчанию могут запускаться на хитах, то есть во время обычных запросов посетителей. Если агентов много, случайный посетитель ждёт, пока выполнится фоновая задача. Перевод агентов на запуск через планировщик сервера убирает эту задержку.

Логи и временные данные

Разросшиеся таблицы статистики, журналов и сессий замедляют работу базы данных. Регулярная очистка устаревших данных и отключение ненужной статистики — простой, но часто забытый шаг.

Порядок работ и контроль результата

Инструменты

Проверяйте результат в PageSpeed Insights и в разделе «Скорость сайта» в Вебмастере. PageSpeed показывает и лабораторные замеры, и данные реальных пользователей, если они накоплены. Вебмастер показывает, как скорость видят посетители из поиска. Внутри Битрикса полезна панель производительности и отладка страниц: они показывают время работы компонентов и число запросов к базе.

Как проверять правильно

Что проверять	Где смотреть	Зачем
LCP, INP, CLS	PageSpeed Insights	Сравнение с нормами Core Web Vitals
Скорость для посетителей из поиска	«Скорость сайта» в Вебмастере	Оценка на реальной аудитории
Время работы компонентов	Панель отладки Битрикса	Поиск компонентов без кэша
Нагрузка на сервер	Панель производительности	Оценка хостинга и настроек

Замеряйте не только главную, но и типовые страницы: раздел каталога, карточку товара, корзину, статью. У магазина именно каталог и карточка чаще всего оказываются самыми медленными. Данные реальных пользователей обновляются не сразу, поэтому после изменений нужно время, чтобы увидеть результат в отчётах.

Если нужна полная картина с приоритетами, скорость разумно проверять в рамках технического SEO-аудита сайта: там же находятся проблемы индексации, дубли и ошибки шаблона, которые тоже влияют на позиции.

Этап 1. Диагностика

Сначала собирают исходные замеры по ключевым страницам и смотрят, что именно тормозит: время ответа сервера, тяжёлые изображения, скрипты или сдвиги вёрстки. Параллельно проверяют настройки кэша, версию PHP, список модулей и агентов. На этом этапе становится понятно, какие проблемы закрываются настройками, а какие требуют правки кода.

Этап 2. Быстрые настройки

Затем включают и проверяют то, что не требует переписывания сайта: композитный сайт, автокэширование, OPcache, объединение CSS и JS, перевод агентов на планировщик. Каждое изменение проверяют отдельно, чтобы при сбое сразу видеть причину.

Этап 3. Работа с контентом и каталогом

Дальше обрабатывают изображения, настраивают автоматическое создание уменьшенных копий и WebP, строят фасетный индекс, добавляют индексы в базу, ограничивают выборки. Это более трудоёмкая часть, но именно она решает проблемы магазинов с большим каталогом.

Этап 4. Доработка шаблона

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

Этап 5. Контроль

После всех изменений повторяют замеры, сравнивают с исходными значениями и договариваются о регулярной проверке. Скорость — не разовая задача: новые баннеры, виджеты и модули постепенно возвращают сайт к прежнему состоянию, если за этим не следить.

Почему Битрикс тормозит и на чём опасно экономить

Типичные причины торможения

Сводный список того, что чаще всего находится при проверке медленного сайта:

Отключён композитный сайт и кэширование компонентов.
Тяжёлые несжатые изображения в оригинальном размере без WebP и lazy-load.
Неоптимизированные выборки каталога и умного фильтра, нехватка индексов в БД.
Устаревшая версия PHP без OPcache.
Десятки сторонних скриптов, метрик и виджетов в шапке сайта.
Дешёвый хостинг, не рассчитанный на Битрикс и нагрузку.

Ошибки при самостоятельном ускорении

Включить всё сразу и не проверить. Композит, объединение JS и CDN, включённые одновременно, могут сломать корзину или формы, а найти причину будет сложно.
Работать без резервной копии. Любые изменения настроек, PHP и базы стоит делать только после бэкапа.
Оптимизировать только главную. Посетители из поиска чаще попадают на карточки и разделы.
Гнаться за баллом PageSpeed. Важны метрики реальных пользователей и конверсия, а не цифра в лабораторном тесте.
Удалять модули вместо отключения. Удалённый модуль может оказаться нужным для обмена с 1С или оплаты.

Короткий чек-лист перед запуском изменений

Сделана резервная копия файлов и базы.
Замерены исходные значения LCP, INP и CLS на ключевых страницах.
Изменения вносятся по одному блоку и проверяются.
После каждого шага проверены корзина, формы, фильтр и обмен с 1С.
Результат зафиксирован и сравнен с исходными значениями.

Частые вопросы

Что даёт композитный сайт?

Композитный сайт отдаёт заранее собранную статическую версию страницы, а динамику подгружает отдельно. Это резко сокращает время до появления контента и улучшает LCP. Главное — правильно разметить динамические блоки, чтобы корзина и персональные данные работали корректно.

Почему магазин на Битрикс тормозит?

Частые причины: отключённое кэширование, тяжёлые несжатые изображения, неоптимизированные выборки каталога и умного фильтра, устаревший PHP, лишние модули и сторонние скрипты. Обычно проблема не одна, а несколько сразу, поэтому начинать лучше с диагностики.

Ускорение влияет на позиции в поиске?

Да. Скорость и Core Web Vitals — фактор ранжирования, а также напрямую влияют на конверсию: медленный магазин теряет заказы. Быстрый сайт при прочих равных получает преимущество и в поиске, и в поведении посетителей.

Нужен ли отдельный сервер для скорости?

Поможет ли просто включить кэш?

Композитный кэш даёт самый заметный прирост, но это не «серебряная пуля». Без оптимизации изображений, каталога и PHP часть проблем со скоростью останется.

Какие значения Core Web Vitals считаются хорошими?

Хорошими считаются LCP ≤ 2,5 с, INP ≤ 200 мс и CLS ≤ 0,1. Ориентироваться стоит на данные реальных пользователей, а не только на лабораторный замер.

С чего начать, если времени и бюджета мало?

С трёх шагов, которые дают основной эффект: композитный кэш, оптимизация изображений и актуальный PHP. Их можно сделать быстро, а остальные пункты чек-листа выполнять постепенно.

Сломается ли сайт после включения композита или объединения JS?

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

Влияет ли обмен с 1С на скорость?

Да. Если выгрузка каждый раз полностью сбрасывает кэш и запускает тяжёлые пересчёты во время работы сайта, посетители это почувствуют. Помогает точечный сброс тегированного кэша и выполнение тяжёлых операций в фоне.

Как часто нужно проверять скорость?

После каждого заметного изменения — нового шаблона, модуля, виджета или обновления платформы. Кроме того, полезно смотреть отчёты по скорости раз в месяц: проблемы часто появляются незаметно, вместе с новыми баннерами и скриптами.

Сколько стоит ускорение сайта на Битриксе?

Зависит от объёма работ: иногда хватает настройки кэша и изображений, иногда нужна переработка каталога и шаблона. Работы по доработке и поддержке обычно оцениваются почасово, от 2 000 ₽ в час, а точный объём понятен после диагностики.

Итог

Ускорение сайта на 1С-Битрикс — это не одна настройка, а последовательность шагов. Основной эффект дают композитный кэш, оптимизация изображений и актуальный PHP, а каталог, CDN, фронтенд и чистка модулей добирают остальное и закрывают частные проблемы.

Работать стоит по приоритетам, с замерами до и после каждого шага и с резервной копией. Ориентир — нормы Core Web Vitals: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1 на реальных пользователях и на ключевых страницах, а не только на главной.

Если нужно ускорить сайт на 1С-Битрикс и довести Core Web Vitals до зелёной зоны, я как частный разработчик могу провести диагностику, настроить кэширование, оптимизировать каталог и изображения и проверить результат на реальных метриках. Подробнее — на странице услуги ускорение сайта. Работаю напрямую, без посредников.