Вот это мой любимый жанр трагедии.
Вы долго настраивали рекламу, спорили с маркетологами, согласовывали креативы, заложили бюджет…
Старт кампании. Трафик пошёл.
И в этот момент:
- сайт открывается по 10 секунд,
- корзина падает с ошибкой,
- оформление заказа крутит «подождите» до посинения,
- телефоны менеджеров разрываются, но не от заявок, а от фразы «у вас сайт не работает».
Деньги летят в окно, конкуренты спокойно собирают ваших же людей у себя.
Сейчас покажу, почему Битрикс-проект ложится под рекламой и что нужно сделать ЗАРАНЕЕ, чтобы запуск трафика не превращался в аттракцион «упал — отжался» для сервера.
1. Симптомы: ваш сайт уже шепчет, что он не готов
Если у вас было хоть что-то из этого — это не «случайность», это сигнал:
- Сайт начинает жутко тормозить в дни акций, распродаж, перед праздниками.
- В аналитике всплеск ошибок, обрывов сессий, странных «недооформленных» заказов.
- Менеджеры слышат от клиентов:
«Я пытался сделать заказ, но всё висело / выдавало ошибку». - Админ панически перезагружает сервер в самый пик.
Это не платформа плохая. Это вы:
- накачали трафика,
- не накачав инфраструктуру и код под этот трафик.
2. Главные убийцы сайта под нагрузкой
Когда магазин на 1С-Битрикс живёт на тарифе уровня «для блога и визитки» — дальше можно не продолжать.
Типовые приколы:
- shared-хостинг, где вы делите ресурсы с ещё сотней таких же сайтов;
- слабый VPS, который упирается в CPU/оперативку ещё до старта кампании;
- один сервер, на котором и сайт, и база, и крон-скрипты, и ещё бог знает что.
В часы пик сервер просто физически не тянет.
И никакие «попробуйте обновить страницу» здесь не спасают.
2.2. Нет кэша. Совсем. Каждому пользователю — свежесваренный ад
Битрикс умеет кэшировать.
Но многие живут так, будто кеш — это что-то страшное:
- сложные разделы каталога каждый раз строятся с нуля;
- меню, хиты продаж, баннеры — всё тянется «живьём»;
- у компонентов либо отключён кеш, либо стоит 60 секунд «на всякий случай».
В обычные дни это просто «ну медленно, да».
Под рекламой — это катастрофа: каждый новый посетитель бьёт по базе и по серверу как кувалдой.
2.3. Тяжёлые страницы: 100 запросов к базе и тонна фронта
Любимая картина:
- каталог — монстр из компонентов, каждый со своими запросами;
- сложные фильтры, которые гонят SELECT’ы без индексов;
- карточка товара с кучей персональных рекомендаций «на лету»;
- мегаскрипты аналитики, чатов, виджетов, трекингов.
Сервер в этот момент тихо плачет в углу, особенно если всё это выполняется для каждого гостя отдельно.
2.4. Синхронные внешние вызовы: CRM и сторонние сервисы вешают оформление
Классика:
- при отправке формы сайт ждёт ответа от CRM/почтового сервиса/коллтрекинга;
- если сервис тормозит — сайт висит вместе с ним;
- если сервис недоступен — клиент видит ошибку, вместо «заявка принята, мы с вами».
Под большой трафик такая схема — суицид.
Любой внешний лаг размножается на сотни посетителей.
3. Что нужно сделать ДО запуска рекламы
3.1. Аудит производительности: где именно у вас узкие горлышки
Я никогда не начинаю с «давайте купим сервер побольше».
Сначала я отвечаю на вопросы:
- какие страницы самые тяжёлые (главная, каталог, карточка товара, корзина, оформление заказа);
- сколько запросов к базе выполняется на них;
- что жрёт время: PHP, база, внешние API, файлы.
Использую:
- встроенный профайлер Битрикс (страница, компоненты, запросы);
- реальное тестирование под несколько пользователей одновременно;
- замеры TTFB, времени генерации страниц, логов БД.
После этого уже понятно:
где надо резать жир, а где действительно добавить железа.
3.2. Включить и настроить кэш по-взрослому
Цель простая:
чтобы 80–90% обращений отдавались из кэша, а не собирались с нуля.
Что я делаю:
- включаю кеш у компонентов, где данные не меняются каждую секунду;
- выношу тяжёлые блоки (меню, популярные товары, акции) в хорошо кешируемый слой;
- настраиваю грамотную очистку: не «чистим всё при каждом сохранении», а точечно — по событию.
И да, иногда проще пересмотреть логику страницы, чем бесконечно лечить её таблетками.
3.3. Оптимизация базы: индексы, запросы, «грязь»
Если у вас:
- таблицы на сотни тысяч строк;
- запросы без индексов по полям фильтрации;
- истории логов и сессий копятся годами — база уже сама по себе тормоз.
Я:
- смотрю топ самых тяжёлых запросов;
- добавляю индексы по тем полям, по которым фильтруемся чаще всего;
- чищу старый мусор — логи, кэши, ненужные временные таблицы.
Иногда одно-два исправленных запроса делают больше, чем увеличение сервера в два раза.
3.4. Разнести нагрузку: веб, база, фоновые задачи
Для проектов, которые реально ждут серьёзный трафик, нормальная практика:
- веб-сервер отдельно, база отдельно;
- фоновые операции (рассылки, выгрузки, импорты, обсчёт скидок) — на крон и в очередь, а не при каждом заходе пользователя.
Критичную вещь важно понять:
оформление заказа не должно ждать, пока вы там что-то пересчитали, записали в 1С, отправили 10 писем и 3 вебхука.
Пользователь должен:
- за 1–2 секунды увидеть, что заказ принят;
- всё остальное можно докрутить асинхронно, без его участия.
3.5. Проверка под нагрузкой: не на реальных людях
Очень странная экономия — тестировать сайт на рекламном трафике.
Я предпочитаю другой вариант:
- поднимаю стенд, максимально похожий на прод;
- прогоняю скрипт, который имитирует одновременные визиты: просмотр каталога, карточек, оформление заказов;
- смотрю, где сайт начинает задыхаться: при 50, 100, 200 посетителях в минуту.
После этого можно уже честно говорить:
«При такой конфигурации мы спокойно выдержим вот такой трафик, дальше — надо усиливать».
4. Подготовка прямо перед запуском кампании
Вот что должно быть сделано к моменту старта рекламы.
4.1. Железо и окружение
- проверены и при необходимости подняты ресурсы по CPU, RAM, диску;
- настроены лимиты PHP (память, время выполнения), чтобы не отстреливать себя по таймаутам;
- кеш и опкеш настроены и прогреты.
4.2. Логи и мониторинг
Запускаем не в слепую:
- мониторинг доступности сайта (пинг, HTTP-код, время ответа);
- отслеживание ошибок (PHP-ошибки, 500-ки, падения БД);
- контроль количества заказов/форм в час — чтобы сразу увидеть провал.
Если в аналитике видим, что:
- трафик идёт,
- а количество заказов внезапно падает до нуля,
— это повод не через неделю вспоминать, а прямо сейчас идти смотреть, что там умерло.
4.3. План действий «если всё-таки что-то легло»
Да, даже при идеальной подготовке любой проект может словить сюрприз.
Важный вопрос: у вас есть план или вы будете бегать по кругу и кричать «кто трогал сервер?!».
Минимум:
- список контактов (кто отвечает за сайт, за хостинг, за рекламу);
- кто принимает решение: останавливаем рекламу или режем часть функционала (например, отключаем тяжёлые разделы/виджеты);
- готовые действия «первой помощи»: рестарт сервисов, откат последних правок, переключение на упрощённый режим.
Когда это проговорено заранее, вы меньше похожи на пожарных без воды.
5. Итог: реклама должна убивать только ваши сомнения, а не сайт
Запуск трафика — это нагрузочный тест, за который вы ещё и платите.
Можно продолжать играть в «авось выдержит» и списывать провалы кампаний на «плохой трафик».
А можно один раз подготовить Битрикс-проект к нормальным нагрузкам:
- вычистить тяжёлые места в коде и базе;
- включить человеческий кеш;
- настроить окружение;
- протестировать всё до старта;
- поставить мониторинг и план на случай ЧП.
И тогда в день запуска рекламы вы будете смотреть не на 500-е ошибки и падающую корзину, а на нормальную статистику: трафик → заявки → деньги.