«Сайт тормозит» может означать долгое ожидание первого ответа, позднее появление главного изображения, задержку кнопки или медленный поиск. Для этих проблем нужны разные исправления. Начните с повторяемого сценария и разделения серверной работы и работы браузера. По этой инструкции можно собрать исходные замеры, определить следующий диагностический шаг и принять ускорение по результату, а не по обещанию «поставили кеш».
Опишите задержку так, чтобы её можно было повторить
Выберите одну страницу и одно действие. Запишите URL, устройство, браузер, тип подключения, состояние авторизации и время проверки. Уточните: страница долго остаётся белой, текст виден без картинки, меню не реагирует или результат поиска приходит с задержкой. Видеозапись короткого сценария бывает полезнее общего скриншота оценки производительности.
Для каталога возьмите главную, типовой раздел, карточку с вариантами и поиск. Для сайта услуг — главную, услугу, статью и форму обращения. Не тестируйте только самую лёгкую страницу. Если проблема возникает у оптового клиента, проверка гостевой версии не заменяет проверку его сценария, хотя обе нужны.
Повторите каждый выбранный сценарий несколько раз в одинаковых условиях. Отдельно отметьте первый визит и повторный, холодный и прогретый кеш. Не усредняйте их в одну цифру без пояснения. Случайный быстрый запуск не опровергает проблему, а единичный медленный не доказывает постоянный дефект.
Шаг 1. Разделите ожидание сервера и отображение
В инструментах разработчика браузера откройте вкладку Network и посмотрите запрос основного HTML-документа. Сколько заняли соединение, ожидание ответа и загрузка? Затем посмотрите запросы изображения, шрифтов и скриптов, нужных для первого экрана. Сохранять и передавать сетевой журнал нужно осторожно: он может содержать cookie, токены, параметры и личные данные.
TTFB — время до первого байта ответа. Оно включает не только выполнение PHP, но и сетевые составляющие; высокий показатель сам по себе не доказывает медленную базу. Официальное руководство web.dev по TTFB объясняет его влияние на дальнейшую загрузку. Если HTML приходит быстро, а крупный элемент появляется поздно, покупать новый сервер до анализа ресурсов преждевременно.
| Наблюдение | Первое направление | Что не доказывает |
|---|---|---|
| Долго ждём HTML | Сеть, сервер, приложение | Что виноват только PHP |
| HTML быстрый, экран поздний | Изображения, CSS, шрифты | Что нужен новый хостинг |
| Кнопка запаздывает | Скрипты и обработчики | Что поможет кеш HTML |
Если медленно только конкретное действие, найдите его запрос отдельно. Поиск может обращаться к серверу после ввода, фильтр — перестраивать каталог, корзина — пересчитывать стоимость. Скорость главного документа не характеризует эти операции. Запишите время ответа и момент, когда интерфейс действительно стал пригоден к следующему действию.
Шаг 2. Поймите, какие метрики измеряете
В текущих Core Web Vitals оцениваются LCP, INP и CLS. Согласно документации web.dev, хорошие значения — LCP не более 2,5 секунды, INP не более 200 миллисекунд, CLS не более 0,1; оценка ориентируется на 75-й процентиль посещений отдельно для мобильных и настольных устройств. Дата проверки критериев — 22 октября 2026 года.
- LCP показывает время появления крупнейшего видимого элемента. Он не всегда является картинкой: это может быть текстовый блок.
- INP описывает отзывчивость взаимодействий. Страница может быстро загрузиться и затем долго реагировать на меню или фильтр.
- CLS характеризует неожиданные сдвиги элементов. Быстрый сайт всё ещё неудобен, если кнопка уезжает при загрузке баннера.
Различайте лабораторный тест и данные реальных посещений. Лабораторный запуск удобен для воспроизведения и сравнения изменений при заданных условиях. Полевые данные показывают опыт аудитории, но не обязаны обновиться сразу после публикации исправления. При малом объёме трафика отдельных данных может не быть — это не ноль и не подтверждение идеальной скорости.
Не заменяйте скорость одним цветным баллом. Запишите саму метрику, страницу, устройство и источник замера. Улучшение оценки при сохранении медленной формы не завершает задачу. И хорошие показатели не дают гарантии поисковых позиций или роста продаж: это один из факторов качества пользовательского опыта.
Шаг 3. Если задержка до первого ответа
Попросите разработчика или администратора сопоставить медленный запрос с нагрузкой сервера: процессор, память, дисковые операции, соединения базы и фоновые задания. Важны значения в то же время, а не скриншот спокойного сервера через час. Зафиксируйте, тормозит ли весь сайт или только определённый компонент.
Проверьте расписания импорта, резервного копирования и индексации. Если тяжёлые задания накладываются на посещаемый период или друг на друга, причина может быть в управлении нагрузкой. Не отменяйте резервное копирование ради скорости: перенесите его в согласованное окно и проверьте ресурсы. Каждый фоновый процесс должен иметь понятное назначение.
Следующий уровень — время запросов к базе и выполнение компонентов. Для этого применяют средства мониторинга, доступные в конкретной установке, и ограниченное профилирование. Тяжёлое нагрузочное испытание рабочего магазина без плана способно само создать инцидент. Начинайте с наблюдения, воспроизведения на копии и измерения узкого места.
Кеш должен учитывать зависимости и пользовательский контекст. Повторное вычисление одинакового списка может быть лишним; зато персональную цену нельзя бездумно выдавать из общей сохранённой страницы. Проверяйте не только ускорение, но и корректность результата для гостя и разных тестовых пользователей.
Шаг 4. Если ответ быстрый, а первый экран медленный
Найдите фактический LCP-элемент в измерении. Если это изображение, сравните его размер в пикселях с размером отображения и весом файла. Для мобильной версии нередко загружается тот же большой файл, что и для широкого экрана. Подготовьте подходящие варианты и проверьте выбор ресурса браузером; не судите только по имени файла.
Сжимайте изображения с визуальной проверкой текста, лиц и деталей продукции. Укажите размеры или соотношение сторон, чтобы место резервировалось до загрузки. Не откладывайте загрузку главного видимого изображения так же, как изображений далеко ниже первого экрана. Правило загрузки зависит от положения и роли элемента, а не только от формата файла.
Проверьте шрифты и стили: сколько начертаний действительно используется, нет ли лишних внешних цепочек. Для скриптов выясните, что нужно прямо сейчас, а что может загружаться позже. Удаление кода без проверки может сломать согласие, форму, аналитику или оплату. Сначала составьте список зависимостей и владельцев функций.
Внешние виджеты измеряйте отдельно: чат, карта, видео, отзывы и аналитика могут влиять на загрузку и взаимодействия. Сравнение с временно отключённым виджетом проводите на тестовой копии или в контролируемом эксперименте. Это способ установить вклад, а не совет убрать полезный бизнесу инструмент навсегда.
Учебный пример: новая мощность не решает позднюю картинку
Представим, что в пяти одинаковых мобильных лабораторных запусках основной HTML приходит примерно за 0,4 секунды, а крупное изображение первого экрана появляется примерно через 5 секунд. Сетевой журнал показывает тяжёлый исходный файл и позднее начало его загрузки. Это вымышленные учебные значения, не результат аудита SignM или клиента.
Гипотеза: основной вклад находится в доставке изображения, а не в вычислении HTML. На копии меняют только варианты изображения и порядок его загрузки, затем повторяют те же измерения. Сравнивают медиану нескольких запусков, разброс и визуальную пригодность. Если LCP улучшился, проверяют ещё мобильную и настольную версии, а затем реальные посещения после публикации.
Если после изменения картинка стала быстрой, но меню всё ещё зависает, это отдельная задача отзывчивости. Не объявляйте сайт полностью ускоренным по одному показателю. Запишите оставшуюся проблему и следующую проверку. Так отчёт показывает причинную связь, а не набор выполненных действий без понятного эффекта.
Что даёт композитный режим и чего он не заменяет
Композитная технология Битрикс разделяет сохранённую статическую часть страницы и динамические области. Она может уменьшить ожидание подходящих публичных страниц, но требует правильной настройки. Наличие режима в административной панели ещё не доказывает, что конкретный URL обслуживается нужным способом.
После включения проверяют повторные гостевые запросы, поведение первого запроса после изменения и актуальность контента. Отдельно тестируют корзину, авторизацию, персональные цены, формы и пользовательские сообщения. Общий кеш не должен показывать одному посетителю данные другого. Динамическая область должна обновляться и при сбое иметь понятное поведение.
Композит не уменьшает автоматически вес фотографий, не исправляет тяжёлый JavaScript и не ускоряет все динамические операции. Если обмен блокирует базу, а поиск делает дорогой запрос, эти причины требуют отдельного разбора. Не обещайте кратное ускорение без измерения конкретных страниц и условий.
Как внедрять изменения и принимать результат
- Зафиксируйте исходные сценарии, метрики, условия и версии.
- Выберите одну проверяемую гипотезу и ожидаемый эффект.
- Сохраните предыдущие файлы и настройки; определите способ возврата.
- Измените один ограниченный участок на копии и повторите измерение.
- Проверьте формы, навигацию, цены, права и мобильную версию.
- Перенесите проверенное изменение и измерьте рабочий сайт в сопоставимых условиях.
- Наблюдайте ошибки, актуальность данных и доступные полевые показатели.
Не очищайте весь кеш перед каждым контрольным замером без отметки: вы будете сравнивать разные режимы. Не публикуйте «до» на медленной мобильной сети и «после» на быстром настольном соединении. Не объединяйте смену сервера, переписывание шаблона и замену всех картинок в один шаг, если нужно понять вклад каждого изменения.
Для отката обычно сохраняют предыдущую версию изменённых файлов и настроек. При изменении структуры данных или инфраструктуры потребуется более широкий согласованный план. После возврата повторяют функциональные проверки: восстановить прежнюю скорость ценой сломанной формы нельзя считать успешным восстановлением.
Когда не нужен новый сервер или модуль ускорения
Не покупайте мощность до подтверждения дефицита ресурсов. Не добавляйте второй кеширующий модуль, пока не разобрались с действующим кешем и его исключениями. Не переписывайте весь сайт из-за одного тяжёлого блока. Иногда достаточно исправить размер изображения, повторный запрос компонента или расписание задачи; иногда измерения действительно обосновывают смену инфраструктуры.
Холодный кеш — состояние до сохранения нужного результата; прогретый — после его формирования; водопад запросов — последовательность загрузки ресурсов; узкое место — участок, ограничивающий весь сценарий. В рабочей таблице оставьте исходный замер, гипотезу, изменение и повторный результат. Такой документ позволит оценить предложение по ускорению Битрикс и принять сделанную работу без зависимости от обещанного балла.
Применить к своей задаче
Собрать воспроизводимые замеры, отличить серверное ожидание от проблем браузера, проверить одну гипотезу и принять ускорение вместе с сохранением рабочих функций.
Журнал диагностики и приёмки скорости сайта: открыть рабочий материал · Скачать CSV для заполнения. Доступ свободный, без регистрации. Можно использовать самостоятельно или передать своему исполнителю.