Core Web Vitals: LCP, INP, CLS

Core Web Vitals — это три показателя реального пользовательского опыта на странице, которые определяет Google: LCP (скорость появления главного содержимого), INP (скорость реакции на действия) и CLS (прыжки элементов во время загрузки). Хорошие значения: LCP до 2,5 секунды, INP до 200 миллисекунд, CLS до 0,1.

Простыми словами

• LCP (Largest Contentful Paint) — за какое время появляется самый большой элемент экрана. В карточке товара это обычно главное фото. Ориентир Google: до 2,5 с от начала загрузки.
• INP (Interaction to Next Paint) — как быстро страница реагирует на клик или касание: добавить в корзину, выбрать размер, открыть фильтр. Ориентир: до 200 мс.
• CLS (Cumulative Layout Shift) — не «прыгает» ли страница, пока грузится. Классическая беда: кнопка «Купить» смещается в момент нажатия, потому что выше подгрузился баннер. Ориентир: до 0,1.

Источник порогов: Google, Core Web Vitals и web.dev. Страница считается хорошей, если все три показателя укладываются в норму для 75-го перцентиля загрузок отдельно для мобильных и десктопов (web.dev). То есть норму должен выполнять не средний, а три из четырёх реальных визитов.

INP стал стабильным показателем в 2024 году и заменил FID. Страница web.dev с этими порогами последний раз обновлялась 31 октября 2024 года; стабильные показатели, по её словам, меняют не чаще раза в год.

Как измеряют: полевые и лабораторные данные

Главными являются полевые данные — измерения на настоящих устройствах посетителей: отчёт Core Web Vitals в Search Console, PageSpeed Insights, Chrome User Experience Report. Лабораторные (Lighthouse) полезны, чтобы найти причину и проверить исправление, но не заменяют полевые; INP в лаборатории измерить невозможно, потому что нет действий пользователя, Lighthouse использует заменитель TBT (web.dev).

Для украинского магазина это значит: посмотрите отчёт в Search Console именно для мобильных, потому что большая часть трафика идёт со смартфонов (см. Мобильный UX).

Как дела в сети в целом

По Web Almanac 2025 от HTTP Archive (данные CrUX за июль 2025): все три показателя в норме имели 48% мобильных и 56% десктопных сайтов (в 2024 на мобильных было 44%). Отдельно на мобильных: LCP в норме у 62%, INP у 77%, CLS у 81% сайтов. Самое слабое место — LCP. Главное фото было LCP-элементом на 76% мобильных страниц. На 16–17% страниц главное фото грузится отложенно (lazy loading), хотя это замедляет его появление; `fetchpriority="high"` стоял лишь у 17% мобильных и 16% десктопных таких изображений (Web Almanac 2025).

Практический вывод для магазина: первое фото товара не следует грузить отложенно; остальные фото ниже первого экрана можно.

Влияет ли на позиции

Google пишет: Core Web Vitals используются системами ранжирования, и Google советует стремиться к хорошим значениям. При этом хорошие оценки не гарантируют высоких позиций; релевантность важнее («Google всегда стремится показать самое релевантное содержимое, даже если опыт страницы не лучший»); гнаться за идеальным результатом только ради SEO, возможно, не стоит (Google, page experience). Сильнее скорость помогает, когда много одинаково полезных страниц конкурируют за один запрос (там же).

Влияет ли на продажи

Здесь доказательств меньше, чем обещают в агентствах. Самый известный пример на web.dev: Rakuten 24. На одной странице за месяц A/B-тест показал прирост выручки на посетителя на 53,37% и конверсии на 33,13%, когда её оптимизировали по Core Web Vitals. Ограничения самого кейса: одна страница, один месяц, пишут собственные разработчики, нет абсолютных значений и статистической значимости; в кейсе не указана дата публикации (web.dev, Rakuten 24). Это пример того, что скорость может влиять на продажи, а не гарантированная цифра. Украинских исследований с открытыми цифрами нет.

Практическое правило: измеряйте на своём магазине. Возьмите страницы с плохими показателями, исправьте и сравните конверсию на A/B-тесте (A/B-тест). То, что Rakuten изменил в кейсе, полезно как перечень идей: убрал блокирующие рендер скрипты, сжал и подобрал размеры изображений, отложил загрузку того, что ниже первого экрана, зарезервировал место под изображения через `aspect-ratio` и `min-height`, чтобы не было сдвигов.

Типичные причины плохих показателей в магазине

• LCP: тяжёлое главное фото без сжатия; оно загружается отложенно; медленный сервер; блокирующие скрипты.
• INP: тяжёлый JavaScript (виджеты чата, аналитика, слайдеры), который занят, когда человек нажимает на кнопку.
• CLS: изображения без заданных размеров; баннеры и виджеты, подгружающиеся сверху; шрифты, меняющие размеры.

Типичные ошибки

• Смотреть только на оценку в лабораторном тесте, а не на реальных пользователей.
• Гнаться за 100 баллами, игнорируя три пороговых значения.
• Исправлять главную страницу, оставляя карточки товаров и категории. В Web Almanac 2025 именно главные страницы были хуже внутренних: в норме 45% мобильных главных против 56% внутренних страниц.
• Ожидать скачка позиций: Google прямо говорит, что релевантность важнее.

FAQ

Что такое Core Web Vitals? Три показателя скорости и стабильности страницы: LCP, INP, CLS.

Каковы нормы Core Web Vitals? LCP до 2,5 с, INP до 200 мс, CLS до 0,1 для 75% посещений.

Влияют ли Core Web Vitals на ранжирование? Да, Google их использует, но они не гарантируют топ и уступают релевантности.

Влияют ли они на конверсию? Есть отдельные кейсы с ростом (Rakuten 24), но с ограничениями. Для вашего магазина проверяйте тестом.

Что такое INP и чем он заменил FID? INP измеряет скорость реакции на все действия на странице, а не только на первое. В 2024 году он заменил FID.

Связанные термины

• Технический аудит сайта
• SEO-аудит интернет-магазина
• Мобильная версия магазина
• Конверсия (conversion rate)
• A/B-тест

Источники

• Google Search Central, Core Web Vitals — developers.google.com/search/docs/appearance/core-web-vitals
• Google Search Central, Understanding page experience — developers.google.com/search/docs/appearance/page-experience
• web.dev, Web Vitals — web.dev/articles/vitals
• HTTP Archive, Web Almanac 2025: Performance — almanac.httparchive.org/en/2025/performance
• web.dev, Rakuten 24 case study — web.dev/case-studies/rakuten