Скорость сайта Битрикс на мобильных: как читать отчёт и найти причину задержки

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

Что именно измерять на мобильных: сценарии и условия

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

Условия должны быть воспроизводимыми. Если сегодня вы мерили на быстром Wi-Fi, а завтра на медленном мобильном соединении, сравнение потеряет смысл. Зафиксируйте: модель или класс устройства, версию браузера, тип соединения, географию, состояние кеша, наличие авторизации. Для повторного замера используйте те же условия, иначе вы будете сравнивать разные вещи.

Отдельно определите, что считается проблемой. Не «сайт медленный вообще», а «карточка товара на мобильном в сети 4G показывает основной контент дольше, чем мы считаем приемлемым». Такой критерий можно проверить и оспорить. Ответственный за этот этап — аналитик или руководитель проекта, который согласует список сценариев с бизнесом.

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

Какие данные собрать до первого вывода

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

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

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

Важно заранее договориться, какие метрики вы считаете основными. Для мобильных обычно важны время до появления основного контента и общая стабильность загрузки. Но конкретные пороги вы устанавливаете сами, исходя из бизнеса, а не из универсальной нормы.

Как читать отчёт: этапы загрузки и точки задержки

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

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

Полезно смотреть отчёт в разрезе сценариев: каталог, карточка, поиск, корзина. Если проблема только в корзине, ищите её в логике корзины, а не в общих настройках сайта. Если проблема во всех сценариях, проверяйте сервер и общий кеш.

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

Синтетические замеры и реальный опыт: где граница

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

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

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

Ответственный за сопоставление — аналитик. Он должен явно указывать, из какого источника взята цифра, чтобы не создавать ложной уверенности.

Сервер, база данных и кеш: что проверять по порядку

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

В Битрикс есть штатные механизмы кеширования компонентов и композитный кеш. Но их работа зависит от настроек и от того, насколько сценарий персонализирован. Если страница собирается для каждого пользователя отдельно, общий кеш не поможет, и нужно смотреть на другие решения.

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

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

Фронтенд на мобильных: вес, порядок и блокировки

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

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

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

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

Варианты решения и критерии выбора

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

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

Критерии выбора: воспроизводимость проблемы, влияние на бизнес-сценарий, стоимость и риск изменений, возможность отката. Если проблема воспроизводится в синтетике и подтверждается реальными данными, решение приоритетно. Если проблема только в одном сценарии, не нужно перестраивать весь сайт.

Как организовать работу и не потерять результат

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

Важно вести журнал изменений: что меняли, когда, зачем, какой результат ожидали и что получили. Без этого через месяц никто не вспомнит, почему были выбраны те или иные настройки. Журнал помогает и при откате.

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

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

Учебный пример: разбор задержки в карточке товара

Учебный пример. Компания с интернет-магазином на Битрикс замечает, что на мобильных карточка товара открывается заметно медленнее, чем каталог. Данные условные, это не реальный кейс.

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

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

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

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

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

Ограничения: если бы карточка была сильно персонализирована, кеширование блоков могло не подойти. Тогда пришлось бы искать другие решения.

Чек-лист приёмки изменений

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

Ошибки и ограничения

Типичная ошибка — гнаться за общим баллом, не разбираясь, из чего он складывается. Балл может быть высоким, а конкретный сценарий — медленным. Другая ошибка — менять несколько вещей сразу и не понимать, что именно помогло. Третья — переносить изменения на рабочий сайт без проверки на копии.

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

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

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