Скорость сайта: что измерять и что улучшать первым
Один балл в отчёте не описывает весь опыт посетителя. Важно понять, что долго появляется, что мешает действию и на каких страницах это происходит.
Разделите загрузку, отклик и устойчивость
Core Web Vitals оценивают три стороны пользовательского опыта: появление основного содержимого, реакцию на действие и неожиданные сдвиги элементов. Рекомендуемые границы «хорошего» результата: LCP до 2,5 секунды, INP до 200 миллисекунд и CLS до 0,1. Оценку смотрят по 75-му процентилю, отдельно для мобильных и настольных устройств. Определения и пороги опубликованы в документации Core Web Vitals.
Для владельца сайта практический вопрос звучит проще: когда человек видит полезную информацию, может ли быстро нажать нужную кнопку и остаётся ли она на месте во время загрузки.
Выберите страницы и сценарии
Не ограничивайтесь главной. В список измерений стоит включить важную услугу, категорию каталога, товар, статью и страницу с формой. У них разный состав содержимого: большой баннер, товарные изображения, фильтры или сторонний виджет могут создавать разные проблемы.
Зафиксируйте условия проверки и повторяйте измерения сопоставимым способом. Случайный запуск на быстром компьютере и нестабильной сети трудно использовать как основу для решения о доработках.
Сопоставьте лабораторию и реальные посещения
Лабораторная проверка полезна для поиска причин и сравнения изменений. Данные реальных посетителей показывают, что происходит на разных устройствах и соединениях. В частности, обычный запуск Lighthouse не измеряет INP без пользовательских взаимодействий; для диагностики блокировок используется TBT. Это различие также поясняется в документации web.dev.
Если реальных данных пока мало, сохраняйте ограничение в выводах. Можно улучшить конкретную загрузку по лабораторному тесту, но нельзя объявлять подтверждённым результат для всей аудитории без наблюдений.
Начните с заметных препятствий
- Проверьте размер и способ загрузки главного изображения.
- Найдите тяжёлые изображения ниже первого экрана.
- Разберите сторонние виджеты и необходимость их раннего запуска.
- Проверьте задачи JavaScript, мешающие нажатию и прокрутке.
- Задайте место для изображений и встраиваемых блоков, чтобы уменьшить сдвиги.
- Проверьте ответ сервера и повторное использование статических ресурсов.
Приоритет зависит от измеренной причины. Не стоит удалять полезные функции только ради балла или внедрять сложную оптимизацию без понимания, какая часть страницы действительно задерживает посетителя.
Проверяйте результат вместе с функциональностью
После изменения загрузки скриптов пройдите меню, поиск, формы, корзину и модальные окна. Отложенный код может ускорить первый экран и одновременно нарушить действие, если зависимости не учтены.
Рабочий план: исходное измерение → конкретная причина → небольшое изменение → повторное измерение → проверка сценариев. Сохраняйте результаты, чтобы видеть эффект каждой доработки.
Проверку производительности удобно включать в план поддержки вместе с контролем ключевых функций.
