- В 9 случаях из 10 причина не в железе, а в настройках, кеше и коде.
- Начинать нужно с замера: без профилирования оптимизация превращается в лотерею.
- Обмен с 1С в часы пик — недооценённый источник тормозов и блокировок.
«Сайт тормозит» — самая частая формулировка, с которой к нам приходят. За ней почти всегда стоит не одна причина, а несколько наложившихся друг на друга. Ниже — те, что встречаются в проектах на «1С-Битрикс» чаще всего.
1. Окружение подобрано «как получится»
Устаревшая версия PHP, стандартные настройки MySQL из коробки, отсутствие OPcache, диски без запаса по операциям ввода-вывода, веб-сервер с настройками по умолчанию. Такой проект работает, пока трафик небольшой, и складывается на первой же акции.
Что делать: привести окружение к рекомендациям вендора, обновить PHP, настроить OPcache и пулы соединений, вынести базу и файлы на подходящие по скорости диски. Это самая дешёвая часть оптимизации и почти всегда самая результативная.
2. Кеширование выключено или работает вхолостую
Классическая картина: кеш компонентов включён, но параметры кеширования подобраны так, что кеш сбрасывается почти на каждом хите — например, в ключ попадает то, что меняется у каждого пользователя. Формально кеш есть, пользы от него нет.
Что делать: проверить реальный процент попаданий, перенести хранилище кеша в оперативную память, разделить содержимое на общее и персональное, включить композитный режим для страниц с преимущественно статичным содержимым.
3. Тяжёлые запросы к базе и фильтры без индексов
Каталог на десятки тысяч позиций, «умный фильтр» по десятку свойств, сортировка по вычисляемому полю — и одна страница выдачи превращается в сотни запросов. Отдельная беда — выборки в цикле: код в шаблоне запрашивает данные по одной записи для каждого элемента списка.
Что делать: снять профиль медленных запросов, добавить недостающие индексы, перевести фильтрацию каталога на подходящий механизм (в том числе поисковый движок для сложных фильтров), убрать запросы из циклов и агрегировать выборки.
4. Обмен с 1С идёт в часы пик
Полная выгрузка номенклатуры в разгар рабочего дня блокирует таблицы, забивает процессор и растягивает время ответа для всех посетителей. Особенно больно, когда обмен запускается по расписанию раз в час и каждый раз выгружает всё целиком.
Что делать: перевести обмен на инкрементальный режим, перенести тяжёлые операции на ночь, разбивать пакеты на порции, изолировать обмен от пользовательской нагрузки и следить за длительностью каждой сессии.
5. Фронтенд весит больше, чем нужно
Оригиналы фотографий по несколько мегабайт, подключённые «на всякий случай» библиотеки, блокирующие рендер стили и скрипты, шрифты со сторонних сервисов. Сервер уже ответил быстро, а пользователь всё ещё смотрит на пустой экран.
Что делать: сжимать и отдавать изображения в современных форматах и в нужном размере, откладывать всё, что не нужно для первого экрана, убирать неиспользуемый код, размещать шрифты на своём домене.
6. Мусорные модули и накопленные доработки
За годы жизни проекта в нём оседают решения из маркетплейса, которые давно не используются, обработчики событий от удалённых функций, дубли шаблонов. Каждый такой модуль подключается на каждом хите.
Что делать: провести ревизию модулей и обработчиков, отключить лишнее, обновить оставшееся, разобраться с журналом ошибок — он часто показывает, что часть кода падает при каждой загрузке страницы.
7. Никто не смотрит на метрики
Без мониторинга проблему замечают, когда её замечают клиенты. Нет данных о времени ответа, о загрузке базы, о росте очередей — значит, нет и понимания, что именно сломалось после очередного релиза.
Что делать: настроить мониторинг сервера и приложения, собирать время ответа по ключевым страницам, следить за ошибками и медленными запросами, фиксировать базовые показатели до и после изменений.
Порядок действий
- Измерить: время ответа сервера, профиль страниц, медленные запросы, показатели фронтенда.
- Устранить системные причины — окружение и кеширование, они дают самый быстрый эффект.
- Разобраться с базой и кодом там, где профиль показал реальные потери.
- Оптимизировать фронтенд и картинки.
- Закрепить результат мониторингом, чтобы регресс было видно сразу.
Если проходить этот путь не по интуиции, а по данным, ускорение в разы — обычный, а не выдающийся результат. Мы делаем такой разбор в формате аудита производительности: с замерами, приоритетами и планом работ, который может выполнить и ваша команда.