Почему скорость — это деньги, а не «технический каприз»

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

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

Шаг 1. Сначала измерить, а не угадывать

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

Профилирование Bitrix (модуль «Монитор производительности») — увидеть медленные хиты и тяжёлые компоненты.
Логи медленных SQL-запросов (slow query log) — найти запросы, которые выполняются дольше всего.
Core Web Vitals в Яндекс.Вебмастере и Google Search Console — увидеть скорость глазами поисковика и пользователя.
Реальные сценарии: открыть каталог, применить фильтр, перейти в карточку — там, где ждёт клиент, и нужно мерить.

Шаг 2. Каталог и фильтры — главный источник нагрузки

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

Что обычно помогает: перевод фильтруемых свойств в индексируемый вид, использование Highload-блоков для справочных данных, ограничение количества обращений к базе на одной странице и аккуратная работа с постраничной навигацией.

Шаг 3. Кеширование — самый дешёвый прирост скорости

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

Кеширование компонентов и составных частей каталога с разумным временем жизни.
Управляемый кеш, который сбрасывается при изменении товара, а не по таймеру.
Внешний кеш (например, Redis/Memcached) для разгрузки базы под нагрузкой.
Контроль того, что кеш реально срабатывает, а не пересобирается на каждом хите.

Шаг 4. SQL, инфраструктура и «тяжёлый» PHP

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

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

Что в итоге получает бизнес

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