Core Web Vitals простым языком: LCP, INP и CLS

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

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

Зачем вообще придумали три отдельные метрики

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

Три метрики Core Web Vitals разбивают ощущение от страницы на три вопроса:

1. Загрузка. Как быстро появился основной контент — LCP.
2. Отзывчивость. Как быстро страница реагирует на действия — INP.
3. Стабильность. Не прыгают ли элементы во время загрузки — CLS.

Каждая метрика оценивается по 75-му процентилю реальных визитов. Проще говоря, страница считается хорошей, если у трёх посетителей из четырёх показатель укладывается в норму. Это важная деталь: оптимизировать нужно не под свой мощный ноутбук в офисе, а под типичного посетителя со средним смартфоном и мобильным интернетом где-нибудь в пригороде Самары.

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

Largest Contentful Paint — время, за которое отрисовался самый крупный видимый элемент на первом экране. Обычно это главное изображение, баннер, фото товара или большой блок текста с заголовком.

Какие значения считаются нормальными

• до 2,5 секунды — хорошо;
• от 2,5 до 4 секунд — требует улучшения;
• больше 4 секунд — плохо.

Что чаще всего тормозит LCP

На практике причины повторяются от проекта к проекту:

• Тяжёлая картинка на первом экране. Фото в несколько мегабайт, загруженное прямо с фотоаппарата, без сжатия и без современных форматов.
• Ленивая загрузка не там, где нужно. Атрибут отложенной загрузки поставили на все изображения подряд, включая главный баннер, — и браузер начинает его качать последним.
• Медленный ответ сервера. Если сервер думает над страницей полторы секунды, уложиться в 2,5 секунды почти невозможно.
• Шрифты и стили, блокирующие отрисовку. Браузер ждёт, пока загрузятся все CSS-файлы и веб-шрифты, и только потом показывает текст.
• Слайдер на первом экране. Скрипт карусели грузится, инициализируется, и только после этого появляется первый слайд.

Как улучшать

Начните с определения, какой именно элемент браузер считает LCP на ключевых шаблонах: главной, категории, карточке, статье. Затем:

1. Сожмите это изображение и отдавайте его в формате WebP или AVIF с правильными размерами под мобильный экран.
2. Уберите с него отложенную загрузку и добавьте подсказку высокого приоритета.
3. Сократите время ответа сервера: кеширование страниц, нормальный хостинг, избавление от тяжёлых запросов к базе.
4. Встройте критичные стили прямо в страницу, а остальные подгружайте асинхронно.
5. Если на первом экране слайдер, подумайте, нужен ли он вообще. Статичный баннер почти всегда быстрее и, по нашим наблюдениям, не хуже по конверсии.

Для главного изображения в разметке должны быть: явно указанные ширина и высота, атрибут fetchpriority со значением high, путь к облегчённой версии для мобильных (например, /images/hero-mobile.webp) и осмысленный alt. А вот атрибута loading со значением lazy у него быть не должно — он уместен только для картинок ниже первого экрана.

INP: откликается ли страница

Interaction to Next Paint — метрика отзывчивости. Она измеряет задержку между действием пользователя (клик, тап, нажатие клавиши) и моментом, когда страница визуально отреагировала. Причём учитывается не первое действие, а почти самое медленное за всё время визита.

INP заменил старую метрику FID, которая смотрела только на первый клик и только на задержку до начала обработки. Новая метрика строже: она ловит ситуации, когда фильтр в каталоге «думает» полсекунды или меню открывается с заметной паузой.

Пороговые значения

• до 200 миллисекунд — хорошо;
• от 200 до 500 миллисекунд — требует улучшения;
• больше 500 миллисекунд — плохо.

Откуда берутся задержки

Главный враг INP — длинные задачи JavaScript. Пока браузер выполняет тяжёлый скрипт, он не может обработать нажатие. Типичные виновники:

• виджеты чатов, квизов и обратного звонка, которые вешают обработчики на всю страницу;
• несколько систем аналитики и пикселей, срабатывающих на каждый клик;
• фильтры каталога, которые при каждом изменении пересчитывают и перерисовывают сотни товаров;
• тяжёлые темы на конструкторах и CMS, где на каждую мелочь подключена отдельная библиотека.

Что делать

• Проведите ревизию сторонних скриптов. Часто половина из них осталась от старых рекламных кампаний и уже никому не нужна.
• Откладывайте загрузку второстепенных виджетов до момента, когда пользователь начал взаимодействовать со страницей или прокрутил её.
• Разбивайте тяжёлые обработчики на части, чтобы браузер успевал реагировать между ними.
• Давайте мгновенную визуальную обратную связь: сначала покажите, что кнопка нажата или фильтр применяется, а уже потом выполняйте расчёты.

У одного интернет-магазина сантехники мы убрали три забытых пикселя и перевели онлайн-чат на отложенную загрузку. INP на мобильных опустился с 480 до 190 миллисекунд без единой правки в основном коде сайта.

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

Cumulative Layout Shift показывает, насколько сильно элементы сдвигаются во время жизни страницы. Все знают это ощущение: начинаешь читать абзац, а он уезжает вниз, потому что сверху догрузилась реклама. Или целишься в «Оформить заказ», а попадаешь в «Удалить из корзины».

Пороговые значения

• до 0,1 — хорошо;
• от 0,1 до 0,25 — требует улучшения;
• больше 0,25 — плохо.

