Как ускорить сайт на 1С-Битрикс: чек-лист

Сайт на 1С-Битрикс, который «тормозит», — одна из самых частых причин обращений в TruWeb. Причём чаще всего дело не в самой платформе: Битрикс изначально проектировался с расчётом на высокую нагрузку и содержит встроенные инструменты ускорения, которые просто не включены или настроены «по умолчанию». За 15+ лет работы с 1С-Битрикс мы провели десятки аудитов производительности — от небольших корпоративных сайтов до интернет-магазинов с тысячами SKU и пиковыми нагрузками в сезон распродаж. Ниже — обновлённый практический чек-лист: что проверять в первую очередь, какие решения дают максимальный эффект при минимальных затратах и каких ошибок стоит избегать, если вы решили ускорить сайт своими силами или ставите задачу подрядчику.

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

Почему скорость — это не только про удобство

Скорость загрузки давно перестала быть вопросом исключительно комфорта пользователя. Есть минимум три причины отнестись к ней как к бизнес-показателю, а не как к техническому «капризу».

Core Web Vitals как фактор ранжирования. Google использует показатели скорости и стабильности интерфейса (LCP, INP, CLS) как один из сигналов ранжирования, особенно заметный при прочих равных условиях — когда несколько сайтов конкурируют за одну и ту же выдачу по коммерческим запросам. Если у конкурента карточка товара грузится за 1,5 секунды, а у вас — за 5, при равном качестве контента и ссылочного профиля выигрывает более быстрый сайт. Подробнее о том, как скорость и технические факторы влияют на позиции, — в статье SEO-продвижение сайта на Битрикс.

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

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

Сначала измерьте, потом чините

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

Базовый набор инструментов для диагностики:

• PageSpeed Insights — быстрый внешний срез: показывает и лабораторные данные (Lighthouse), и полевые данные реальных пользователей (CrUX), если у сайта достаточно трафика для их накопления.
• Lighthouse (встроен в Chrome DevTools) — детальная лабораторная диагностика с указанием конкретных «тяжёлых» ресурсов, блокирующих скриптов и рекомендаций по каждому пункту.
• Метрики LCP, CLS, INP — три опорных показателя Core Web Vitals; их нужно смотреть в динамике, а не разово, и обязательно отдельно для мобильной и десктопной версии.
• Встроенный монитор производительности Битрикс — раздел «Настройки → Инструменты разработчика → Монитор производительности» показывает время выполнения каждого компонента, количество запросов к базе данных и «горячие точки» прямо в админке, без внешних сервисов.

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

Композитный сайт — главный рычаг ускорения

Если бы нужно было выбрать одну настройку, которая даёт максимальный эффект при минимальных затратах, это композитный режим (Composite Site). Идея проста: для неавторизованных посетителей — а это, как правило, 80–95% трафика — Битрикс кэширует полностью собранный HTML страницы целиком, включая шапку, меню, футер и статичный контент. Динамические блоки (корзина, счётчик избранного, персональные предложения, авторизация) подгружаются отдельно, AJAX-запросом поверх уже показанной страницы.

Эффект — страница физически отдаётся пользователю почти мгновенно, потому что серверу не нужно каждый раз заново собирать её из десятков компонентов и обращений к базе данных. Именно композитный режим чаще всего даёт наибольший прирост в тестах PageSpeed Insights и Lighthouse — иногда в разы, без единой строчки нового кода.

Но здесь есть нюансы, которые важно понимать до включения:

• Композит требует корректной настройки исключений — страницы с формами, личным кабинетом, оформлением заказа не должны кэшироваться целиком или должны кэшироваться с осторожностью.
• Если на сайте много кастомной логики (нестандартные компоненты, самописные модули), их нужно протестировать отдельно — не все они «из коробки» совместимы с композитным кэшированием.
• После включения композита обязательно нужно проверить сценарии: добавление в корзину, авторизацию, работу форм обратной связи, персонализацию — здесь чаще всего случаются регрессии, о которых расскажем отдельно в разделе про типичные ошибки.

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

Кэширование в 1С-Битрикс: три уровня

Композит — это, по сути, надстройка над более базовой системой кэширования Битрикс, которая работает на трёх уровнях, и полезно понимать разницу.

Автокэширование компонентов

Многие стандартные компоненты Битрикс (новости, каталог, меню) имеют встроенное автокэширование, которое включается прямо в параметрах компонента — «Кэширование» → «Включено». Это самый простой уровень: результат работы компонента сохраняется на заданное время и не пересчитывается заново при каждом заходе. Проблема в том, что на многих сайтах это кэширование либо выключено «на всякий случай» ещё на этапе разработки, либо настроено с неоправданно коротким временем жизни.

