Фраза «у нас Битрикс, поэтому он тормозит» звучит так часто, что я уже перестал улыбаться.
Нет, не потому что обидно за платформу.
А потому что под этой мантрой очень удобно ничего не делать:
- каталог открывается по 5 секунд — «ну это же Битрикс»
- оформление заказа висит — «да, платформа тяжёлая»
- админка лагает — «так у всех»
Спойлер: нет, не у всех.
И девяносто процентов «тормозящего Битрикса» — это не карма, а очень конкретные косяки в коде, настройках и инфраструктуре.
Сейчас покажу, как я раскладываю эту боль по полочкам и нахожу, где именно вы убиваете скорость.
Начинаем не с сервера, а с вопроса: что именно тормозит?
Самая большая глупость — услышать «всё тормозит» и сразу бежать апгрейдить железо.
Нормальный старт такой:
- тормозит для кого: для пользователей или в админке?
- тормозит где: главная, каталог, карточки, корзина, личный кабинет, оформление заказа?
- тормозит когда: всегда или под нагрузкой (реклама, пик, обмен 1С)?
Без этого вы просто будете кидаться деньгами в проблему наугад.
Я всегда сначала иду смотреть глазами человека:
- открываю ключевые страницы как обычный пользователь;
- замеряю, что дольше всего думает:
- до первого отклика (страница вообще шевельнулась),
- до полной загрузки;
- параллельно смотрю время генерации страницы на сервере.
Очень часто оказывается, что сервер не виноват:
утонул не железо, а один кривой компонент на странице.
«Битрикс тяжёлый» — а кеш вообще включён?
Вот тут начинается цирк.
Я захожу в проект и вижу:
- у половины компонентов кеш выключен «на время разработки»… два года назад;
- меню, хиты, баннеры, сложные выборки — всё считается на лету при каждом заходе;
- формы и фильтры каждый раз лезут в базу, как будто вы прям сейчас переписываете каталог.
В обычный день это просто «нудно грузится».
Под рекламой это превращается в падение сайта.
Битрикс умеет кешировать вообще всё, что не меняется каждую секунду.
Но им почему-то часто не пользуются.
Что я делаю:
- включаю кеш там, где он обязан быть: меню, списки, повторяющиеся блоки, сложные выборки;
- настраиваю адекватное время жизни кеша, а не 60 секунд «на всякий случай»;
- выстраиваю нормальный механизм сброса кеша:
- изменился товар → обновили только его;
- изменился раздел → почистили только связанное.
После этого сайт внезапно перестаёт думать полжизни над каждым запросом.
Каталог и фильтр: главный пожиратель ресурсов
Если у вас интернет-магазин, то 80% боли обычно сидит в трёх местах:
- раздел каталога,
- умный фильтр,
- сортировки.
Типичные сюрпризы:
- фильтр дергает по 20–50 запросов к базе на один клик;
- нет индексов по полям, по которым вы фильтруете;
- каждая сортировка — отдельный тяжёлый запрос без оптимизации;
- в выборку тащится больше полей, чем нужно (под каждый элемент — километр данных).
«Битрикс тормозит» здесь выглядит как вы качаете базу, как прессом, и она честно стонет.
Я делаю так:
- включаю профайлер и смотрю, какие конкретно запросы живут дольше всех;
- добавляю индексы по реальным полям фильтрации/сортировки, а не «по идее»;
- оптимизирую компоненты каталога, чтобы они не тащили всё подряд;
- в особо запущенных случаях — перестраиваю схему каталога и фильтра.
Очень часто одна-две правки в каталоге дают больше эффекта, чем перенос на «сервер подороже».
Фронт — не мусорка: скрипты, стили, картинки
Больно признавать, но многим проектам не нужен никакой «оптимизированный Битрикс», им нужен не мусорный фронт.
Симптомы:
- на каждый чих грузится отдельная библиотека JS;
- пять разных виджетов онлайн-чата, половина отключена, но скрипты всё равно тянутся;
- картинки весом по 2–4 МБ «чтобы было красиво на ретине»;
- блоки, которые вообще не нужны пользователю на первом экране, грузятся первыми.
В таких проектах TTFB (ответ сервера) может быть нормальным, а пользовательский опыт — всё равно «как в болоте».
Что я делаю:
- сжимаю и нормализую картинки (вплоть до WebP, если уместно);
- включаю ленивую загрузку для всего, что ниже первого экрана;
- вычищаю мёртвые и дублирующие скрипты;
- разбираю, что реально нужно тянуть сразу, а что можно подгружать потом.
Битрикс тут ни при чём.
Если вы повесили на машину десять прицепов — дело не в марке автомобиля.
Админка тормозит? Скорее всего, её превратили в свалку
Отдельная песня — «у нас админка в Битрикс жутко тормозит».
Ну да, если:
- в одном инфоблоке десять тысяч элементов, с сотней свойств каждый;
- в списке админки выводятся все сто свойств, плюс ещё пара вычисляемых;
- нет фильтров, всё открывается одним списком;
- контентщики работают под логином с правами «бог», им видны все возможные сущности.
Тут не Битрикс падает, тут вы просто тащите через админку всё, что только можно, без нормальной настройки.
Как я лечу:
- настраиваю отдельные представления списка для разных задач (минимум колонок, максимум фильтров);
- разбиваю инфоблоки, если там реально свалка всего подряд;
- настраиваю права доступа, чтобы людям не загружать адскую кучу полей, которые им не нужны.
Контентщик не должен работать в режиме «открыть список и пойти налить чай, пока прогрузится».
Окружение и сервер: да, иногда проблема в железе
Бывает и так:
код и настройки более-менее, а инфраструктура — слёзы.
Типовые истории:
- проект живёт на виртуальном хостинге для визиток;
- старый PHP, старая база, никакого opcache;
- на том же сервере живёт ещё десяток тяжёлых проектов;
- нет никакого мониторинга, пока всё не упало — никто не чешется.
В этом случае без апгрейда не обойтись.
Но!
Я никогда не начинаю с покупки «большого сервера».
Сначала вычищаю всё, что тормозит в коде и БД, а потом уже считаю:
- сколько реально нужно CPU/памяти;
- есть ли смысл разнести веб и базу;
- нужен ли балансировщик, если вы растёте по нагрузке.
И только после этого можно честно сказать:
«Да, тут уже вопрос не в настройках, а в том, что бизнес вырос, нужен более серьёзный хостинг».
Что я делаю, когда мне говорят: «Битрикс тормозит, сделайте что-нибудь»
Мой алгоритм простой и злой:
- Собираю конкретику.
Какие страницы, какие сценарии, в какое время, с каких устройств. - Включаю профайлер.
Смотрю, где горят запросы, компоненты, события. - Рублю три самых жирных места.
Каталог, фильтр, корзина/оформление — в 80% случаев этого достаточно, чтобы сайт «поехал». - Чищу фронт.
Скрипты, стили, картинки, лишние виджеты. - Уже потом трогаю сервер.
Только когда видно, что сам по себе он не вывезет даже после оптимизации.
После этого разговора «Битрикс — тормозная CMS» как-то быстро сдувается.
Остаётся другая, более честная формулировка:
«Мы годами долбили в прод всё подряд без головы,
не настраивали кеш, не смотрели в профайлер,
экономили на хостинге и теперь удивляемся, что оно дышит на ладан».
Если у вас сайт на Битрикс еле шевелится — это не повод перепрыгивать на «лёгкую модную CMS».
Чаще это повод навести порядок в том, что уже есть: в коде, базе, кешах и окружении.
И да, почти всегда оказывается, что «Битрикс тормозит» — это удобная сказка.
Реальность куда прозаичнее: кто-то когда-то хотел сделать побыстрее и подешевле, а теперь вы платите за этот ускоренный подход скоростью каждого клика пользователей.