Скорость сайта на Битрикс: как ускорить и получить больше заявок (гид 2026)

Задача приходит в двух формулировках: «PageSpeed красный, что делать» и «сайт тормозит, менеджеры жалуются». Мы разбираем скорость сайта на Битрикс как SEO и PPC агентство, поэтому смотрим не на балл, а на отказы, конверсию и стоимость обращения.

Рамка ожиданий честная: ускорение почти никогда не даёт скачка позиций, но почти всегда влияет на экономику платного трафика. Статья для маркетолога или владельца e-commerce на 1С-Битрикс, который ставит задачу разработчику и принимает работу. Порядок такой: диагностика, быстрые победы, затем бюджетные работы. Цифры ниже даём как порядок величин, без ссылок на чужие исследования вида «+7% конверсии за 100 мс».

Зачем ускорять сайт на Битрикс: считаем в заявках, а не в баллах

Ускорение окупается через конверсию, а не через позиции. Цепочка потерь простая: долгая загрузка, рост отказов, меньше просмотров каталога, меньше корзин, меньше заявок.

Почему 100 баллов PageSpeed плохая цель

Для магазина с каталогом, фильтром и трекингом последние баллы стоят дорого и пользователю не видны. При ускорении мобильных с 4 до 2 секунд разумно ждать единицы процентов относительного роста конверсии, а не роста в разы.

Когда ускорять не надо

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

Как понять, что скорость тормозит продажи: три проверки за 20 минут

Проверяем поведение, а не баллы. Три шага закрывают вопрос.

1. Метрика: отчёт по времени загрузки, сегменты быстрых и медленных визитов, сравнение отказов и конверсии между ними.
2. Конверсия по устройствам и по шаблонам (главная, категория, карточка, фильтр, корзина). Разрыв мобайл и десктоп больше 1,5-2 раз ставит скорость в подозреваемые.
3. Живой тест: открыть каталог с телефона на 4G и оформить заказ с секундомером, затем посмотреть тяжёлые URL в логах.

Вебвизор отделяет «медленно» от «неудобно». Порог для старта работ: LCP на мобильных выше 4 секунд там, куда идёт платный трафик.

Чем мерить: PageSpeed, «Скорость сайта» в админке Битрикса, монитор производительности

Инструменты мерят разные вещи, поэтому цифры не совпадают. PageSpeed про опыт браузера, админка Битрикса про генерацию страницы на сервере.

Инструмент	Что показывает	Когда нужен
PageSpeed Insights, Lighthouse	Лабораторный прогон плюс полевые данные CrUX	Постоянно, по полевым данным
«Скорость сайта» в админке	Время генерации страницы	Постоянно, серверная часть
Монитор производительности	Тяжёлые компоненты и SQL-запросы	Только диагностика, ненадолго
Метрика, логи сервера	Реальные визиты и обход роботом	Приёмка и мониторинг

Правило приёмки: полевые данные и Метрика за период, а не один прогон из чужого дата-центра по кабелю.

Core Web Vitals в 2026: что учитывают Яндекс и Google, а что нет

Прямого бонуса за баллы нет ни у Google, ни у Яндекса. LCP это время до главного блока, INP это отзыв на нажатие, CLS это скачки вёрстки; оценивают их по 75-му процентилю, не по среднему.

У Google скорость работает как слабый фактор и тайбрейкер: содержание страницы весит сильнее, провал в CWV сам по себе из топа не выбивает. Яндекс сильнее опирается на поведение, и медленный сайт вредит именно через отказы. Отдельно скорость решает в краулинге больших каталогов. Вывод: лечим CWV потому, что это лечит поведение.

Диагностика перед оптимизацией: хостинг, шаблон или кастомный код

Развилка определяется по TTFB. Больше 600-800 мс означает сервер или код, меньше отправляет искать на фронтенде.

