Сайт на 1С Битрикс тормозит: откуда секунды и куда они деваются

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

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

Наивные действия узнаваемы: купить тариф мощнее, поставить очередной плагин кеша «на всё», сжать картинки один раз и забыть. Иногда помогает ненадолго. Без диагностики вы ускоряете не то узкое место — или ускоряете тестовый контур, глядя не на те URL.

Откуда обычно берутся секунды

Сценарий тяжёлого TTFB. Сервер долго думает до первого байта: неоптимальные запросы, холодный кеш, внешние API в синхронном запросе страницы, перегруженная админка на том же контуре.

Сценарий «красивой витрины». Огромные слайдеры, шрифты, скрипты сторонней аналитики и виджетов. Страница «оживает» долго уже после ответа сервера.

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

Грабли ускорения Битрикса

• Включать агрессивный кеш без понимания, какие блоки персонализированы.
• Лечить только картинки, игнорируя базу и серверную логику.
• Держать тестовые и отладочные режимы на проде.
• Не разделять тяжёлые фоновые задачи и отдачу страниц.
• Мерить скорость с офисного канала на прогретом кеше и считать, что «у клиентов так же».

Порядок ускорения, который работает

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

Нужно снять профиль, определить, какие URL критичны для бизнеса, узнать TTFB и этапы (сервер, сеть, отрисовка), а также отдельно рассмотреть мобильный профиль.

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

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

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

Проверить инфраструктуру. PHP-FPM, БД, диск, TLS, географию аудитории. Иногда нужен не «ещё один модуль», а нормальный контур и сопровождение.

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

Что сделать за первые дни

1. Выбрать 5 ключевых страниц воронки и зафиксировать текущие цифры.
2. Найти, где теряется время: до первого байта или после.
3. Убрать очевидный мусор: отладка, лишние агенты, тяжёлые виджеты на первом экране.
4. Включить/починить кеш там, где он безопасен.
5. Повторить замер с мобильного профиля и сравнить заявки/отказы через короткий период.

Какой эффект считать успехом

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

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

Если сайт уже «медленный», начните с измерений на боевых URL, а не с покупки нового тарифа вслепую. Мощность без диагностики — самый дорогой способ не узнать причину.

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

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

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

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