Ускорение сайта на Битриксе: что помогает

Содержаниесвернуть ▾развернуть ▸

1. 01Ускорение начинается с причины, а не с тумблера
2. 02Штатное кеширование — первый бесплатный рычаг
3. 03Оптимизация отдачи страницы
4. 04Хостинг и CDN — когда узкое место снаружи
5. 05Как выглядит настоящее ускорение
6. 06Короткий чек-лист перед ускорением

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

Ускорение начинается с причины, а не с тумблера

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

Отсюда правило, которое экономит деньги: сначала найти узкое место, потом включать рычаги. Если делать наоборот, любое ускорение держится на кеше и рассыпается при первом сбросе. Как искать причину по шагам — в опорной статье про сайт на Битриксе, который тормозит. Здесь разберём сами рычаги — по убыванию пользы.

Штатное кеширование — первый бесплатный рычаг

У Битрикса есть встроенное кеширование: результат работы компонента сохраняется и отдаётся из готового, вместо того чтобы каждый раз собираться заново. Включается в настройках продукта: автокеширование и управляемый кеш. Управляемый (тегированный) кеш удобнее неуправляемого тем, что сам сбрасывается при изменении данных: поправили цену или товар — соответствующие страницы пересобрались, остальное осталось в кеше.

У этого рычага есть граница. Кеш ускоряет повторную отдачу страницы, но не оптимизирует сам сайт. Если страницу тормозит тяжёлый запрос к базе или скрипт, перебирающий лишнее, кеш его не уберёт — он спрячет результат до первого сброса. Первому посетителю, для которого кеш ещё не собран, по-прежнему медленно. Поэтому кеширование — это ускорение доставки, а не лечение причины.

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

Оптимизация отдачи страницы

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

Эффект здесь скромнее, чем от устранения настоящей причины, зато и риск ниже: браузер получает меньше и более лёгких файлов, картинки ниже первого экрана не тормозят его отрисовку. На сайте, где базовые вещи не тронуты, этот слой иногда даёт заметный прирост сам по себе.

Хостинг и CDN — когда узкое место снаружи

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

Это не значит, что хостинг не важен: неподходящий тариф добьёт даже здоровый сайт. Важно не путать причину со следствием — сначала диагностика, потом железо. Какой сервер действительно нужен Битриксу под вашу посещаемость и вилки цен — в статье про хостинг для Битрикса.

Как выглядит настоящее ускорение

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

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

Короткий чек-лист перед ускорением

Что можно проверить самому, прежде чем звать кого-то со стороны:

1. Включены ли автокеширование и управляемый кеш в настройках продукта.
2. Включены ли объединение и сжатие CSS- и JS-файлов, отложенная загрузка картинок.
3. Когда последний раз чистили временные папки и какие скрипты их наполняют.
4. Соответствует ли хостинг требованиям Битрикса и вашей реальной посещаемости.
5. Какие именно страницы тормозят и когда — всегда или в пиковые часы.

Если хочется, чтобы причину нашли и убрали профессионально, — в Редстаре есть технический аудит: находим, что именно тормозит, и лечим причину, а не симптом. Обычно аудит стоит 20 000 ₽, читателям этого блога — бесплатно по промокоду «olegrodin»: назовите его менеджеру при обращении.

Услуга по темеТехподдержка сайтов на 1С-Битрикс→Сайт на Битриксе работает, обновляется и не тормозит — без вашего участия. Мониторинг, обновления, правки и дежурство при сбоях.