Это безразмерная величина: она учитывает, какую долю экрана занимал сдвинувшийся элемент и на какое расстояние он переместился.

Типичные причины сдвигов

• изображения и видео без заданных ширины и высоты;
• баннеры, плашки о cookie и всплывающие полосы, которые вставляются в начало страницы после загрузки;
• веб-шрифты, при подмене которых меняется ширина строк и текст перестраивается;
• блоки, подгружаемые скриптом: отзывы, виджеты карт, рекомендации.

Как исправить

1. Всегда указывайте размеры изображений или задавайте блокам соотношение сторон в CSS.
2. Резервируйте место под динамические блоки заранее — пусть это будет пустая область нужной высоты.
3. Плашку о cookie выводите поверх контента, а не сдвигая его.
4. Подбирайте резервный системный шрифт, близкий по метрикам к фирменному, или используйте настройки, выравнивающие размеры шрифтов.

Где смотреть данные: лаборатория против реальности

Одна из главных путаниц — разница между лабораторными и полевыми данными. Лабораторный тест запускается на эмулированном устройстве в идеальных условиях. Полевые данные собираются у реальных пользователей браузера Chrome за последние 28 дней.

Источник	Тип данных	Для чего подходит	Ограничения
PageSpeed Insights, блок с реальными данными	Полевые	Понять, как сайт видят посетители	Нужен достаточный трафик, иначе данных нет
PageSpeed Insights, лабораторная часть	Лабораторные	Найти конкретные причины и проверить правки	Одна загрузка, одна модель устройства
Отчёт «Основные интернет-показатели» в Search Console	Полевые	Увидеть проблемные группы страниц	Обновляется с задержкой
Инструменты разработчика в браузере	Лабораторные	Отладка конкретного шаблона	Ваше устройство не равно устройству клиента
Собственный сбор метрик на сайте	Полевые	Точная картина по всем посетителям	Нужна настройка скрипта и хранения

Правило простое: ориентироваться на полевые данные, а лабораторные использовать как микроскоп для поиска причин. Если в лаборатории всё зелёное, а в Search Console группа страниц помечена как медленная, верить стоит Search Console.

Отчёты Search Console полезно просматривать регулярно вместе с остальными показателями — как это встроить в рабочую рутину, мы описали в материале про Яндекс Вебмастер и Google Search Console.

Как метрики влияют на позиции

Core Web Vitals входят в набор сигналов удобства страницы в Google. Но важно не переоценивать их вес. Хороший LCP не вытащит в топ страницу, которая не отвечает на запрос. Зато при прочих равных быстрый и стабильный сайт получает преимущество — и, что важнее, лучше конвертирует.

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

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

Порядок работ: с чего начать на реальном проекте

Когда клиент приходит с жалобой «PageSpeed всё красное», мы действуем по одной и той же схеме.

1. Смотрим полевые данные по группам страниц. Обычно проблема не во всём сайте, а в одном-двух шаблонах, например в карточке товара или в статьях блога.
2. Выбираем шаблоны с наибольшим трафиком. Ускорение карточки товара, куда приходит 70 % посетителей, даёт больше, чем полировка страницы «О компании».
3. Определяем, какая метрика хуже всего. Если провален только CLS, не нужно переписывать сервер — достаточно поправить вёрстку.
4. Делаем правки небольшими порциями. Так видно, что сработало, а что нет.
5. Ждём обновления полевых данных. Из-за 28-дневного окна результат в отчётах проявляется постепенно, это нормально.

Для стоматологии в Промышленном районе такая схема заняла около трёх недель: сжали фото врачей на главной, убрали слайдер, отложили загрузку онлайн-записи и задали размеры всем изображениям. Все три метрики на мобильных перешли в зелёную зону, а доля отказов по мобильному трафику заметно снизилась.

Если хочется получить список проблем по всему сайту сразу, а не по одной странице, закажите технический аудит — в нём скорость и Core Web Vitals разбираются по каждому шаблону.

Частые заблуждения

• «Нужно 100 баллов в PageSpeed». Балл — это лабораторная оценка, а не Core Web Vitals. Сайт с оценкой 70 может проходить все три метрики, а сайт с 95 — проваливать INP у реальных людей.
• «Мы на хорошем хостинге, значит всё быстро». Хостинг влияет только на время ответа сервера. Тяжёлые картинки и скрипты он не исправит.
• «Проверили один раз — и забыли». Каждый новый виджет, баннер или счётчик может откатить метрики назад. Проверка нужна после каждого заметного изменения.
• «Для десктопа всё хорошо, этого достаточно». Google индексирует и оценивает прежде всего мобильную версию, а там условия намного жёстче.

Выводы

Core Web Vitals — это три понятных вопроса о странице: быстро ли показалось главное, реагирует ли она на нажатия и не прыгает ли под рукой. Чтобы работать с ними осознанно:

• ориентируйтесь на полевые данные и 75-й процентиль, а не на балл PageSpeed;
• начинайте с самых посещаемых шаблонов и самой проблемной метрики;
• для LCP оптимизируйте главный элемент первого экрана и ответ сервера;
• для INP чистите и откладывайте сторонние скрипты;
• для CLS задавайте размеры всем медиаблокам и резервируйте место под динамику;
• перепроверяйте метрики после каждого значимого изменения на сайте.

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