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

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

Почему сайт на Битрикс тормозит не по одной причине

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

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

Что мы измеряем и как

Аудит идёт сверху вниз по цепочке. На фронтенде мы снимаем Core Web Vitals — LCP, INP и CLS — в полевых и лабораторных условиях, смотрим вес страницы, число запросов, наличие критического CSS и отложенной загрузки. На серверном уровне профилируем рендеринг страницы: сколько времени уходит на сборку компонентов, обращения к базе, файловые операции. Отдельно разбираем кеширование на всех уровнях — кеш компонентов, страниц, меню, тегированный и композитный кеш — и считаем коэффициент попаданий. Затем спускаемся в базу данных: включаем лог медленных запросов, анализируем планы выполнения, ищем выборки без индексов и тяжёлые места каталога, фильтра и личных кабинетов.

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

От разрозненных симптомов к плану ускорения

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

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

Когда нужен полный аудит, а когда хватит экспресс-проверки

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

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

Почему отчёт важнее красивого числа

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

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

Что вы получаете в итоге и как удержать результат

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

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

Типичные узкие места в проектах на Битрикс

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

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

Как аудит экономит деньги бизнесу

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

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

Чем мы отличаемся от шаблонной проверки скорости

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

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