Сайт может долго показывать пустой экран, быстро открываться и затем зависать при нажатии на кнопку или сдвигать форму, пока догружаются изображения. Для посетителя всё это выглядит как «сайт тормозит», но причины и способы исправления разные.
Начинать стоит с конкретной страницы и действия, которое не удаётся выполнить без ожидания. Замена хостинга, сжатие всех картинок или установка ещё одного плагина ускорения без измерений могут не затронуть источник задержки.
Что именно считать медленной работой
У загрузки нет одного универсального момента «всё готово». Посетителю важно увидеть предложение, открыть нужный раздел и отправить заявку. Поэтому полезно разделить три стороны качества страницы.
| Что замечает посетитель | Что помогает измерить | Ориентир хорошего значения |
|---|---|---|
| Главное изображение или крупный текст появляются поздно | LCP — время появления крупнейшего видимого изображения или текстового блока | Не более 2,5 секунды |
| После клика, касания или нажатия клавиши интерфейс поздно обновляется | INP — задержка до следующего отображения после взаимодействия | Не более 200 миллисекунд |
| При загрузке элементы неожиданно смещаются | CLS — показатель визуальной стабильности | Не более 0,1, без единицы времени |
LCP, INP и CLS составляют Core Web Vitals. Для полевой оценки используют 75-й процентиль отдельно для мобильных и настольных устройств: не менее 75% измеренных посещений должны укладываться в хороший порог. Это не среднее значение и не результат одного открытия страницы.
INP не показывает, за сколько завершится покупка или придёт ответ сервера. Например, кнопка может сразу показать состояние «Отправляем», а подтверждение заявки появится позже. Отзывчивость кнопки и длительность отправки нужно проверять раздельно.
Для поиска причин дополнительно смотрят TTFB — время от начала перехода до первого байта ответа. Оно включает не только обработку на сервере, но и сетевые этапы, установку соединения и перенаправления. По одному высокому TTFB нельзя заключить, что виноват хостинг. Низкий TTFB, в свою очередь, ещё не означает, что посетитель увидел страницу.
Как проверить скорость загрузки сайта
Для первого обследования подойдёт PageSpeed Insights. В нём есть два разных вида данных, которые нельзя смешивать.
Полевые данные CrUX отражают опыт реальных пользователей Chrome за предшествующие 28 дней. Посмотрите, относятся ли они к выбранному адресу или ко всему origin — группе страниц с одной схемой соединения, доменным именем и портом. Если данных по странице мало, инструмент может показать общую оценку origin. Она не доказывает, что конкретная карточка товара работает так же, как главная.
Отсутствие полевых данных означает, что доступной выборки недостаточно для такого отчёта, а не что сайт быстрый или медленный. При необходимости специалист настраивает собственный сбор показателей реальных посещений — RUM.
Лабораторные данные Lighthouse — отдельный прогон страницы в моделируемых условиях. Он помогает найти задержки и проверить гипотезу исправления. Его оценка в баллах не равна оценке всех посетителей. Обычный прогон загрузки без действий пользователя не измеряет INP; лабораторный TBT помогает искать блокировки, но не заменяет INP.
Для владельца бизнеса первый проход может выглядеть так:
- Выбрать страницы, через которые клиенты решают задачу: посадочную из рекламы, услугу, каталог, карточку товара, форму. Не ограничиваться главной.
- Отдельно сохранить мобильные и настольные отчёты, дату и адрес проверки.
- На реальном телефоне повторить путь клиента: открыть страницу, вызвать меню, выбрать фильтр, заполнить форму. Записать, где возникает ожидание.
- Передать специалисту отчёт вместе с этим сценарием. Скриншот низкого балла без описания проблемы даёт мало оснований для выбора работ.
В Chrome DevTools панель Network показывает последовательность запросов и время их этапов. Панель Performance помогает разобрать отрисовку, занятость браузера и реакцию на действия. Эти инструменты нужны для установления причины, а не для получения ещё одного красивого итогового числа.
Где обычно возникает задержка
Изображения: важны размер и момент загрузки
Фотография из исходного архива может загружаться целиком даже там, где на телефоне нужна небольшая версия. Нужно проверять фактически переданный файл, а не только размер картинки на экране. Адаптивные варианты с srcset и sizes позволяют браузеру выбрать подходящее изображение.
Формат и степень сжатия подбирают с проверкой качества: надписи на товаре и полезные детали должны оставаться различимыми. Переход на WebP или AVIF сам по себе не устраняет задержку, если картинка начинает загружаться поздно или скрыта до выполнения скрипта.
Крупное изображение первого экрана, которое становится LCP-элементом, не следует откладывать через loading="lazy". Отложенная загрузка полезна для изображений ниже первого экрана. Главный ресурс, наоборот, должен быть обнаружен достаточно рано. Приоритет загрузки задают избирательно: если объявить важными все картинки, браузеру сложнее выделить нужную.
Размеры или соотношение сторон изображения стоит резервировать заранее. Это помогает избежать сдвигов текста и кнопок, пока файл ещё загружается.
JavaScript: файл скачался, но работа браузера продолжается
JavaScript отвечает за интерактивность. После скачивания браузеру нужно разобрать и выполнить код. Долгая работа в основном потоке может задерживать и показ страницы, и реакцию на нажатия.
Проверяют, нужен ли весь подключённый код именно этой странице, не дублируются ли библиотеки и можно ли загружать отдельные функции по необходимости. Например, код видеоплеера не обязательно нужен до появления самого видео.
Отложить загрузку скрипта недостаточно, если затем он надолго занимает браузер. Для проблем с меню, фильтром или формой нужно записать именно это взаимодействие и посмотреть обработчики событий. Исправление может состоять в сокращении вычислений или разделении работы на короткие задачи.
Минификация и передача с gzip или Brotli уменьшают объём текстовых ресурсов. Они не заменяют сокращение ненужной работы JavaScript.
CSS и шрифты: ресурсы готовы не в том порядке
CSS определяет внешний вид страницы. Ожидание необходимых стилей может задерживать отрисовку, поэтому проверяют объём, состав и способ подключения файлов. Стили редко используемого раздела не всегда нужно передавать каждому посетителю.
Однако удалять всё, что оказалось неиспользованным в одном тесте, нельзя: правила могут понадобиться открытому меню, сообщению об ошибке или другому размеру экрана. Оптимизацию сверяют с состояниями интерфейса.
У шрифтов проверяют число начертаний, объём файлов и поведение до их загрузки. Возможность сначала показать запасной шрифт помогает избежать невидимого текста, но замена гарнитуры может сдвинуть вёрстку. Нужна проверка читаемости и стабильности, особенно рядом с формой и кнопками.
Сервер: ожидание HTML, данных и свободных ресурсов
Если задержка возникает до начала получения страницы, специалист разделяет сетевое ожидание и работу приложения. На сервере проверяют запросы к базе данных, формирование страницы, доступность памяти и обработчиков, обращения к другим системам.
Одна страница может ждать повторяющиеся запросы к базе, другая — внешний ответ, третья — свободный обработчик при росте нагрузки. Поэтому увеличение тарифа хостинга выбирают по наблюдаемому дефициту ресурсов, а не по одному медленному открытию.
Кэширование позволяет повторно использовать подходящий результат вместо постоянного пересчёта или скачивания. Но правила должны учитывать обновления и персональные данные. Общий кэш не должен отдавать одному посетителю корзину или содержимое кабинета другого.
CDN может приблизить раздачу ресурсов к посетителям. Он не исправляет автоматически долгий запрос к базе или тяжёлую обработку фильтра в браузере.
Внешние сервисы: карта, чат и аналитика тоже требуют ресурсов
Виджеты, карты, видео и счётчики могут добавлять запросы, загрузку кода и вычисления. Состав подключений стоит сверить с текущими задачами бизнеса: иногда на сайте остаются дублирующие или уже ненужные инструменты.
В диагностическом окружении можно сравнить сценарий с конкретным виджетом и без него. Если разница воспроизводится, обсуждают способ подключения: загрузку по необходимости, замену необязательного встраивания или удаление подтверждённо ненужного кода.
Нельзя просто отключить аналитику, чат или защиту формы ради балла. После изменения способа загрузки нужно проверить, что обращения принимаются, а нужные события учитываются. Основное содержимое страницы также не должно бесконечно ждать необязательный сервис; для такого ожидания нужен понятный предел и предусмотренное состояние ошибки.
Как выбрать первую доработку
Приоритет задаёт связь задержки с задачей клиента и подтверждённой причиной. Полезнее исправить ресурс, который мешает увидеть предложение, чем уменьшить файл, загружаемый после завершения основного действия.
| Наблюдение | Что проверить первым |
|---|---|
| До появления содержимого долго нет ответа | Этапы соединения, перенаправления и серверную обработку |
| Текст уже виден, главный баннер появляется поздно | Начало запроса изображения, его объём и задержку показа |
| Страница видна, но меню или фильтр зависают | Выполнение скриптов и обработчик конкретного действия |
| Кнопка меняет положение во время загрузки | Зарезервированные размеры, вставляемые блоки и шрифты |
| Ожидание заметно только на отдельных страницах | Отличия шаблона, данных и подключённых ресурсов |
Учебный пример: на странице услуги большой баннер создаётся скриптом карусели. Проверка показывает, что браузер начинает запрашивать картинку только после выполнения скрипта. Гипотеза — подготовить первый слайд в исходной разметке, не дожидаясь всей карусели. Проверять нужно момент появления баннера и работу переключения слайдов. Само уменьшение файла изображения здесь не устраняет позднее начало запроса. Это иллюстрация метода, а не результат клиентского проекта.
Если источник задержки пока не установлен, задачу разумно начать с технического аудита сайта: согласовать страницы, сценарии и ожидаемые основания для рекомендаций. Для более широкой проверки ошибок пригодится чек-лист технического аудита.
Как сравнить результат до и после
Ускорение сайта — проверяемое изменение поведения на согласованных страницах и сценариях. Чтобы разница в отчётах относилась к доработке, условия нужно зафиксировать заранее.
Для лабораторного сравнения сохраните:
- адреса и путь входа, включая перенаправления;
- инструмент, его версию и режим проверки;
- устройство или настройки эмуляции, размер экрана, ограничения сети и процессора;
- состояние браузерного кэша, входа в аккаунт и согласия на подключение внешних сервисов;
- содержание страницы и последовательность действий.
Первое открытие с пустым браузерным кэшем и повторный визит проверяют отдельно. Быстрый повторный визит не подтверждает такой же результат для нового клиента. У приложения и CDN тоже может быть кэш: его состояние нужно учитывать, если оно меняет результат.
Проведите несколько повторов в каждом наборе условий. Для лабораторных прогонов полезно показать медиану и разброс, а не выбрать лучший запуск «после» и худший «до». Количество повторов и приемлемую разницу согласуют до работ с учётом нестабильности измерений. Если результаты сильно колеблются, сначала выясняют причину разброса.
Для полевого сравнения используют одинаковый источник и уровень данных, сопоставимые устройства, страницы и периоды. Скользящее 28-дневное окно CrUX сразу после исправления ещё содержит посещения прежней версии. Изменение аудитории, сети или состава страниц тоже может повлиять на итог. При собственном сборе RUM полезно различать версии сайта и сравнивать достаточно наполненные группы.
После технического измерения повторите рабочий путь клиента: меню, поиск, фильтры, валидацию и отправку формы, оформление заказа, нужные события аналитики. Изображения должны сохранять качество, а персональные данные — оставаться изолированными. Улучшение одной метрики не оправдывает поломку другой функции.
Для ускорения сайта стоит заранее согласовать список страниц и действий, исходные замеры, предполагаемые причины, объём исправлений и способ приёмки. Итоговый отчёт должен связывать каждую доработку с измеренным изменением и оставшимися ограничениями. Фиксированный процент ускорения или постоянные 100 баллов без учёта устройства, сети и внешних зависимостей не дают надёжного критерия результата.
