Как ускорить сайт на 1С-Битрикс за 1 день?

Семь действий, которые дают 80% результата: включить композитный кэш на главной и каталоге, настроить OPcache с opcache.memory_consumption=512+, переключить кэш Битрикса на Redis, перевести базу на NVMe, добавить индексы в HL-блоки, отключить неиспользуемые модули, поставить Cloudflare на статику. По нашему кейсу — ускорение с 4.2 до 0.9 секунды.

Что лучше для Битрикса — Redis или Memcached?

Redis. Он умеет персистентность (кэш не теряется при рестарте), поддерживает структурированные данные, кластеризуется, имеет лучший мониторинг. Memcached проще в установке, но менее гибкий. Для проектов от 10 000 хитов в сутки разница в производительности минимальна, в эксплуатации Redis удобнее.

Нужен ли NVMe для Битрикса в 2026?

Да, обязательно для базы данных. На HDD один JOIN по миллионной таблице товаров занимает 200–500 мс, на NVMe — 5–15 мс. Разница в 30 раз. Современные тарифы хостингов (Beget, Reg.ru, Timeweb, Yandex Cloud) предлагают NVMe за дополнительные 200–500 ₽/мес — это самое дешёвое ускорение, которое можно купить.

Что такое композитный кэш в Битриксе и стоит ли его включать?

Композит — технология Битрикса, отдающая статичную часть страницы из Nginx за 30–80 мс, а динамические блоки догружающая асинхронно. Включение композита на главной и листингах даёт TTFB менее 200 мс независимо от нагрузки на PHP. Стоит включать всегда, кроме страниц, где весь контент персонализирован (личный кабинет, корзина).

Поможет ли смена хостинга, если сайт тормозит?

Поможет, если сейчас вы на виртуальном хостинге или сервере без NVMe. Смена на VPS с 4+ ГБ RAM, NVMe и активным OPcache+Redis даёт ускорение в 2–5 раз без переписывания кода. Не поможет, если проблема в коде сайта (неоптимальные запросы, отсутствие индексов, тяжёлый фронтенд) — тут нужна оптимизация на уровне приложения.

Сайт на Битриксе тормозит: чек-лист ускорения за 1 день

Q: Почему тормозит сайт на Битриксе?

В 80% случаев причины: выключенный композитный кэш, отсутствие OPcache в PHP, кэш на диске вместо Redis/Memcached, HDD вместо NVMe под базой данных, неоптимальные запросы через старое API CIBlockElement::GetList, отсутствие индексов в HL-блоках, включённые неиспользуемые модули. Диагностируется через Монитор производительности Битрикса и slow_log MySQL за 15 минут.

Прямой ответ: если сайт на 1С-Битрикс тормозит, в 80% случаев виноваты пять вещей — выключенный композитный кэш, отсутствие OPcache, использование HDD вместо NVMe, неоптимальные запросы через старое API CIBlockElement::GetList и HDD под базой данных. Ниже — как за один рабочий день диагностировать и исправить, и реальный кейс с 4.2 секунд до 0.9 секунд.

Как за 15 минут понять, где тормозит

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

Монитор производительности Битрикса (Настройки → Производительность → Панель производительности). Запускает синтетический тест, показывает время выполнения PHP, БД, файловой системы. Если общая оценка ниже 30 — проблема в конфигурации сервера, а не в коде.
Композитный сайт (Настройки → Композитный сайт) на главной — должен быть в статусе «Работает» с TTFB < 200 мс. Если выключен или TTFB больше секунды — первая точка работы.
PageSpeed Insights и Core Web Vitals — смотрим LCP, INP, CLS на мобильном. LCP > 2.5 сек — проблема загрузки. INP > 200 мс — проблема интерактивности (тяжёлый JS).
slow_log MySQL — включаем порог 0.5 секунды, получаем список самых тяжёлых запросов. Чаще всего — несколько SELECT без индексов на HL-блоках.
Хит-карта Битрикса (Производительность → Анализ хитов) — показывает, на какие страницы тратится больше всего времени. Часто 80% нагрузки идёт на 5–10 страниц — их и оптимизируем в первую очередь.

Топ-7 причин, почему тормозит Битрикс

1. Не включён композитный кэш

Композит — это технология Битрикса, которая отдаёт статичную часть страницы из Nginx за 30–80 мс, а динамические блоки догружает асинхронно. На правильно настроенном композите TTFB не превышает 100–150 мс независимо от того, что в PHP. Включение композита на главной и листингах каталога даёт ускорение в 5–15 раз сразу. Включается в Настройки → Композитный сайт, обязательно проверить, что Nginx настроен (есть директива fastcgi_cache).

2. Не включён OPcache в PHP

OPcache кэширует скомпилированный байт-код PHP. Без него на каждый запрос Битрикс компилирует тысячи файлов заново. Проверьте через phpinfo() или в Мониторе производительности раздел «Настройки PHP». Минимальная конфигурация для Битрикса в php.ini:

opcache.enable=1
opcache.memory_consumption=512
opcache.max_accelerated_files=200000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

На промышленных сайтах с большим количеством файлов opcache.max_accelerated_files поднимаем до 300 000. Без этого OPcache переполняется и работает вхолостую.