1. Сравнить TTFB и время генерации страницы в админке, плюс замер на пустой странице без CMS для проверки хостинга.
2. Тест холодного и горячего кеша: одна страница дважды, разница показывает, работает ли кеширование вообще.
3. Монитор производительности: число SQL-запросов, дубли в цикле, N+1 на свойствах товаров, обращения к внешнему API прямо в шаблоне, инфоблоки без индексов.

Результат оформляем таблицей «узкое место, причина, кто чинит, ожидаемый эффект».

Быстрые победы: прирост за первую неделю без бюджета на разработку

За неделю обычно удаётся заметно улучшить TTFB и LCP на типовых страницах, не трогая код. Маркетолог делает это сам или одним письмом хостеру.

• Включить gzip или brotli и корректные заголовки кеширования статики (обычно сторона хостинга).
• Включить автокеширование компонентов и проверить настройки кеша в «Настройках продукта».
• Отключить неиспользуемые модули и старые счётчики от прошлых подрядчиков.
• Перейти на поддерживаемую ветку PHP.
• Сжать баннеры и картинки-гиганты в слайдерах.

Без разработчика не делаем: композит, объединение и минификацию JS, обновление ядра на бою.

Кеширование в Битриксе по-человечески: теги, автокеш, memcached и Redis

Уровней три: кеш компонентов, управляемый кеш инфоблоков и кеш страниц (композит). Первые два дают основной эффект и почти ничего не ломают.

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

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

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

Классические поломки: CSRF-токены форм, корзина, авторизация, персональные цены, A/B-тесты, кастомные формы подрядчика. Подходит контентным страницам, категориям и типовым карточкам; опасен на B2B-каталогах с индивидуальными ценами и тяжёлых кастомных решениях. Порядок включения: тест на копии, список динамических областей, регресс по формам и оформлению заказа, проверка целей Метрики и конверсий в Директе, только потом бой.

Изображения и медиа: сжатие, WebP, lazy load на шаблонах Битрикса

Начинаем с размеров, а не с формата. Файл должен соответствовать контейнеру, ресайзы делаем через CFile::ResizeImageGet.

• Сжатие без видимых потерь на карточках и баннерах.
• WebP или AVIF отдаём на уровне сервера либо CDN, чтобы не переписывать шаблоны.
• Lazy load не применяем к первому экрану и к LCP-картинке, иначе метрика ухудшится.
• Явные width, height и aspect-ratio против скачков вёрстки.
• YouTube и Яндекс.Карты заменяем на превью с загрузкой по клику, иконочный шрифт на SVG.

Фронтенд: минификация, лишние скрипты трекинга и счётчиков

Начинаем с инвентаризации тегов: Метрика, Директ, Google Ads, коллтрекинг, чат, виджеты отзывов, забытые пиксели. Вклад сторонних скриптов легко оценить прогоном с блокировкой их доменов.

Чат и обратный звонок грузим по взаимодействию или таймеру. Счётчик Метрики и код Директа трогаем осторожно: сломанные конверсии дороже сэкономленных 200 мс. Встроенные объединение и минификация в Битриксе работают, но конфликтуют с кастомным JS, поэтому только после теста на копии. Шрифты: font-display, локальное размещение, минимум начертаний. Критический CSS оставляем на финал, он часто съедает бюджет без видимого эффекта.

Серверная часть: BitrixEnv, PHP, настройки MySQL, CDN

BitrixEnv удобен предсказуемой конфигурацией, но не обязателен: важны версии, лимиты и настройки, а не бренд окружения. Частая причина плохого TTFB это shared-хостинг с лимитами CPU и общим MySQL.

Обязательный минимум: актуальная ветка PHP с OPcache и realpath_cache, адекватные лимиты памяти, буферный пул InnoDB под размер базы, slow log и индексы на кастомных таблицах, HTTP/2 или HTTP/3 с keep-alive и корректным TLS. CDN при трафике только из России нужен точечно (тяжёлые медиа, отдача WebP), при близком сервере прирост минимален. Решение о переезде принимаем по тесту копии с реальным дампом.

Большой каталог: фасетные индексы, фильтры и краулинговый бюджет

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