Управляемый кэш (тегированный)

Более гибкий механизм — управляемый кэш с тегированием. Он позволяет не просто хранить закэшированные данные заданное время, а сбрасывать конкретные фрагменты кэша точечно, по событию — например, при изменении цены товара сбрасывается кэш именно карточки этого товара и связанных с ним разделов каталога, а не всего сайта целиком. Неправильная настройка тегов — частая причина, когда на сайте видна «неактуальная» информация (старая цена, товар, которого уже нет в наличии) при включённом кэше.

HTML-кэш статичных блоков и композит

Верхний уровень — кэширование уже готовой HTML-разметки блоков или всей страницы целиком (композитный режим, о котором мы говорили выше). Это самый мощный, но и самый требовательный к аккуратности настройки уровень: ошибка здесь заметна сразу всем посетителям сайта.

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

Изображения и фронтенд

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

• Lazy loading — отложенная загрузка изображений, которые не попадают в первый экран (атрибут loading="lazy" или JS-реализация для более старых шаблонов). Браузер не тратит ресурсы на загрузку того, что пользователь может так и не увидеть.
• srcset и адаптивные изображения — отдача разных размеров картинки в зависимости от разрешения экрана устройства, чтобы на мобильном телефоне не грузилось изображение, рассчитанное на десктопный монитор.
• WebP/AVIF — современные форматы изображений, которые при сопоставимом визуальном качестве весят на 25–60% меньше JPEG/PNG. На каталогах с тысячами товарных фото это даёт ощутимую экономию трафика и ускорение LCP.
• Минификация и объединение CSS/JS — встроенная в Битрикс опция «Настройки → Настройки продукта → Автоматическая оптимизация CSS и JavaScript» сжимает и объединяет файлы, уменьшая количество запросов к серверу и вес каждого из них.
• Критический CSS и отложенная загрузка скриптов — выделение минимально необходимых стилей для отрисовки первого экрана и загрузка остального CSS/JS асинхронно (defer/async), чтобы скрипты не блокировали рендеринг страницы.

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

База данных и сервер

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

• Slow query log — журнал медленных запросов MySQL/MariaDB стоит включать регулярно на 1–2 дня под реальной нагрузкой, а не разово. Он показывает конкретные запросы, которые выполняются дольше порогового значения, и часто выявляет отсутствующие индексы или неэффективные самописные выборки в кастомных модулях.
• PHP OPcache — кэш байт-кода PHP, который исключает повторную компиляцию PHP-скриптов при каждом запросе. Его отсутствие или неправильная настройка (слишком маленький размер кэша, из-за которого он постоянно перезаписывается) может незаметно «съедать» значительную часть производительности.
• Актуальная версия PHP — каждая новая мажорная версия PHP исторически даёт заметный прирост производительности «из коробки»; устаревшая версия — это не только риски безопасности, но и прямая потеря скорости.
• Соответствие хостинга требованиям Битрикс — платформа предъявляет конкретные требования к конфигурации сервера (версия PHP, настройки MySQL, наличие необходимых модулей и расширений). Экономия на хостинге «в лоб» часто оборачивается тем, что даже идеально настроенный сайт упирается в потолок возможностей сервера.

Если на сайте регулярно возникают ошибки 502/504, «зависания» при высокой посещаемости или странности в работе после обновлений — это тоже почти всегда серверная история, требующая отдельной диагностики хостинга и конфигурации PHP/MySQL.

Мобильная версия — отдельная головная боль

Google оценивает показатели скорости и стабильности именно мобильной версии сайта (mobile-first indexing), и здесь есть отдельная категория проблем, которая часто ускользает от внимания при оптимизации «в целом».

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

Что стоит проверить отдельно для мобильной версии:

• Отдаются ли изображения адаптированного под мобильный экран размера (а не просто «сжатые» стилями CSS в браузере);
• Не подгружаются ли десктопные виджеты и скрипты, которые на мобильном интерфейсе скрыты стилями, но продолжают выполняться;
• Насколько стабилен CLS на мобильных — часто «прыгающая» вёрстка на телефоне заметнее, чем на десктопе, из-за меньшего экрана;
• Соответствует ли INP (задержка отклика на взаимодействие) приемлемым значениям именно на мобильных процессорах, которые слабее десктопных.

Сторонние модули и трекеры как источник торможения

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

