Как проверить
скорость сайта
Какие сервисы открыть, как прочитать отчёты и превратить замечания о скорости в понятные задачи разработчику.
Найти причину.
Проверить результат.
Разбираем лабораторные замеры и опыт реальных посетителей. Показываем порядок работы с PageSpeed, сетевыми запросами и отчётами Яндекса.
Что именно проверять и какой результат получить
Проверка скорости сайта должна заканчиваться списком воспроизводимых проблем и задачами на исправление. Число в цветном круге полезно для сравнения замеров, но само по себе не объясняет, почему посетитель ждёт фотографию товара или не может открыть меню. В этом руководстве пройдём путь от выбора страниц до повторной проверки после доработок.
Возьмите по одному адресу каждого важного шаблона: главную, услугу, категорию, карточку товара, статью, контакты. Добавьте тяжёлые варианты: длинную галерею, большой каталог, страницу с калькулятором. Если улучшаете весь сайт, ведите реестр всех URL и отмечайте, какие проверены лично, а какие пока представлены только контрольной страницей шаблона.
Для каждого адреса запишите устройство, дату, версию сайта и состояние: первый визит, повторный визит, открытое меню, выбранный фильтр. Проверка публичной страницы без авторизации не подтверждает скорость личного кабинета. Доступ к нему и сценарии проверки согласуйте отдельно.
Таблица URL и условий, сохранённые отчёты, список причин, ответственные за исправления и повторные замеры. Учебные примеры ниже показывают порядок работы; это не показатели клиентских проектов.
Какой инструмент выбрать
| Сервис | Что смотреть | Чего он не подтверждает |
|---|---|---|
| PageSpeed Insights | Лабораторную загрузку и доступные данные CrUX | Работу всех страниц и действий посетителя |
| GTmetrix | Загрузку в указанных условиях и последовательность запросов | Равенство результата оценке другого сервиса |
| Chrome DevTools: Network | Конкретные запросы, их размер, ожидание и источник | Статистику всей аудитории по одному открытию |
| Яндекс Метрика | Время загрузки у посетителей, сегменты и динамику | Точную копию метрик и оценки Lighthouse |
| Яндекс Вебмастер | Доступность URL и ответ сервера для выбранного робота | Отрисовку первого экрана на телефоне |
Для первого прохода достаточно PageSpeed и браузера. Метрику подключайте для проверки реального опыта посетителей, а дополнительный лабораторный сервис — для конкретной гипотезы. Перед платным тестом уточните доступные настройки в своём тарифе: перечень регионов и устройств может меняться.
Как запустить PageSpeed и сохранить проверку
- Откройте PageSpeed Insights, вставьте полный адрес нужной страницы с HTTPS и запустите анализ.
- Дождитесь завершения. Убедитесь, что итоговый URL относится к нужной странице: перенаправление на главную или заглушку меняет смысл проверки.
- Посмотрите результаты для мобильных устройств и компьютеров отдельно. Сохраните ссылку на отчёт и дату.
- В верхней части проверьте, есть ли данные реальных пользователей и относятся ли они к этому URL или всему источнику — origin.
- В лабораторной части запишите оценку Performance и значения метрик. Раскройте замечания, связанные с худшим показателем.
- Сохраните параметры запуска, показанные в отчёте: версию Lighthouse, ограничения сети и устройство. Они нужны для сопоставимого повторного измерения.
В журнале проверок не объединяйте четыре оценки в одну. Performance, Accessibility, Best Practices и SEO отвечают на разные наборы автоматических проверок. Зелёный SEO-блок не заменяет полноценный аудит индексации, а высокий Performance не подтверждает доставку заявки.
Если сервис завершился ошибкой, зафиксируйте её как незавершённый замер. Не подставляйте прошлую оценку в новую строку. При сообщении о перегрузке сервиса вернитесь к проверке позже; при недоступности страницы сначала проверьте сам URL в браузере и ответ сервера.
Почему реальные пользователи и лаборатория показывают разное
По документации PageSpeed, лабораторная часть — отдельная загрузка в контролируемых условиях. Данные CrUX описывают опыт реальных пользователей за предыдущие 28 дней. Поэтому опубликованное сегодня исправление может отразиться в новом лабораторном замере сразу, а полевая статистика изменится постепенно.
При недостатке данных по конкретной странице сервис может показать сведения об origin. Это более широкая группа адресов, а не доказательство качества выбранного URL. Если статистики нет совсем, отметьте «недостаточно данных», продолжайте лабораторную проверку и анализ собственной аналитики. Отсутствие данных не означает ни прохождения, ни провала проверки.
У новой карточки товара хороший лабораторный результат, но верхний блок показывает неудовлетворительную оценку всего источника. Проверьте подпись охвата данных и другие шаблоны. Исправлять карточку только из-за общего результата, не найдя её собственной проблемы, преждевременно.
При сравнении до и после фиксируйте оба источника, но оценивайте каждый в своём временном масштабе. Не обещайте заказчику обновление полевой статистики в день публикации.
Какие значения записывать кроме общего балла
| Показатель | Что отражает | Ориентир |
|---|---|---|
| LCP | Появление крупнейшего видимого элемента контента | Хорошее значение — не более 2,5 с |
| INP | Задержку отклика на взаимодействия | Не более 200 мс |
| CLS | Нестабильность расположения элементов | Не более 0,1 |
| FCP | Появление первого контента | Используйте для поиска начала задержки |
| TBT | Блокировки основного потока при лабораторной загрузке | Помогает искать тяжёлую работу JavaScript |
| Speed Index | Темп визуального заполнения страницы | Сравнивайте со снимками загрузки |
Пороговые значения LCP, INP и CLS относятся к Core Web Vitals. Для оценки реальных пользователей проверяют 75-й процентиль отдельно для мобильных устройств и компьютеров. Обычный лабораторный запуск Lighthouse без действий пользователя не измеряет INP; TBT помогает диагностике, но не заменяет его.
По описанию расчёта Lighthouse, Performance складывается из метрик. Список рекомендаций влияет на оценку через изменение этих метрик, а не количеством закрытых предупреждений. Состав и веса зависят от версии: не переносите формулу из старой статьи в новый отчёт.
Если LCP хороший, а балл ниже ожидаемого, посмотрите остальные значения. Например, Speed Index оценивает визуальный прогресс; один своевременно появившийся крупный блок ещё не описывает всю картину загрузки.
Как сравнивать PageSpeed, GTmetrix и повторные запуски
Одинаковый URL не гарантирует одинаковые условия. Могут различаться география сервера проверки, браузер, ограничения сети и процессора, версия движка, кэш, сторонние запросы. GTmetrix объясняет различия методики; две итоговые оценки нельзя считать взаимозаменяемыми.
Откройте отчёт GTmetrix и сначала найдите сведения об условиях запуска. Затем сопоставьте конкретные запросы и этапы загрузки с PageSpeed. Если отличаются условия, используйте отчёты для поиска причин, а не для вывода «один сервис ошибается».
Для внутреннего протокола можно согласовать три последовательных замера одной версии в одинаковых условиях и записывать медиану вместе с диапазоном. Это рабочее правило команды, не требование Google. Не выбирайте единственный лучший запуск и не повторяйте тест до случайного получения 100.
Большой разброс требует отдельной гипотезы: медленный внешний виджет, нестабильный серверный ответ, разная выдача контента или прогрев кэша. Меняйте один фактор за раз. Иначе одновременно включённые кэширование, сжатие и новый плагин не позволят понять, что помогло и что сломало страницу.
Как найти источник задержки в Network
- Откройте страницу в Chrome, затем инструменты разработчика и вкладку
Network. - Выберите согласованный профиль сети. Для отдельного теста первого визита включите
Disable cacheпри открытых инструментах; состояние кэша запишите в журнал. - Перезагрузите страницу и дождитесь появления основного контента. Найдите запрос документа, затем изображения, шрифты и скрипты.
- Откройте медленный запрос и вкладку
Timing. Сравните ожидание ответа с передачей данных. ПосмотритеInitiator, чтобы понять, что запустило запрос. - Сохраните скриншот последовательности запросов — waterfall — и адрес подозрительного ресурса. Повторите загрузку с обычным кэшем как отдельный сценарий.
Элементы интерфейса описаны в справке Chrome Network. Длинная полоса сама по себе не доказывает проблему хостинга. Если изображение запрошено поздно после выполнения скрипта, быстрый сервер не уберёт задержку обнаружения этого изображения.
При передаче HAR-файла разработчику сначала проверьте его содержимое и состав экспорта: в сетевых данных могут быть параметры запросов и сведения авторизованной сессии. Для публичного примера часто достаточно снимка waterfall и конкретных URL ресурсов без персональных данных.
Что смотреть в Метрике и Вебмастере
В Метрике выберите счётчик сайта, затем отчёт «Мониторинг → Время загрузки страниц». Установите период, выделите нужную страницу по URL просмотра и сравните сегменты по устройствам, браузерам или географии. Откройте этапы загрузки и найдите, где увеличивается время.
Справка отчёта описывает этапы DNS, соединения, ответа сервера и обработки страницы. По умолчанию используется квантиль 50%, который можно менять. Поэтому его число нельзя напрямую приравнивать к 75-му процентилю CrUX. Записывайте выбранный квантиль вместе с периодом и фильтрами.
Практический порядок: найдите ухудшение в определённом сегменте, выберите пример URL, воспроизведите его в браузере и только затем формулируйте причину. Общая средняя динамика без разбивки способна скрыть проблему одного важного шаблона.
В Вебмастере инструмент «Проверка ответа сервера» помогает проверить доступность URL, код ответа и SSL для выбранного робота. Укажите страницу, выберите робота и выполните проверку. Успешный HTTP-ответ не доказывает быструю отрисовку браузером: для неё вернитесь к PageSpeed и Network.
Как превратить замечание сервиса в гипотезу
| Что наблюдаем | Что проверить | Чем подтвердить исправление |
|---|---|---|
| Поздно появляется главный контент | LCP-элемент, время ответа документа, момент запроса картинки | Сравнение этапов LCP и повторный замер |
| Скачут текст и кнопки | Размеры изображений, место под виджеты, замену шрифтов | Запись загрузки и проверка сдвигов |
| Меню реагирует с задержкой | Долгие задачи во время самого взаимодействия | Повторение действия на целевом устройстве |
| Картинка тяжелее необходимого | Фактически выбранный файл, размеры отображения и качество | Новый размер передачи без потери нужной детализации |
| После оптимизации пропала форма | Отложенные и объединённые скрипты | Полный сценарий формы, а не только новый балл |
Для LCP используйте разбор этапов загрузки: ответ сервера, обнаружение и получение ресурса, задержка его отображения. Сжатие картинки бесполезно против задержки, возникшей до её запроса. Для CLS проверьте резервирование места по рекомендациям по визуальной стабильности. Для медленных действий нужна диагностика INP в сценарии взаимодействия.
Не отключайте изображение, форму или аналитику только ради отчёта. После каждой правки проверьте, сохранилась ли функция, ради которой элемент установлен. Приоритет отдавайте проблеме, мешающей важному действию посетителя, а не самому длинному списку советов.
Что написать вместо «сделайте сайт быстрее»
Хорошая задача содержит наблюдение, условия, доказательство и критерий повторной проверки. Не назначайте причину заранее: формулировка «медленный хостинг» без анализа запроса документа может направить работу не туда.
URL: страница услуги. Условие: первый визит на мобильном устройстве, профиль сети и версия отчёта приложены. Наблюдение: главный баннер появляется после остальных элементов. В waterfall запрос баннера начинается после выполнения скрипта галереи. Просьба: проверить обнаружение LCP-ресурса и устранить подтверждённую задержку. Приёмка: сравнить этапы LCP в тех же условиях, сохранить видимый баннер и работу галереи на телефоне и компьютере.
Приложите ссылку на отчёт, снимок с выделенным запросом, дату и идентификатор версии сайта. В отдельной строке оставьте ожидаемый критерий: например, согласованную границу метрики или отсутствие конкретной задержки. Если причина ещё не установлена, сначала поставьте задачу на диагностику.
Несколько проблем оформляйте отдельными пунктами. Так можно принять исправление изображения, не закрывая оставшуюся задержку фильтра. Для комплексной проверки используйте также нашу инструкцию по приёмке сайта.
Как подтвердить улучшение после публикации
Проверьте, что тестируете опубликованную версию: старый кэш или другой домен способны полностью изменить вывод. Повторите исходные условия, затем пройдите пользовательский сценарий. Если правка затрагивает общий шаблон, проверьте и другие типы страниц, которые его используют.
Сохраните исходный и новый отчёты рядом. Если улучшился только балл, а проблемный сценарий остался медленным, задача ещё не решена. Если сервис временно недоступен, оставьте пункт измерения открытым и отдельно отметьте выполненные функциональные проверки.
Частые вопросы о проверке скорости
Нужно ли обязательно получить 100 в PageSpeed?
Это может быть согласованной целью проекта, но один запуск со 100 не подтверждает качество всего сайта. Нужны сопоставимые условия, проверка важных URL и сохранность пользовательских действий. По методике Lighthouse зона 90–100 считается хорошей оценкой производительности.
Почему компьютер получил 100, а телефон значительно меньше?
Сначала сравните условия двух отчётов. Мобильная проверка моделирует иные ограничения. Затем найдите метрику с ухудшением и связанные с ней ресурсы; переносить компьютерный результат на телефон нельзя.
Почему после исправления реальные данные всё ещё плохие?
Они отражают накопленный период, а не только последнюю загрузку. Проверьте охват URL или origin, дату публикации и свежий лабораторный результат. Затем наблюдайте динамику полевых данных.
Как проверить новый сайт без посетителей?
Начните с лабораторных замеров, Network и сценариев на целевых устройствах. Недостаток CrUX отметьте в отчёте. По мере появления аудитории добавляйте анализ реальных загрузок.
Можно ли судить о сайте по проверке главной?
Нет: карточка товара, каталог и статья могут загружать другие изображения и скрипты. Выберите представителей всех шаблонов, затем расширяйте проверку по реестру URL и важности страниц.
Гарантирует ли хорошая скорость рост позиций?
Нет. Google прямо поясняет, что хорошие Core Web Vitals не гарантируют верхние позиции. Скорость — часть качества страницы; содержание и соответствие запросу также важны. См. рекомендации Google по удобству страниц.
Если нужны измерения, диагностика и проверка доработок, начните с технического развития сайта. Для связи технических проблем с видимостью в поиске используйте SEO-аудит и продвижение. Проверку интерфейса на разных экранах разбираем в отдельном руководстве.
НАЙДЁМ, ЧТО ЗАМЕДЛЯЕТ
ВАШ САЙТ
Проверим важные страницы, разберём причины задержек и согласуем доработки с понятными критериями повторной проверки.