Аудит производительности и скорости сайта на 1С-Битрикс

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

Из чего складывается медленный отклик

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

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

Почему синтетический балл вводит в заблуждение

Браузерные инструменты измеряют то, что видит пользователь, и это ценно для клиентской оптимизации. Но они смешивают серверную и клиентскую части в один балл, а на Битрикс эти слои ведут себя по-разному. Можно идеально сжать картинки и отложить скрипты, но если сервер отдаёт первый байт через полторы секунды, пользователь всё равно ждёт. И наоборот: бывает, что сервер отвечает быстро, а тормозит уже клиентская часть, и тогда серверная оптимизация ничего не даст. Аудит как раз разделяет эти слои: мы отдельно меряем серверный TTFB и отдельно смотрим клиентскую сторону, и потому точно знаем, куда вкладываться. Если вам важна именно клиентская метрика, мы подключаем смежный аудит Core Web Vitals и PageSpeed, который разбирает отрисовку, скрипты и стабильность вёрстки.

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

Где Битрикс теряет время чаще всего

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

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

Как мы профилируем хиты

Профилирование — это разбор того, на что уходит время внутри одного хита PHP. Мы смотрим, сколько времени тратит каждый компонент, сколько запросов он делает к базе, какие события и обработчики срабатывают и сколько они стоят. Это превращает абстрактное «сайт медленный» в конкретное «листинг каталога делает 400 запросов к базе на хит, из них 380 — повторяющиеся выборки одного и того же раздела». С такой формулировкой уже понятно, что чинить и какой будет эффект. Профиль снимаем на типичных и на тяжёлых сценариях, чтобы поймать и обычное поведение, и крайние случаи.

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

Кеш: тонкая настройка, а не выключатель

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

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

Что делать с результатами аудита

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

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

Подготовка к нагрузке и пикам

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

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

Скорость как часть бизнес-результата

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

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

Кому и когда нужен аудит скорости

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

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

Почему стоит начать с аудита, а не с правок

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

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