Что делаем: включаем и перестраиваем фасетный индекс, ограничиваем число фильтруемых свойств, убираем «показать все» и огромные листинги, кешируем страницы фильтра со сбросом по тегам при смене цен. Вторая часть проблемы это обход: медленные ответы означают меньше URL за сессию робота, новые товары индексируются дольше. Мусорные URL фильтра закрываем robots.txt и канониклами, а контроль ведём по логам (URL в день и среднее время ответа).

Мобильная скорость отдельно: где теряется основной трафик

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

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

Скорость и платный трафик: как ускорение влияет на стоимость обращения

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

Реальная экономика считается так: заявки равны клики умножить на конверсию, стоимость обращения равна бюджет разделить на заявки. При том же бюджете рост конверсии на 10% снижает CPL примерно на 9%, при росте на 15% примерно на 13%. Поэтому после работ мерим CPL и отказы по платному трафику, а не позиции и баллы.

Что делать, если проблема в готовом решении с маркетплейса

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

Вариантов три. Чинить: отключить неиспользуемые блоки, сделать облегчённый шаблон каталога, аккуратные переопределения. Менять: когда смета доработок перевешивает стоимость нового шаблона или своей вёрстки. Терпеть: трафика мало, деньги нужнее в рекламе. Критерий выбора один, сравнить смету с ожидаемым приростом заявок за 6-12 месяцев.

Как поставить задачу разработчику: техзадание и критерии приёмки

В ТЗ входят страницы-эталоны, текущие и целевые метрики, среда тестирования и запреты (не ломать формы, счётчики, вёрстку). Метрики приёмки: время генерации в Битриксе, TTFB, LCP и INP на мобильных по полевым данным, число SQL-запросов на странице.

1. Замер: минимум 5 прогонов на каждой из 5 типовых страниц плюс полевые данные за 28 дней. Один тест не принимается.
2. Регресс: все формы, корзина, оплата, авторизация, цели Метрики, конверсии Ads.
3. Договор: этапы, откат, доступ к копии, отчёт до и после в одном формате.

Признаки переплаты: работы без привязки к найденному узкому месту, «оптимизация ядра», гонка за 100 баллами, минификация вместо кеша.

Мониторинг после оптимизации: чтобы не откатиться через два месяца

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

Минимум инструментов: отчёт по скорости в Метрике, полевые CWV, монитор TTFB и аптайма, алерт на рост времени генерации. Раз в месяц проверяем те же 5 страниц той же методикой. Правило для маркетинга: любой новый скрипт или баннер проходит проверку веса перед выкладкой, проверка скорости стоит в чек-листе приёмки доработок. При откате сравниваем с базовым замером и ищем изменение, а не оптимизируем заново.

Типовые сценарии: где ускорение окупилось, а где нет

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

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

Чек-лист: порядок работ по приоритету влияния на заявки

Этап 0, замер базы: 5 типовых страниц, Метрика, полевые CWV, TTFB. Без базы приёмка невозможна.

• Этап 1 (неделя, без бюджета): сжатие и кеш статики, автокеш компонентов, актуальный PHP, чистка счётчиков, сжатие тяжёлых картинок.
• Этап 2 (небольшой бюджет): тегированный кеш, Redis или memcached, фасетный индекс, WebP, lazy load вне первого экрана, отложенные виджеты.
• Этап 3 (серьёзные работы): переезд окружения, рефакторинг шаблонов, композит, критический CSS, CDN для медиа.

Сначала страницы с платным трафиком и корзина. Косметические пункты PageSpeed без влияния на пользователя откладываем сознательно.

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

Насколько вырастет конверсия при ускорении с 4 секунд до 2?

Единого коэффициента нет. На мобильном e-commerce относительный рост обычно измеряется единицами процентов, реже превышает 10-15% (ориентир по нашим проектам, не норматив), и только если скорость была реальным барьером. Потенциал считайте так: доля мобильного трафика умножить на разрыв в отказах между быстрыми и медленными визитами в Метрике.

