Что именно измеряют
Разговор о скорости часто сводится к весу страницы, но вес — только причина. Измеряют то, как страница ощущается: когда появляется основной контент, прыгает ли вёрстка при загрузке, быстро ли интерфейс реагирует на нажатие.
В Google эти параметры сведены в Core Web Vitals: LCP — время до отрисовки главного элемента, CLS — величина сдвигов вёрстки, INP — задержка реакции на действие пользователя. Ориентиры, которые Google публикует как хорошие: LCP до 2,5 секунды, CLS до 0,1, INP до 200 миллисекунд. Это не обещания подрядчика, а общедоступные пороги оценки.
Практическая польза от метрик в том, что они позволяют обсуждать факт, а не впечатление. «Мне кажется, медленно» и «LCP на мобильном профиле 4,1 секунды» — разные уровни разговора с исполнителем.
Что реально влияет
Порядок влияния примерно такой: изображения, шрифты, сторонние скрипты, ответ сервера, затем всё остальное. Картинка на несколько мегабайт в первом экране портит впечатление сильнее, чем любая микрооптимизация кода.
Шрифты блокируют отрисовку текста: пока файл не загружен, браузер либо ждёт его, либо показывает невидимый текст. Подключение веб-шрифта — всегда компромисс между внешним видом и скоростью первого экрана.
Сторонние скрипты — счётчики, чаты, карты, виджеты — грузятся с чужих серверов, и вы не управляете их доступностью. Один тяжёлый виджет способен свести на нет всю работу по оптимизации, причём обнаружится это уже после запуска.
Четвёртый фактор — ответ сервера. Пока сервер думает над страницей, браузер не начинает её отрисовывать: помогает кэширование, но не спасает медленный запрос к базе на каждый визит. Пятый — порядок загрузки: если сначала грузится то, что не видно на первом экране, человек ждёт лишнее время, хотя все ресурсы полезны.
Что влияет меньше, чем принято думать
Количество запросов само по себе мало о чём говорит: современные протоколы позволяют держать много параллельных соединений. Минус один-два запроса почти не заметен, если главный ресурс весит несколько мегабайт.
Минификация HTML и CSS даёт выигрыш, но не спасает страницу с тяжёлым видео в первом экране. Начинать с неё — значит тратить время на то, что не меняет ощущение от загрузки.
Оптимизация серверного кода важна, но только после того, как устранены явные проблемы на клиенте. Пока картинки не сжаты, ускорение бэкенда почти не видно в замерах.
Как проверять
Базовый набор доступен бесплатно: PageSpeed Insights, который показывает и лабораторные, и полевые данные, Lighthouse и вкладка Performance в Chrome DevTools, а также отчёты о скорости в системах аналитики, если они установлены на сайте.
Правила проверки простые: измеряйте на мобильном профиле с ограничением скорости, а не на быстром рабочем компьютере; сравнивайте одну и ту же страницу до и после изменений; делайте несколько прогонов, потому что одиночный замер всегда шумный.
- LCP: какой элемент считается главным и сколько он грузится
- CLS: не прыгает ли вёрстка при загрузке баннеров, шрифтов и изображений
- INP: реагирует ли интерфейс на нажатие без задержки
- Размер и формат изображений первого экрана
- Количество и вес сторонних скриптов
- Время ответа сервера и наличие кэширования
Сервер, кэш и сеть доставки
Скорость — это не только страница, но и путь до неё. Если сервер физически далеко от аудитории, каждый запрос тратит время на дорогу. Кэширование статики и сеть доставки контента сокращают этот путь, но не заменяют нормальную отдачу страницы.
Отдельно проверьте, что кэш настроен правильно: статические файлы отдаются с длительным сроком хранения, а страницы не кэшируются так, чтобы пользователь видел устаревшую цену или наличие. Ошибка в настройках кэша выглядит как «сайт показывает не то» и обычно всплывает уже после запуска.
Для сайта с формами и кабинетом важно, чтобы кэш не мешал персональным данным. Это решается разделением: общие страницы кэшируются, персональные блоки подгружаются отдельно. Решение принимают на этапе проектирования, а не после жалоб.
Порядок исправлений
Исправлять хаотично бессмысленно: эффект даёт последовательность. Сначала то, что человек видит в первую секунду, затем то, что влияет на взаимодействие, и только потом общая оптимизация кода и конфигурации.
После каждого шага нужен повторный замер на том же профиле и той же странице. Иначе невозможно понять, помогла правка или совпала со сторонним фактором вроде нагрузки на сервер.
- Сжать и правильно отдать изображения первого экрана, задать им размеры, чтобы не прыгала вёрстка
- Убрать или отложить сторонние скрипты, которые не нужны до первого взаимодействия
- Настроить кэширование статики и сжатие на сервере
- Разобраться со шрифтами: подмножество, формат, отображение до загрузки
- Разделить код: не грузить на главной то, что нужно только в личном кабинете
- Проверить метрики повторно и сравнить с исходными значениями
Как принимать работу по скорости
Скорость нужно зафиксировать до старта, иначе приёмка превращается в спор о вкусах. Формулировка «сайт должен быть быстрым» не проверяется. Проверяемая формулировка содержит метрику, конкретную страницу, профиль измерения и инструмент.
Замерять нужно на рабочем домене после запуска, а не на локальной машине разработчика: локально нет реальной сети, кэша и сторонних скриптов. Если показатели ухудшились после подключения аналитики или чата, это тоже часть работы, а не «внешний фактор».