Типичная картина на сайте, который «оброс» интеграциями за несколько лет: 8–15 сторонних скриптов, часть из которых уже не используется, но так и не была удалена, часть — дублирует функциональность (два счётчика аналитики, две системы веб-аналитики целей), а часть загружается синхронно в <head>, блокируя отрисовку страницы до полной загрузки.

Что с этим делать:

• Провести ревизию всех подключённых сторонних скриптов минимум раз в полгода — часть можно смело удалить;
• Перевести подключение через менеджер тегов (Google Tag Manager и аналоги) — это даёт централизованный контроль над загрузкой и позволяет настраивать условия и приоритеты;
• Использовать атрибуты async/defer для всех скриптов, которые не обязаны выполниться до первой отрисовки страницы;
• Для тяжёлых виджетов (чаты, видео) рассматривать отложенную загрузку по событию — например, только после взаимодействия пользователя со страницей.

Типичная причина замедления → решение → эффект

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

Сезонные пики нагрузки и подготовка к ним

Отдельная категория задач по ускорению — не «сделать сайт быстрым в среднем», а гарантировать, что он выдержит кратный рост нагрузки в конкретные даты: чёрная пятница и предновогодние распродажи для интернет-магазинов, конец квартала или финансового года — для B2B-порталов, всплеск обращений после рекламной кампании или анонса в СМИ.

Проблема в том, что производительность, которая выглядит нормально при обычной посещаемости, может резко деградировать при 5–10-кратном росте трафика — сайт, который «летал» в будни, в пиковый день распродажи начинает отдавать 502/504 или замедляется настолько, что часть пользователей уходит, так и не оформив заказ.

Что стоит сделать заранее, минимум за 3–4 недели до ожидаемого пика:

• Нагрузочное тестирование — смоделировать ожидаемый рост трафика на тестовом контуре и посмотреть, где именно «просядет» система первой: сервер, база данных, сторонние интеграции (например, обмен с 1С или платёжным шлюзом).
• Проверка композитного режима и кэша под нагрузкой — под пиковой посещаемостью особенно важно, чтобы кэш не «протекал» и не создавал лишнюю нагрузку на пересборку страниц.
• Временное масштабирование хостинга — обсудить с хостинг-провайдером возможность временного увеличения ресурсов сервера на период пика.
• Отключение второстепенных виджетов на время пика — тяжёлые рекомендательные блоки, неважные для конверсии сторонние скрипты можно временно отключить, чтобы не создавать лишнюю нагрузку в критичные дни.
• Мониторинг в реальном времени — во время самого пика нужен человек (или система алертов), который отслеживает метрики сервера и способен быстро вмешаться, а не постфактум анализировать логи.
• План отката — заранее согласованный сценарий действий, если что-то пойдёт не так: от временного упрощения страниц до отключения проблемной интеграции.

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

Типичные ошибки при ускорении сайта

Часть проблем с производительностью появляется не из-за отсутствия оптимизации, а из-за того, что оптимизация была сделана без понимания последствий. Вот ошибки, которые мы чаще всего встречаем при повторных аудитах после чьей-то «быстрой» работы над скоростью.

• Погоня за 100 баллами PageSpeed вместо реальных метрик пользователей. Лабораторный балл в идеальных условиях теста и то, что реально ощущают пользователи на разных устройствах и сетях, — не одно и то же. Оптимизация «под цифру» иногда ухудшает реальный пользовательский опыт.
• Включение композита без проверки критичных сценариев. Корзина, оформление заказа, авторизация, формы обратной связи — эти сценарии обязательно нужно протестировать после включения композитного режима, потому что именно они чаще всего страдают от неправильно настроенных исключений.
• Избыточное сжатие изображений в ущерб качеству. Особенно критично для карточек товара в интернет-магазине — агрессивное сжатие ради скорости может визуально ухудшить фото и снизить конверсию сильнее, чем выигрыш от ускорения загрузки.
• Оптимизация только фронтенда при игнорировании сервера и БД. Красиво сжатые изображения и минифицированный CSS не спасут, если TTFB (время до первого байта) остаётся высоким из-за медленных запросов к базе данных.
• Разовая оптимизация без регулярного пересмотра. Сайт — живая система: добавляются новые модули, растёт каталог, подключаются новые интеграции. Настройки кэша и производительности, актуальные полгода назад, могут быть уже недостаточны.
• Отключение полезной аналитики вместо оптимизации её загрузки. Иногда в погоне за скоростью удаляют нужные для бизнеса счётчики и пиксели вместо того, чтобы просто перенести их загрузку в асинхронный режим.
• Слепое копирование «типового» решения без учёта кастомных доработок. На сайте с самописными модулями и нестандартной логикой универсальные рекомендации из статей (включая эту) нужно проверять на своём проекте — то, что безопасно на «коробочном» сайте, может сломать кастомный функционал.

