Как проверить скорость сайта и найти причину задержки

Какие страницы и условия проверять

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

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

Почему PageSpeed показывает два разных результата

В PageSpeed Insights могут быть данные реальных пользователей и результат моделируемой проверки Lighthouse. Реальные данные описывают наблюдавшиеся посещения, а лабораторный запуск помогает воспроизвести проблему и найти ресурсы. Они могут различаться из-за устройства, сети, кэша и поведения людей.

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

Документация: web.dev: почему лабораторные и реальные данные различаются

Что означают LCP, INP и CLS

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

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

Документация: web.dev: показатели и пороги Core Web Vitals

Как найти источник, а не только симптом

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

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

Документация: web.dev: оптимизация Largest Contentful Paint

Что исправлять в первую очередь

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

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

Документация: web.dev: оптимизация Largest Contentful Paint

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

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

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

• Есть исходный замер и воспроизводимая проблема.
• Исправление связано с конкретным ресурсом или поведением.
• После выпуска повторены замер и покупательские сценарии.
• Лабораторные результаты отделены от реальных данных.