Core Web Vitals — это три показателя, по которым оценивают удобство страницы для посетителя: скорость загрузки основного содержимого, отзывчивость на действия и стабильность вёрстки. Все три измеряются на реальных устройствах посетителей, а не на тестовом стенде.
Три метрики: что означает каждая
LCP — скорость появления главного
LCP показывает, за какое время на экране появляется основной элемент страницы: крупное изображение, заголовок, блок с товаром. Это не «время загрузки сайта» целиком, а момент, когда посетитель видит то, за чем пришёл. Если это происходит позже, человек успевает уйти.
INP — отзывчивость на действие
INP измеряет, как быстро страница отвечает на то, что делает посетитель: нажатие кнопки, выбор фильтра, отправку формы. Метрика отвечает на вопрос, «залипает» ли интерфейс. Проблема обычно не в сервере, а в скриптах, которые выполняются в браузере.
CLS — стабильность вёрстки
CLS показывает, насколько сильно элементы смещаются во время загрузки. Классический случай — когда баннер или картинка без указанных размеров подгружаются позже и сдвигают текст вниз, а посетитель в этот момент нажимает не туда, куда целился.
Пороговые значения: где проходит граница
У каждой метрики есть три зоны: «хорошо», «нужно улучшить» и «плохо». Ориентиры, на которые опираются поисковые системы, такие: LCP — до 2,5 секунды, INP — до 200 миллисекунд, CLS — до 0,1. Значения из средней зоны не наказывают напрямую, но означают, что часть посетителей уже уходит, не дождавшись страницы.
Важная деталь: показатель считается по совокупности посещений, а не по одному удачному замеру. Поэтому фраза «у меня на компьютере всё открывается быстро» ничего не доказывает — оценка строится на том, что пережило большинство людей, включая медленные устройства и слабую связь. Обратная сторона: после правок полевая оценка обновляется постепенно, ведь она собирается из новых визитов, — улучшение видно не на следующий день.
Гнаться за идеальными цифрами при этом не нужно. Если показатели в зелёной зоне, дальнейшие усилия дают меньше отдачи, чем те же часы, вложенные в релевантность страницы под запрос.
Лабораторные замеры и реальные данные
Один и тот же сайт на быстром компьютере и на телефоне в метро показывает разные цифры. Поэтому метрики разделяют на лабораторные и полевые.
Лабораторные замеры делает инструмент на заданных условиях: они воспроизводимы и удобны для отладки, но не отражают реальных устройств. Полевые данные собираются с посетителей сайта за месяц — это то, что видит поисковая система. Если лабораторные цифры хорошие, а полевые плохие, значит проблема на конкретных устройствах или в конкретных регионах, и разбираться нужно там.
Влияют ли метрики на позиции напрямую
Это не главный фактор ранжирования: релевантность запросу остаётся важнее. Но удобство влияет косвенно и сильно: посетители, у которых страница «тормозит», возвращаются в выдачу и выбирают другой сайт, а поведение учитывается алгоритмами. На практике медленный сайт проигрывает конкуренту при прочих равных.
Отдельная причина заниматься метриками — они влияют на конверсию, а не только на видимость. Быстрая страница даёт больше заявок при том же трафике, и это измеримый эффект, который виден в отчётах сразу, без ожидания пересчёта позиций.
Что чаще всего портит показатели
- Изображения без оптимизации. Фотографии, выгруженные прямо из камеры, весят в разы больше, чем нужно для экрана.
- Сторонние скрипты. Виджеты, чаты и счётчики подключают чужие скрипты, которые грузятся с внешних серверов.
- Элементы без размеров. Картинки и баннеры без указанной высоты сдвигают текст при загрузке.
- Раздутый CSS и JS. Подключаются все стили темы и плагинов даже там, где нужна десятая часть.
- Отсутствие кэширования. Каждый переход собирает страницу заново запросами к базе.
Типичные ошибки при работе с метриками
- Ориентироваться только на лабораторный замер. Инструмент показывает, как страница грузится в заданных условиях, а не как её видят посетители. Хорошая оценка в отчёте и жалобы людей на «тормозит» спокойно уживаются: причина в устройстве, регионе или качестве связи.
- Улучшать цифры в ущерб человеку. Классический пример — показывать текст только после загрузки всех скриптов. Формально метрики подтягиваются, а посетитель получает пустой экран и уходит.
- Замерять одну главную. Люди приходят из поиска на страницы услуг, товаров и статей. Проблемы чаще живут именно там — из-за тяжёлых галерей, карт, форм и виджетов.
- Ставить оптимизацию «пакетом». Плагины кэширования, сжатия и «ускорения» конфликтуют между собой и с темой. Правки вносят по одной и проверяют результат — иначе непонятно, что помогло, а что сломало вёрстку.
- Не смотреть мобильные отдельно. На телефоне медленнее процессор и нестабильнее связь, поэтому именно там показатели чаще всего выходят из нормы.
- Замерить один раз и забыть. Новый виджет, баннер или плагин откатывает показатели назад, и без контроля регресс накапливается незаметно.
Как проверить себя: чек-лист
- Полевые данные по мобильным и компьютерам смотрите раздельно: усреднённая цифра скрывает проблему одной из групп.
- Берите не весь сайт, а страницы с трафиком — те, куда приходят из поиска и рекламы.
- Проверьте INP на реальных действиях: открыть фильтр, отправить форму, переключить вкладку. Для этого достаточно пройти путь клиента на телефоне.
- Перед правками зафиксируйте замер, после — повторите в тех же условиях. Иначе улучшение нечем подтвердить.
- Сверьте лабораторный замер с полевыми данными по одним и тем же страницам: расхождение показывает, что дело в реальных устройствах и связи, а не в настройках сервера.
- Раз в месяц просматривайте полевые данные по группам страниц: так регресс видно раньше, чем он отразится на трафике и конверсии.
Часть правок не требует разработчика: сжать изображения, вернуть им размеры, убрать лишние виджеты — задачи уровня контент-менеджера. Системный контроль удобнее держать в рамках технической поддержки сайта: скорость проверяется вместе с обновлениями, а не отдельным разовым замером.
С чего начинать
Начинать стоит с полевых данных, а не с лабораторной оценки: сначала смотрят, какие именно страницы и на каких устройствах не укладываются в норму. Дальше правки идут по порядку — вес изображений, внешние скрипты, кэширование, размеры элементов. Такой порядок даёт результат быстро, без переписывания сайта.
Проверить текущее состояние можно по шагам из материала Скорость сайта: 10 проверок. Если сайт работает на конкретной платформе, у неё есть свои особенности: для WordPress это разбор SEO на WordPress, для Битрикса — SEO на 1С-Битрикс, включая композитный кэш.
Частые вопросы
Нужно ли гнаться за идеальными показателями
Нет. Ориентир — попадание в «зелёную» зону и отсутствие регресса: важнее не абсолютная цифра, а то, что показатели не ухудшаются после обновлений и новых блоков на странице.
Как часто нужно замерять
Полевые данные обновляются постепенно — ориентироваться на них раз в месяц достаточно. Замерять вручную после каждой правки не нужно, но при крупных изменениях (новый шаблон, подключённый сервис) проверка обязательна.
Метрики одинаковы для мобильных и компьютеров
Нормы одни, но реальные показатели различаются: на телефоне медленнее процессор и нестабильнее связь. Если полевые данные плохие только на мобильных, искать причину нужно в мобильной версии.
Поможет ли смена хостинга
Иногда, но это последний шаг. Чаще причина в настройках, весе страницы и скриптах — их исправление даёт больше, чем переезд на более мощный сервер.
Влияют ли метрики на индексацию
Нет, страницы с плохими показателями не выпадают из индекса. Речь о другом: неудобная страница хуже удерживает посетителя, а это сказывается и на поведенческих факторах, и на конверсии.
Что делать, если сайт на готовом конструкторе
Контроль ограничен: часть настроек платформа не отдаёт. Сначала используют то, что доступно, — изображения, внешние скрипты, кэш. Если возможностей платформы не хватает, это повод считать смену платформы отдельным проектом, а не «оптимизацией».