Скорость загрузки сайта: проверка и что ускорять

Вопрос «какая у сайта скорость» не имеет одного ответа. Есть время до первого байта, время до появления главного изображения, время до момента, когда страница начинает отвечать на нажатия. Это разные числа, и ускоряются они разными средствами.

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

Лабораторные и полевые данные

Лабораторный замер — один прогон в контролируемых условиях: заданный канал, заданное устройство, чистый профиль без расширений. Так работают Lighthouse в браузере и лабораторная часть PageSpeed Insights. Плюс — воспроизводимость: можно сравнить «до» и «после». Минус — это не ваши пользователи.

Полевые данные собираются с реальных посещений: разные устройства, сети, регионы, кэш. Их показывают отчёт Chrome UX Report в PageSpeed и собственный отчёт о скорости в Яндекс Метрике. Здесь нет воспроизводимости, зато есть правда о том, что видят люди.

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

Core Web Vitals

Три метрики, к которым сведено большинство разговоров о скорости.

• LCP — время отрисовки самого крупного элемента первого экрана, обычно картинки или заголовка. Хорошо — до 2,5 секунды.
• INP — задержка отклика на действия человека: нажатие, ввод, раскрытие меню. Хорошо — до 200 миллисекунд. Эта метрика заменила прежний FID и оценивает не первое взаимодействие, а все.
• CLS — суммарный сдвиг вёрстки: насколько содержимое прыгает во время загрузки. Хорошо — до 0,1.

Оценку дают по 75-му перцентилю за окно около месяца. Значит, улучшения появляются в отчётах с задержкой. И значит, на среднее смотреть бессмысленно: оно прячет ровно ту четверть посещений, из-за которой страница считается медленной.

Балл PageSpeed из ста — производная величина, взвешенная сумма лабораторных метрик. Он удобен для разговора с руководством и плохо годится как цель.

Как мерить, чтобы не обмануться

Большую часть ложных выводов убирают четыре привычки. Мерьте мобильную версию: основная аудитория почти всегда там, а разрыв с десктопом кратный. Делайте три-пять прогонов и берите медиану — соседние замеры расходятся заметно. Проверяйте не главную, а типовую страницу: карточку товара, статью, оформление заказа. И смотрите «холодный» заход, без кэша.

И сравнивайте себя с собой во времени, а не с конкурентом в один день: у него может идти акция с лишними скриптами, и сравнение ничего не скажет.

Что даёт основной выигрыш

Список рекомендаций в отчёте длинный, но по опыту почти весь выигрыш дают четыре вещи.

Изображения. Самая частая причина медленного LCP — фотография первого экрана на полтора-два мегабайта. Она же чинится быстрее всего. Современный формат, реальный размер вместо исходника с фотоаппарата, явные width и height в разметке, отложенная загрузка для всего, что ниже первого экрана. Одна фотография, ужатая с 2 МБ до 200 КБ, на мобильном соединении экономит секунды, а не проценты.

Сторонние скрипты. Счётчики, чаты, пиксели рекламных систем, виджеты — основной источник плохого INP. Каждый из них выполняет свой код в том же потоке, что и ваша страница. Лечение: атрибут async или defer, загрузка по действию (чат подключается по нажатию кнопки) и честная ревизия. В списке почти всегда находится пара скриптов, о которых никто уже не помнит, зачем они.

Шрифты. Невидимый текст во время загрузки шрифта и последующий скачок вёрстки — типовая пара проблем. Свойство font-display: swap, предзагрузка основного начертания и отказ от шести начертаний в пользу двух решают её почти полностью.

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

Чем опасны оптимизации ради балла

Отчёт легко превратить в цель и сделать страницу хуже для человека, подняв при этом число.

• Отложенная загрузка главной картинки первого экрана. Балл за «оптимизацию изображений» растёт, LCP ухудшается — картинка начинает грузиться позже.
• Отложенный CSS ради устранения блокирующих ресурсов: страница показывается неоформленной и потом перестраивается, CLS портится.
• Скрытие содержимого до полной загрузки: метрики выглядят хорошо, человек смотрит на белый экран дольше.
• Удаление аналитики ради баллов. Скорость выросла, измерять эффект больше нечем.
• Дробление кода на десятки мелких файлов: в отчёте меньше «неиспользуемого JavaScript», на деле — лишние запросы.

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

Окупается ли ускорение

Отраслевые исследования связи скорости с конверсией существуют, но переносить чужие проценты на свой сайт не стоит: эффект зависит от аудитории, устройств и типа покупки. Надёжнее измерить у себя. Сравните конверсию до и после ускорения на сопоставимых периодах и проверьте, отличается ли разница от шума, в калькуляторе A/B-тестов. Где именно теряются люди по шагам, покажет калькулятор воронки.

Честная оговорка: если конверсия падает из-за непонятной формы или отсутствия нужной информации, ускорение страницы с 3 до 2 секунд не спасёт. Скорость — необходимое условие, а не причина покупки.

И про виджеты

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