Три числа, которые решают судьбу вашего сайта. Скорее всего, вы исправляете не то

Сайт грузится за 1,2 секунды на MacBook — и кажется, что всё хорошо. Но для пользователя на среднем Android в автобусе с одной полоской сигнала это слайд-шоу. Google измеряет скорость глазами реальных людей, и учитывает три метрики, которые определяют поведение аудитории.

Идеальная оценка в Lighthouse ничего не значит, если три четверти реальных пользователей видят красные цифры.

Что измеряет Google и почему это важно

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

LCP (Largest Contentful Paint) — время до появления основного контента. Это первое впечатление: сколько ждать, пока страница станет хоть сколько-то полезной.

INP (Interaction to Next Paint) — скорость реакции страницы на нажатие. Это рукопожатие: ткнул пользователь в кнопку — и сколько ждать, пока что-то произойдёт.

CLS (Cumulative Layout Shift) — насколько прыгает вёрстка при загрузке. Это тот момент, когда палец летит по кнопке «купить», а кнопка телепортируется под рекламный баннер.

Все три метрики измеряются не в лаборатории, а на реальных пользователях — на 75-м процентиле, сгруппированных по шаблонам страниц. Если три четверти вашей аудитории получают плохой опыт, никакие идеальные показатели на тестовом MacBook этого не компенсируют.

Главная ошибка: приоритет LCP

Разработчики чаще всего начинают исправления с LCP. Логика понятна: это число хорошо видно в DevTools, его легко измерить, легко объяснить заказчику. Проблема в том, что LCP — во многом лабораторная метрика. Она отражает условия «идеального» подключения, мощного устройства, кэшированного DNS.

А вот INP — это полевая метрика. Она проявляется только тогда, когда реальный человек касается экрана реального телефона. В лабораторных условиях её поймать практически невозможно. Команды запускают Lighthouse, получают заветные 100 баллов, отмечают — а потом удивляются, почему показатель отказов на мобильных напоминает статистику с места происшествия.

Пользователь на среднем Android с нестабильным интернетом — это не крайний случай, это основная аудитория большинства сайтов в мире. И Google это прекрасно понимает: алгоритм оценивает именно «автобус», а не ваш MacBook.

CLS: дёшево, быстро и повсеместно игнорируется

Из трёх метрик CLS — самая дешёвая в исправлении и при этом самая запущенная. Сдвиг макета — это не просто косметическое неудобство. Это прямая причина случайных кликов по рекламе или кнопкам, которых пользователь не собирался нажимать. Это утрата доверия к сайту. И это потери в конверсии, которые остаются долго после того, как человек забыл, почему именно его раздражала страница.

Типичные причины CLS — отсутствие явных размеров у изображений и встраиваемых элементов, рекламные блоки, которые загружаются после основного контента, динамические элементы, появляющиеся «above the fold» после начальной отрисовки.

Практический порядок исправлений

Не каждый дефект требует одинаковых усилий. Вот порядок, который реально работает:

1. Откройте Google Search Console, раздел Core Web Vitals. Сортируйте не по отдельным страницам, а по группам URL. Если одна страница шаблона работает плохо — проблема во всём шаблоне. Чините шаблон, а не каждую страницу отдельно.

2. Исправляйте CLS первым. Пропишите ширину и высоту для каждого изображения и каждого встраиваемого элемента. Зарезервируйте место под рекламные блоки и динамические компоненты. Не вставляйте контент выше видимой области после загрузки страницы. В типичном случае это исправляется за один рабочий день.

3. Затем — LCP. Предзагружайте главное изображение (hero image). Уберите скрипты, блокирующие рендеринг. Проверьте, что CDN не просто подключён, а реально отдаёт кэшированный контент.

4. Последним и дольше всего — INP. Это проблема основного потока исполнения, то есть проблема JavaScript. Длинные задачи нужно разбивать на фрагменты не более 50 мс. Некритичные обработчики событий — откладывать. И тестировать throttled CPU, а не мощность вашего рабочего компьютера.

Почему это касается мобильного трафика

Категория «Телефоны» здесь не случайна. Именно на мобильных устройствах Core Web Vitals проявляются острее всего. Процессор среднего смартфона слабее десктопного в разы. Мобильная сеть нестабильна. Экран меньше — и любой сдвиг макета, любой лаг при касании ощущается болезненнее.

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

Что в итоге

Core Web Vitals — не абстрактные цифры для отчётов. Это инструмент, который напрямую влияет на ранжирование в поиске и на реальное поведение аудитории. Причём наибольший эффект при минимальных затратах даёт исправление той метрики, которую большинство команд игнорирует — CLS. А самая неприятная ловушка — ориентироваться на Lighthouse-скор на мощном устройстве, забывая про реальных пользователей с реальными ограничениями.