Почему «Скорость сайта» в админке зелёная, а PageSpeed показывает 30 баллов?

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

Влияет ли скорость на позиции в Яндексе в 2026 году?

Влияет косвенно. Бонуса за баллы нет, скорость работает как слабый фактор и тайбрейкер. Основной канал это поведение: медленный сайт получает больше отказов. Второй канал это объём обхода. Ускоряться ради позиций плохая мотивация, ради заявок хорошая.

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

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

Что раньше при ограниченном бюджете: менять хостинг или чинить код?

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

Можно ли ускорить сайт без программиста?

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

Почему после включения композита сломались формы и корзина?

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

Обязательно ли переезжать на BitrixEnv?

Не обязательно. Тот же результат даёт грамотно настроенный VPS: актуальный PHP с OPcache, MySQL с адекватным буферным пулом, Redis или memcached, HTTP/2. Проблема обычно не в отсутствии BitrixEnv, а в shared-хостинге с лимитами CPU. Критерий один, тест копии на новом окружении.

Снизит ли ускорение стоимость клика в Яндекс.Директе?

Практически нет: цену клика определяет аукцион. В Google Ads связь ближе, опыт на целевой странице входит в показатель качества. Главный эффект другой: из того же числа визитов приходит больше заявок, то есть падает стоимость обращения. Мерить нужно CPL, а не CPC.

Как проверить, что подрядчик реально ускорил сайт?

Зафиксируйте методику до работ: 5 типовых страниц, минимум 5 прогонов, одно место замера, полевые Core Web Vitals за 28 дней, отчёт по скорости в Метрике, время генерации и число SQL-запросов. Один зелёный прогон Lighthouse на главной приёмкой не считается.

Почему магазин тормозит только на страницах с фильтром?

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

Стоит ли уходить с Битрикса, если сайт неисправимо медленный?

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

Сколько живёт результат оптимизации?

Без регламента 2-4 месяца. Откат дают несжатые баннеры, новые виджеты и скрипты, рост каталога, обновления модулей, потерянные настройки кеша. Решение: базовый замер, ежемесячная проверка тех же 5 страниц, алерт на рост времени генерации и проверка веса любого нового скрипта перед выкладкой.

Как скорость влияет на индексацию большого каталога?

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

Нужен ли CDN сайту с трафиком только из России?

Обычно не в первую очередь. При сервере близко к аудитории выигрыш на HTML минимален, а точек отказа становится больше. CDN оправдан точечно: тяжёлые изображения и видео, большой объём статики, отдача WebP на лету, сезонные всплески. Высокий TTFB из-за кода он не вылечит.

Нужна диагностика скорости с оценкой в заявках

Что сделать на этой неделе

1. Снять базу: 5 типовых страниц, TTFB, полевые CWV, отчёт по скорости в Метрике.
2. Сравнить отказы и конверсию в сегментах быстрых и медленных визитов.
3. Попросить хостера включить сжатие и заголовки кеширования статики.
4. Включить автокеш компонентов и убрать лишние счётчики.
5. Сжать тяжёлые картинки на главной и в категориях.

Мы делаем аудит скорости с приоритизацией работ по влиянию на заявки и стоимость обращения: список узких мест, кто их чинит (хостер, разработчик, SEO-специалист), смета и ожидаемый эффект. Если ускорение не окупится, скажем прямо и предложим, куда направить бюджет. Работаем с 2012 года с e-commerce на 1С-Битрикс, медициной, B2B и промышленностью. Оставьте заявку на бесплатный экспресс-аудит сайта или рекламы в КлиентЛаб: https://klientlab.ru.

Материалы по теме

• SEO для сайтов на 1С-Битрикс
• Кейс: каталог на 33 915 товаров
• SEO-аудит интернет-магазина
• Sitemap.xml и robots.txt на Битриксе: настройка без копипасты шаблонов
• Настройка SEO на Битриксе: пошаговый порядок работ от агентства (2026)