Скорость сайта и оптимизация под AI-поиск (LLMO/AEO/GEO)

Отдельный, относительно новый аспект — как скорость и техническое качество сайта влияют на то, как его видят не только классические поисковые роботы, но и краулеры AI-систем (GPTBot, ClaudeBot и аналогичные), а также как контент сайта попадает в ответы AI-поисковиков и чат-ботов (это направление всё чаще называют LLMO, AEO или GEO — оптимизация под большие языковые модели и генеративный поиск).

Практическая связь со скоростью здесь прямая:

• У AI-краулеров, как и у обычных поисковых роботов, есть лимиты на время ожидания ответа сервера и ограниченный «бюджет» обхода — медленный или нестабильный сайт рискует быть просканирован не полностью или реже, чем конкуренты.
• Чистый, быстро отдающийся HTML без избыточных блокирующих скриптов проще корректно распарсить и системе индексации, и модели, которая формирует ответ на основе содержимого страницы.
• Структурированные данные (разметка Schema.org) помогают AI-системам точнее извлекать факты со страницы — цену, наличие, характеристики товара, ответы на частые вопросы. Мы подробно разбирали эту тему в статье Schema.org и AI-поиск — она хорошо дополняет эту статью: там про то, как быть «читаемым» для AI-систем содержательно, здесь — как быть «доступным» для них технически, за счёт скорости.
• Раздел с вопросами и ответами (FAQ) в конце страницы — в понятном, семантически размеченном виде — не только помогает пользователям, но и повышает шанс, что фрагмент вашего ответа процитирует AI-поисковик или голосовой помощник.

Иными словами, техническая оптимизация скорости и оптимизация под AI-поиск — не конкурирующие, а взаимодополняющие задачи: быстрый, чисто вёрстанный сайт со структурированными данными одинаково хорошо работает и для классического SEO, и для новых каналов AI-поиска.

Чек-лист для самопроверки

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

Измерение

• Сняты текущие показатели PageSpeed Insights и Lighthouse отдельно для десктопа и мобильной версии;
• Проверены реальные полевые данные (CrUX) за последние 28 дней, если трафика достаточно;
• Просмотрен встроенный монитор производительности Битрикс на предмет «тяжёлых» компонентов и запросов.

Кэширование

• Включён и корректно настроен композитный режим;
• Проверены критичные сценарии после включения композита (корзина, авторизация, формы, оформление заказа);
• Включено автокэширование там, где это уместно, для стандартных компонентов;
• Настроено тегирование управляемого кэша с точечным сбросом.

Фронтенд

• Включён lazy loading для изображений вне первого экрана;
• Настроены srcset/адаптивные размеры изображений;
• Изображения конвертированы в WebP/AVIF там, где это возможно;
• Включена минификация и объединение CSS/JS;
• Скрипты, не критичные для первой отрисовки, загружаются с async/defer.

Сервер и база данных

• Включён slow query log и проанализирован под реальной нагрузкой;
• Проверено и настроено PHP OPcache;
• Используется актуальная поддерживаемая версия PHP;
• Хостинг соответствует официальным требованиям 1С-Битрикс.

Мобильная версия

• Проверено, что мобильная версия не грузит десктопные по весу ресурсы;
• Отдельно замерены Core Web Vitals для мобильных устройств;
• Проверена стабильность вёрстки (CLS) на мобильных экранах.

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

• Проведена ревизия всех подключённых сторонних скриптов, удалено неиспользуемое;
• Скрипты подключены через менеджер тегов там, где это возможно;
• Тяжёлые виджеты загружаются отложенно, по событию.

Готовность к пикам нагрузки

• Проведено нагрузочное тестирование перед ожидаемым пиком трафика;
• Согласовано временное масштабирование хостинга при необходимости;
• Настроен мониторинг в реальном времени и есть план отката.

Как часто возвращаться к чек-листу

Разовая оптимизация даёт временный эффект. Сайт на 1С-Битрикс — живая система: добавляются новые товары и разделы, устанавливаются новые модули, подключаются новые интеграции и трекеры, растёт база данных. Мы рекомендуем возвращаться к этому чек-листу минимум раз в квартал в плановом режиме, а также внепланово — после каждого крупного обновления платформы, после подключения новой интеграции или стороннего сервиса, и обязательно за 3–4 недели до любого ожидаемого пика нагрузки (сезонная распродажа, крупная рекламная кампания, анонс в СМИ).

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