Core Web Vitals: как скорость сайта влияет на заявки

Core Web Vitals — набор из трёх метрик, которыми измеряют не абстрактную «скорость», а конкретные ощущения пользователя: долго ли ждать, отзывчиво ли, не прыгает ли содержимое под пальцем.

Три метрики

LCP — когда появилось главное

Время до отрисовки самого крупного элемента в видимой части: обычно заглавной картинки или заголовка. Отвечает на вопрос «когда стало видно, куда я попал».

Хорошо — до 2,5 секунды. Плохо — больше 4.

Чаще всего портится тяжёлыми изображениями, медленным сервером и шрифтами, которые блокируют отрисовку.

INP — насколько отзывчива страница

Задержка между действием пользователя и видимой реакцией. Заменил прежнюю метрику FID и стал строже: учитывается не первое взаимодействие, а все.

Хорошо — до 200 миллисекунд. Плохо — больше 500.

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

CLS — прыгает ли вёрстка

Насколько содержимое смещается во время загрузки. Знакомое ощущение: собираетесь нажать кнопку, в этот момент подгрузился баннер, всё уехало, и нажатие пришлось на другое.

Хорошо — до 0,1. Плохо — больше 0,25.

Портится изображениями без указанных размеров, шрифтами, подменяющими друг друга, и баннерами, которые вставляются после загрузки.

Почему это деньги, а не техническая гигиена

Две причины.

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

Поведение. Это важнее. Медленный сайт теряет посетителей до того, как они увидели предложение. Особенно жёстко это работает на мобильном трафике из рекламы: человек пришёл по объявлению, ждёт три секунды и возвращается в выдачу — а клик уже оплачен.

Как измерить свой сайт

Два вида данных, и путать их не стоит.

Лабораторные — замер в контролируемых условиях. Инструмент вроде PageSpeed Insights или встроенная в браузер вкладка Lighthouse. Удобны для поиска причин: показывают, что именно тормозит.

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

Ориентируйтесь на полевые. Лабораторные используйте, чтобы понять причину.

Что чинить в первую очередь

По убыванию отдачи на вложенные усилия:

1. Изображения. Самая частая и самая простая победа. Современные форматы, правильные размеры под устройство, отложенная загрузка того, что ниже экрана. Часто даёт больше, чем всё остальное вместе.
2. Сторонние скрипты. Чаты, счётчики, виджеты, пиксели. Проверьте список — на живом сайте за годы накапливаются скрипты, которые уже никому не нужны, но грузятся.
3. Шрифты. Подгружайте заранее, задавайте поведение при загрузке, не подключайте начертания, которые не используются.
4. Ответ сервера. Если сервер отдаёт документ дольше 600 мс, дальнейшая оптимизация бессмысленна: вы экономите миллисекунды поверх потерянной секунды.
5. Объём JavaScript. Самая трудоёмкая часть, требующая работы с кодом. Берётесь за неё последней.

Здравый смысл

Сто баллов из ста — не цель. Гнаться за последними баллами дорого, а разницы пользователь не почувствует.

Разумная цель — попасть в «хорошо» по всем трём метрикам на мобильных, по полевым данным. Этого достаточно, чтобы скорость перестала быть проблемой, а дальше усилия выгоднее вкладывать в содержание и удобство.