Сайт на 1С-Битрикс начал тормозить, хотя вы ничего не меняли? В 90% случаев виноваты три вещи

30 июня 2026 · 9 мин чтения

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

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

Сначала плохая новость: вы теряли деньги ещё до того, как заметили

Прежде чем про причины — про то, почему это вообще стоит того, чтобы читать дальше.

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

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

Запомните этот тезис — он ключевой. Тормоза не возникают за одну ночь. Они накапливаются. А раз накапливаются — значит, их можно было увидеть заранее. Но об этом в конце.

Причина №1. База данных распухла

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

Ровно это происходит с базой данных Битрикса. Со временем она обрастает балластом: сессии давно ушедших посетителей, брошенные корзины, статистика за все годы, журналы, временные данные. Таблицы пухнут, и запросы, которые раньше отрабатывали мгновенно, начинают ползти. Сайт делает ту же работу, что и всегда, — просто каждый раз перелопачивает гору лишнего.

Как это выглядит со стороны: тормозит и сама витрина, и админка. Особенно заметно на списках, фильтрах, каталоге — там, где система роется в базе.

Что с этим делают: чистят и оптимизируют таблицы, настраивают регулярную автоматическую очистку старых данных, проверяют индексы. Это рутинная гигиена, которую большинство сайтов не делает годами.

Причина №2. Кэш не работает так, как должен

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

Беда в том, что кэш часто либо настроен плохо, либо постоянно обнуляется. Самая классическая ловушка у интернет-магазинов — частый полный обмен товарами с 1С. Каждая полная выгрузка сбрасывает кэш всего каталога, и сайт вынужден собирать страницы с нуля снова и снова, как будто кэша и нет вовсе. Получается, что инструмент ускорения есть, но он простаивает.

Как это выглядит: каталог и карточки товаров «думают», а нагрузка на сервер скачет именно в моменты обмена с 1С.

Что с этим делают: включают и правильно настраивают типовое и композитное кэширование, а логику обмена с 1С перестраивают так, чтобы она не сбрасывала весь кэш по любому поводу.

Причина №3. Встали агенты и cron — самая коварная

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

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

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

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

Что с этим делают: настраивают и проверяют режим cron, следят, чтобы агенты выполнялись по расписанию, а не дёргали живых посетителей.

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

Как проверить себя самому за десять минут

Хорошая новость: Битрикс умеет диагностировать себя сам, и для этого не нужен программист.

Зайдите в админке в раздел Настройки → Производительность (в разных редакциях он называется «Панель производительности» или «Управление производительностью»). Там есть монитор, который прогоняет вашу конфигурацию и выставляет ей балл. Грубый ориентир — около 30; чем выше число, тем лучше настроена система. Если у вас сильно меньше — это уже сигнал.

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

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

Почему разовый аудит — это лечение симптома, а не болезни

Допустим, вы всё это нашли (или наняли человека, который нашёл) и починили. Сайт снова летает. Победа?

На пару месяцев — да. А потом происходит вот что. База снова постепенно распухает — посетители ходят, корзины бросаются, статистика копится. Кто-то ставит новый модуль, который тянет лишнее. После очередного обновления снова отваливается cron. И в один прекрасный день — снова тот же звонок: «сайт тормозит, хотя мы ничего не меняли».

В этом и есть ловушка разовой оптимизации. Все три причины — накопительные по своей природе. Аудит за один-два дня делает снимок состояния на сегодня и приводит его в порядок. Но он не сторожит ваш сайт завтра. Это как сходить к стоматологу, вылечить зуб — и считать, что чистить зубы больше не нужно. Через полгода вы вернётесь с той же проблемой.

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

Что реально помогает: видеть дым, а не тушить пожар

Решение не в том, чтобы чинить быстрее. Оно в том, чтобы узнавать о проблеме раньше — когда показатели только поползли, а клиент ещё ничего не заметил.

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

Именно для этого мы и сделали Pingvera. Сервис ставит лёгкий коннектор внутрь вашего Битрикса и держит руку на пульсе ровно тех трёх вещей, о которых вся эта статья: снимает баллы встроенного монитора производительности (perfmon) — включая реальную скорость базы данных; проверяет состояние кэша — тип хранилища (файлы или быстрый Memcached/Redis), включён ли композитный сайт и управляемый кэш; следит за режимом запуска агентов и cron и ловит просроченные агенты (те самые «вставшие» фоновые задачи). Плюс прогоняет штатную «Проверку системы» Битрикса. Параллельно — внешние пробы: замеряют реальное время отклика сайта из нескольких регионов России и из-за рубежа (заодно ловят ситуацию, когда сайт лёг для части страны, а у вас открывается). Как только что-то уходит от нормы — perfmon просел, кэш настроен не оптимально, агенты встали, время отклика поползло вверх, — вы получаете уведомление в Telegram или на почту, до того как сайт начнёт тормозить при клиентах. Плюс сервис следит за сроком домена и SSL, чтобы сайт однажды не исчез из-за нелепо забытой оплаты.

Смысл простой: перестать узнавать о проблемах из звонка разъярённого клиента и начать узнавать о них из спокойного уведомления — заранее.

Коротко, если лень читать всё

Если сайт на 1С-Битрикс начал тормозить «сам по себе», не паникуйте про взлом и не бегите менять хостинг. В девяти случаях из десяти виноваты три вещи:

• Распухшая база данных — лечится чисткой и оптимизацией таблиц.
• Неработающий кэш — настраивается типовое и композитное кэширование, особенно если у вас частый обмен с 1С.
• Вставший cron и агенты — настраивается расписание фоновых задач.

Проверить себя можно бесплатно за десять минут во встроенном мониторе производительности (Настройки → Производительность). А чтобы это не превратилось в бесконечный круг «починили — через полгода снова тормозит», за этими тремя точками имеет смысл следить постоянно, а не раз в аварию. Потому что тормоза — это всегда сигнал, что система уже работает на пределе. И лучше услышать этот сигнал раньше своего клиента.

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

Почему сайт на 1С-Битрикс тормозит, если я ничего не менял?

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

Как проверить производительность Битрикса самому?

Зайдите в админке в раздел Настройки → Производительность (Панель производительности). Встроенный монитор прогонит конфигурацию и выставит балл — грубый ориентир около 30, чем выше, тем лучше. В рекомендациях не должно быть «красных» пунктов, а во вкладке для разработки видны самые тяжёлые страницы. Менять тонкие настройки сервера БД самостоятельно не стоит — смотреть диагностику можно и нужно, а крутить значения лучше со специалистом.

Сколько стоит мониторинг Битрикса в Pingvera?

Начать можно бесплатно: бесплатный тариф покрывает до 5 сайтов с проверками от 1 минуты — этого хватает, чтобы следить за доступностью, сроком домена и SSL. Платные тарифы добавляют частые проверки и CMS-диагностику изнутри (perfmon, состояние кэша, агенты и cron Битрикса) через лёгкий коннектор.

Читайте также: Сайт клиента упал: как узнать об этом раньше клиента.