3. Кэш на диске вместо Memcached/Redis

По умолчанию Битрикс хранит кэш в файловой системе — в папке /bitrix/cache/. На сайтах с трафиком от 10 000 хитов в сутки этот кэш становится узким местом: тысячи мелких файлов, миллионы операций чтения, фрагментация диска.

Решение — переключить кэш на Redis или Memcached в файле /bitrix/.settings_extra.php. Redis предпочтительнее: он умеет персистентность, кластеризацию, поддерживает структурированные данные. Установка — apt install redis, далее в Битриксе указываем 'cache' => ['type' => 'redis']. Ускорение на массовых страницах — в 3–8 раз.

4. HDD вместо NVMe под базой

Самое медленное в Битриксе — это запросы к БД. На HDD один JOIN по миллионной таблице товаров занимает 200–500 мс, на NVMe — 5–15 мс. Разница в 30 раз. В 2026 году разворачивать Битрикс на HDD — значит сразу заплатить за тормоза. Любой современный хостинг (Beget, Reg.ru, Timeweb, Yandex Cloud, Selectel) предлагает NVMe-тарифы за +200–500 ₽/мес. Это самый дешёвый способ ускорить сайт.

5. Неоптимальные запросы через старое API

Старое API CIBlockElement::GetList() — главный источник медленных запросов. Оно делает каскад джойнов и не умеет нормально кэшироваться. На каталогах с 10 000+ товаров переход на D7 API \Bitrix\Iblock\Elements\ElementXxxTable::getList() или прямые DataManager-запросы даёт ускорение в 3–10 раз. Это требует переписывания кода, но окупается на каждом запросе.

6. Включены неиспользуемые модули

Каждый установленный модуль (даже неиспользуемый) добавляет инициализацию ядра, события, права. На свежем сайте часто включены 50+ модулей, из которых работает 15. Проверьте Marketplace → Установленные решения и отключите всё, что не используется: форумы, обучение, реклама, опросы, поддержка. Эффект — минус 20–30% к времени инициализации ядра.

7. Нет индексов в HL-блоках и пользовательских таблицах

HL-блоки и пользовательские поля UF_* по умолчанию не имеют индексов. На таблицах с десятками тысяч записей запросы WHERE UF_ARTICLE = '...' сканируют всю таблицу. Решение — добавить индекс через Настройки → Highload-блоки → Индексы или вручную в БД. Эффект — ускорение конкретных страниц в 10–50 раз.

Реальный кейс: с 4.2 сек до 0.9 сек за день

Клиент — производственная компания, 12 000 товаров, шаблон Aspro Allcorp3, выручка от сайта — 60 млн ₽/год. Жалоба — медленная загрузка страниц каталога, заказчик теряет конверсию на мобильных. Аудит показал LCP = 4.2 сек, TTFB = 1.8 сек, оценка PageSpeed Mobile = 28.

Что сделали за рабочий день (8 часов):

Перенесли с виртуального хостинга на VPS с NVMe и 8 ГБ RAM (Beget, тариф «Sapphire»). +20% к скорости PHP, ×6 к скорости БД.
Включили OPcache с memory_consumption=1024 и max_accelerated_files=300000. Время выполнения PHP — минус 35%.
Поставили Redis, перевели на него кэш Битрикса и сессии. Главная страница — ускорение в 4 раза.
Включили композит на главной, листингах, странице товара. TTFB на этих страницах упал с 1.8 сек до 90 мс.
Добавили индексы на 6 ключевых полей HL-блока «Характеристики». Фильтр в каталоге — ускорение в 25 раз.
Отключили 18 неиспользуемых модулей. Время инициализации — минус 22%.
Включили в NGINX brotli-сжатие для статики и поставили HTTP/3. Объём трафика — минус 25%.
Настроили Cloudflare на кэширование статики (картинки, CSS, JS). Сэкономили ~70% запросов к origin.

Итог: LCP = 0.9 сек (было 4.2), TTFB = 90 мс (было 1800), оценка PageSpeed Mobile = 87 (было 28). Конверсия в заявку с каталога выросла на 31% за следующий месяц по данным Метрики.

Когда оптимизация уже не спасёт

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

Каталог собран на инфоблоках с 100+ свойствами — каждая страница делает 50+ запросов к БД.
Личный кабинет с историей в 100 000+ записей на пользователя — нужен внешний микросервис.
Реалтайм-функционал (чаты, уведомления) на polling вместо WebSocket.
Сложные фильтры с комбинацией 20+ свойств — стандартный smart-фильтр не справляется, нужен Sphinx или ElasticSearch.

В этих случаях нужна точечная переработка проблемных мест: вынос фильтра в отдельный поисковый движок, кэш-прослойка на Redis, переписывание кода с старого API на D7. Это уже не «настройка за день», а полноценный проект на 2–6 недель.

Аудит производительности от Inter Web

Если сайт тормозит, а вы не уверены, в чём дело — сделаем бесплатный аудит производительности за 5 рабочих дней. Проверим конфигурацию сервера, журналы, тяжёлые запросы, фронтенд. Пришлём отчёт с конкретным списком работ и оценкой эффекта в числах. Если работы небольшие — уложимся в 1–2 дня. Если нужна архитектурная переработка — честно скажем и обсудим план.