Как проверить скорость сайта и прочитать результаты

Проверяйте скорость сайта по отдельным страницам и сценариям: сравните данные посетителей с лабораторным тестом и сохраните условия каждого измерения.

Что должно получиться

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

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

Из чего это складывается

Например, PageSpeed Insights сочетает накопленные данные CrUX и лабораторную диагностику Lighthouse. Их назначение и ограничения описаны в официальной справке PageSpeed Insights. Не смешивайте эти части отчёта в одно измерение: они получены разными способами.

Уточняйте масштаб полевых данных: отдельный URL или origin — группу страниц с одинаковыми протоколом, именем хоста и портом. Например, HTTP и HTTPS относятся к разным origin. Общая оценка такой группы не равна измерению каждой входящей в неё страницы.

Как это сделать по шагам

1. Выберите страницы и действия. Возьмите представительные адреса, а не только самый лёгкий. Запишите, что именно проверяете: открытие материала, просмотр каталога или взаимодействие с формой. Отдельно отметьте состояние входа в аккаунт и наличие персонального содержимого.
2. Запустите внешний тест нужного адреса. Для начала подойдёт PageSpeed Insights. Проверьте, какой адрес фактически анализируется после перенаправлений. Сохраните результат отдельно для мобильного и настольного режима.
3. Разберите данные реальных посетителей. Уточните, относятся ли они к выбранной странице или к origin целиком. Посмотрите, есть ли достаточные сведения по метрикам. Отсутствие данных не записывайте как успешную проверку.
4. Прочитайте лабораторную диагностику. Найдите проблемные этапы загрузки и элементы, которые инструмент выделил в отчёте. Сохраните условия запуска. Пока не меняйте несколько подсистем сразу: сначала получите исходное измерение.
5. Повторите проверку в сопоставимых условиях. Оцените разброс результатов, особенно если один запуск резко отличается от остальных. Не выбирайте только самый удачный. Для собственных измерений фиксируйте состояние кэша, сети и устройства.
6. Проверьте реальные действия на странице. Откройте меню, прокрутите материал, начните ввод в форму. Запишите задержки и скачки блоков, которые не объясняются одним начальным тестом. При необходимости передайте разработчику запись профилирования.
7. Составьте список наблюдений. Для каждого пункта укажите адрес, сценарий, показатель и условия. Отделите найденную причину от предположения. После исправления повторите тот же сценарий и сравните результат с исходным.

Какие показатели читать

LCP: появление крупного содержимого

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

INP: отклик на действия

INP относится к реакции страницы на взаимодействия. Он не равен времени загрузки документа. Страница может быстро показать текст, но заметно тормозить при раскрытии меню или вводе. В обычном лабораторном тесте начальной загрузки показатель TBT помогает диагностике блокировок, однако не заменяет полевой INP численно.

CLS: устойчивость расположения блоков

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

В документации Web Vitals хорошими ориентирами названы LCP до 2,5 секунды, INP не более 200 миллисекунд и CLS не более 0,1. Полевую оценку смотрят по 75-му процентилю отдельно для мобильных и настольных устройств. Это границы конкретных метрик, а не обещание, что весь сайт полностью загрузится за одно и то же время.

Почему лабораторный тест и данные посетителей расходятся

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

CrUX в PageSpeed Insights описывает предшествующий период сбора данных, а не только состояние страницы в момент теста. В справке указан период 28 дней. После сегодняшней правки лабораторная диагностика может измениться сразу, а накопленная картина будет обновляться по мере появления новых наблюдений. Не объявляйте исправление неудачным только из-за этого различия.

Есть и различие сценариев. Стандартный прогон может не открыть меню и не дождаться поздней вставки, с которой сталкиваются реальные люди. Особенности сравнения подробно разобраны в руководстве по измерению Web Vitals. Для неудобства, возникающего после действия, воспроизводите именно это действие.

Как сравнивать до и после

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

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

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

Частые ошибки

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

Как проверить

• Выбраны характерные страницы и записаны точные адреса.
• Мобильные и настольные результаты сохранены отдельно.
• Указано, откуда взяты данные: реальные посещения или лабораторный запуск.
• Понятно, относится полевая оценка к странице или к origin целиком.
• Есть наблюдения о загрузке, отклике и устойчивости блоков.
• Повторные измерения сопоставимы, обычный разброс не скрыт.
• Перед исправлениями сохранён исходный отчёт.

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

Вопросы и ответы

Почему один и тот же сайт получает разные результаты?

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

Можно ли проверить весь сайт по главной странице?

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

Что означает отсутствие данных реальных посетителей?

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

Нужно ли добиваться только высокого общего балла?

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

Почему после правки полевые показатели не изменились сразу?

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

Что передать разработчику вместо скриншота с баллом?

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