Когда мне говорят «сайт тормозит», я не начинаю с покупки нового сервера. Я начинаю с вопроса: а что именно тормозит? Потому что в девяти случаях из десяти проблема не в железе, а в конфигурации. И решается она не деньгами, а часами работы.
За последние годы я ускорял десятки проектов на Битрикс. И каждый раз находил одни и те же места, где теряются секунды. Ниже — семь приёмов, которые дают измеримый результат. Не «может быть, поможет», а «проверено, работает». С замерами до и после.
Приём первый: кеш, который действительно кеширует
Самое обидное — когда кеш включён, а сайт всё равно медленный. Это не парадокс, это ошибка в ключе кеша.
В ключ компонента попадает что-то уникальное для каждого посетителя — время с точностью до секунды, идентификатор сессии, случайное значение. Кеш создаётся заново при каждом запросе. Сервер выполняет всю работу и выбрасывает результат.
Что делать. Откройте панель производительности, вкладку «Разработка». Посмотрите, какие компоненты помечены как кешируемые, но генерируются долго. Если компонент кешируется, а время генерации страницы не падает — ищите причину в ключе.
На одном проекте я нашёл в ключе кеша time(). Одна строка. Убрал — время генерации главной упало с 1,8 секунды до 0,3. В шесть раз, без единой копейки затрат.
Приём второй: агенты на cron, а не на хитах
По умолчанию агенты в Битрикс могут выполняться прямо во время запроса посетителя. Человек заходит на страницу, а система в этот момент решает отправить письмо или обновить счётчик. Страница ждёт.
Если агентов много и они тяжёлые, каждый хит превращается в лотерею. Повезёт — откроется быстро. Не повезёт — будешь смотреть на белый экран.
Что делать. Переведите всех агентов на cron. В настройках модуля «Агенты» отключите выполнение на хитах и настройте запуск через планировщик сервера. Это стандартная рекомендация, но её игнорируют чаще, чем любую другую.
Разница ощущается сразу. На проекте с каталогом на пять тысяч товаров время ответа сервера упало с 2,1 до 0,9 секунды. Только за счёт переноса агентов.
Приём третий: композит, который настроен, а не включён
Композитный сайт — технология, которая отдаёт страницу почти мгновенно, минуя выполнение PHP. Когда она настроена правильно.
Типичная ошибка: композит включён, но отдача статики не перенесена на nginx. Или страницы, которые не должны кешироваться (корзина, личный кабинет, результаты поиска), попадают в композит. Или динамические блоки на странице всё равно дёргают базу при каждом запросе.
Что делать. Проверьте, что отдача композита настроена через nginx. Убедитесь, что из композита исключены страницы с персонализированным контентом. И честно ответьте: композит включён ради галочки или ради скорости?
На одном интернет-магазине правильная настройка композита дала падение времени загрузки главной с 2,4 до 0,6 секунды. В четыре раза.
Приём четвёртый: база данных без лишних переборов
Битрикс активно работает с базой. Каждый компонент, каждый фильтр в каталоге — это запросы. Если на таблицах нет правильных индексов, база перебирает миллионы строк, чтобы найти десять нужных.
Особенно больно это в каталоге с фильтрами. Пользователь выбирает размер, цвет и производителя, а база судорожно соединяет несколько таблиц с десятками тысяч записей.
Что делать. В панели производительности есть вкладка «База данных». Там видны медленные запросы. Если запрос выполняется дольше секунды и содержит LIKE без индекса — это кандидат на оптимизацию. Для каталога с фильтрами включите фасетный индекс — он специально создан для ускорения фильтрации.
На проекте с каталогом на двадцать тысяч товаров фасетный индекс сократил время выборки в фильтре с 3,2 до 0,4 секунды. В восемь раз.
Приём пятый: сервер, настроенный под Битрикс
Хостинг с настройками «как у всех» — лотерея. По умолчанию PHP может работать как CGI, а не FastCGI. Может отсутствовать акселератор. Может быть включён open_basedir, который добавляет проверку пути к каждой файловой операции.
Каждый пункт по отдельности даёт небольшой проигрыш. Вместе они складываются в пропасть.
Что делать. Запустите проверку в панели производительности на вкладке «Конфигурация». Если видите красные отметки — начните с них. Убедитесь, что PHP работает через FastCGI, OPcache включён, статика отдаётся nginx, а не Apache.
Это базовые вещи. Но на них экономить нельзя. На одном проекте переход с CGI на FastCGI и включение OPcache дали падение времени генерации страницы с 1,5 до 0,5 секунды. В три раза, без изменения кода.
Приём шестой: изображения и скрипты, которые не грузятся «всё сразу»
Сервер может генерировать страницу за 200 миллисекунд. А браузер будет рисовать её три секунды. Потому что на странице двадцать изображений по два мегабайта каждое, три внешних скрипта и шрифт с чужого сервера.
Битрикс тут ни при чём. Но сайт от этого тормозит точно так же, как и любой другой.
Что делать. Включите ленивую загрузку изображений — те, что за пределами экрана, не будут грузиться при открытии. Проверьте, что картинки товаров оптимизированы по размеру. Объедините и минимизируйте CSS и JS через настройки главного модуля.
На проекте с фотогалереей только ленивая загрузка и сжатие изображений сократили время полной загрузки страницы с 4,8 до 1,9 секунды. В два с половиной раза.
Приём седьмой: ревизия модулей и свойств
Сайт живёт. Добавляются модули. Ставятся решения из Маркетплейса. Прикручивается интеграция с CRM, потом с 1С. Старые модули, которые «пока нужны», остаются включёнными. Старые свойства инфоблоков, которые уже не используются, остаются в базе.
Каждый лишний модуль — это обработчики событий, которые выполняются на каждом хите. Каждое лишнее свойство — это лишние данные в выборках.
Что делать. Раз в полгода проводите ревизию. Отключайте модули, которые не используются. Проверяйте, не осталось ли в инфоблоках свойств, которые не участвуют в выборках и сортировках.
Это не даст мгновенного вау-эффекта. Но остановит постепенное «утяжеление» проекта. На одном сайте отключение трёх неиспользуемых модулей и удаление двадцати мёртвых свойств дало падение времени ответа сервера с 1,1 до 0,7 секунды. Не в разы, но заметно.
Как это измерить и не обмануть себя
Не полагайтесь на ощущения. Запишите время ответа сервера для проблемной страницы до оптимизации. После каждого изменения — замеряйте снова. Иначе через месяц вы будете помнить, что «стало быстрее», но не сможете сказать, насколько.
Я использую простой замер: время генерации страницы из панели производительности плюс полное время загрузки из браузера. Первое показывает, что делает сервер. Второе — что видит пользователь. Оба важны.
И ещё одно. Ускорение в два раза — это не всегда реалистично. Иногда потолок — полтора раза, и это уже хорошо. Не гонитесь за цифрой. Гонитесь за тем, чтобы каждая секунда, которую вы можете убрать, была убрана.
А какой приём дал самый большой эффект на вашем проекте?