Core Web Vitals простыми словами: что измеряют Google и Яндекс

Core Web Vitals это три метрики: LCP отвечает за скорость появления главного блока, зелёный порог 2,5 секунды; CLS за прыжки вёрстки, порог 0,1; INP за отклик на действие, порог 200 миллисекунд. INP заменил FID в марте 2024 года.

Core Web Vitals часто упоминают в чек-листах SEO-агентств, но владельцу сайта от этого не легче. Цифры есть, баллов мало, что чинить, неясно. В этой статье разберу три ключевые метрики простыми словами, без формул и без терминов из спецификации W3C. После прочтения вы будете понимать, на что смотрит Google в 2026 году, чем от него отличается Яндекс и какие пороги действительно важны вашему сайту, а какие можно отложить.

Я не буду тащить вас в режим маньяка-перфекциониста. Цель: чтобы при следующем письме от подрядчика «у вас плохой LCP» вы могли спокойно ответить, на каком экране, на каком устройстве и почему именно сейчас это критично.

Что такое Core Web Vitals и зачем они нужны

Core Web Vitals (русский перевод не прижился, говорят как есть) — это набор технических показателей, которыми Google измеряет качество загрузки и взаимодействия со страницей с точки зрения реального пользователя. В 2020 году Google вычленил три метрики из десятков существующих и сказал: вот это самое главное, на это смотрим в поиске.

С тех пор состав менялся. В марте 2024 года FID окончательно сменил INP. Сегодня в 2026 году в группе три метрики:

• LCP (Largest Contentful Paint) — когда видно главное.
• CLS (Cumulative Layout Shift) — насколько прыгает вёрстка.
• INP (Interaction to Next Paint) — как быстро сайт реагирует на клик или тап.

Зачем это владельцу сайта. Во-первых, Google официально учитывает Core Web Vitals в ранжировании. Влияние не катастрофическое, но при равных прочих условиях быстрый сайт побеждает медленный. Во-вторых, плохие метрики коррелируют с отказами: пользователь не дождался, ушёл, конверсия просела. Если у вас за квартал упал трафик и одновременно ухудшился LCP, скорее всего это связано.

Яндекс прямо не использует Core Web Vitals в ранжировании, но смотрит на ИКС, поведенческие, время до клика. Косвенно те же причины, что портят CWV, портят и поведенческие в Яндексе. Чинить надо в любом случае.

Lab data против field data

Когда вы запускаете PageSpeed Insights, в отчёте две колонки. Слева цифры из реальных пользователей за последние 28 дней (field data, его же называют CrUX). Справа симулированный замер прямо сейчас на машине Google (lab data).

Для ранжирования важны только реальные данные. Если в lab у вас 95 баллов, а в field LCP 4 секунды, то Google смотрит на 4 секунды. Lab нужен для отладки: его можно гонять перед каждым деплоем и видеть тренд. Field подъезжает с задержкой и инертно реагирует на изменения, поэтому после правок надо ждать пару недель, а потом оценивать.

LCP простыми словами

LCP отвечает на вопрос: когда пользователь увидел самое большое содержимое страницы. Это может быть hero-картинка на главной, заголовок статьи, первый абзац текста, видео-постер. Браузер сам определяет, что считать «главным» по площади видимой области.

Порог Google на 2026 год не изменился. Хорошо: до 2,5 секунды. Требует улучшения: до 4 секунд. Плохо: больше 4 секунд. Замер ведётся по 75-му перцентилю реальных пользователей. То есть если у трёх четвертей ваших посетителей LCP меньше 2,5 секунды, метрика зелёная.

Что чаще всего ломает LCP:

1. Тяжёлая hero-картинка без сжатия и без современного формата.
2. Шрифты с CDN, которые блокируют рендер.
3. JS-фреймворк, который не отдаёт контент пока не отработал бандл.
4. Медленный TTFB (хостинг тупит до того, как HTML вообще полетел в браузер).
5. Lazy-loading на той самой картинке, которую браузер должен был показать первой.

Пятый пункт особенно обидный. Я регулярно вижу, как разработчики из лучших побуждений ставят loading="lazy" на все картинки подряд, включая hero. Браузер честно ждёт скролла перед загрузкой главной картинки. LCP уезжает за 5 секунд. Лечится снятием атрибута и добавлением fetchpriority="high":

<img
  src="/img/hero.webp"
  width="1200"
  height="600"
  alt="Главная картинка"
  fetchpriority="high"
/>

Где посмотреть свой LCP

Несколько способов:

• PageSpeed Insights — вбили URL, получили картину. Field data, если её достаточно, плюс lab.
• Chrome DevTools — вкладка Performance, запись загрузки, в timeline видно отметку LCP с миниатюрой того самого элемента.
• Search Console — раздел Core Web Vitals, агрегированные данные по всему сайту с разбивкой по типам страниц.
• Web Vitals Extension — расширение для Chrome, показывает три метрики в углу прямо при сёрфинге.

Я обычно начинаю с PageSpeed для конкретной страницы, потом ныряю в DevTools. Search Console использую раз в месяц для общей картины.

CLS простыми словами

CLS отвечает на вопрос: насколько сильно скакала вёрстка пока страница загружалась. Это про ситуации, когда вы целитесь в кнопку, а в последний момент над ней подгружается баннер, и вы попадаете в баннер. Раздражение, отказ, минус к доверию.

Метрика безразмерная. Хорошо: до 0,1. Требует улучшения: до 0,25. Плохо: больше 0,25. Считается сумма всех визуальных сдвигов взвешенная по площади. Один большой сдвиг на 70 процентов экрана даст 0,7, что катастрофа. Десять крошечных по 0,01 дадут те же 0,1, что граница нормы.

Главные причины плохого CLS:

• Картинки без явных width и height атрибутов (или CSS-аналогов с aspect-ratio).
• Шрифты, которые при загрузке меняют размер текста (FOIT и FOUT).
• Рекламные блоки и виджеты типа Я.Карт, чатов, форм подписки, которые подъезжают с задержкой.
• Видео с автозапуском, которое подгружает плеер уже после первого рендера.
• Анимации, использующие top/left вместо transform.

Лечится в основном профилактикой при вёрстке. Если у вас 200 страниц блога без размеров у картинок — готовьтесь к скучному вечеру с регулярками или с плагином для CMS.

Минимальный санитарный фикс

Для WordPress есть свежий PHP-фильтр, который добавляет width/height во все картинки в контенте, если их нет. В Битриксе делается через обработчик OnAfterRenderImage. На статике (Astro, Hugo, Next) — встроенным компонентом картинки, который ставит размеры автоматически.

Шрифты решаются через font-display: optional (без подмены, рискуем разными шрифтами при первой загрузке) или font-display: swap (быстрее, но возможен сдвиг). Для большинства сайтов малого бизнеса я предпочитаю optional плюс предзагрузку основного веса:

<link
  rel="preload"
  href="/fonts/inter-regular.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

Виджеты типа Я.Карт, JivoSite, чатов — резервируйте под них место заранее CSS-плейсхолдером. Тогда подгрузка не двигает контент.

INP вместо FID и почему он важнее

INP пришёл на смену FID в марте 2024 года. FID мерял задержку только до первого взаимодействия. Если первый клик быстрый, а каждый следующий по интерфейсу занимает секунду, FID этого не видел и оставался зелёным. INP смотрит на самое долгое взаимодействие на странице за всю сессию.

Что такое «взаимодействие». Клик, тап на тачскрине, нажатие клавиши. Не скролл (это считают отдельно). INP меряет от момента ввода до момента, когда браузер показал визуальный отклик: подсветился элемент, открылось меню, поменялась кнопка.

Пороги Google: хорошо до 200 мс, требует улучшения до 500 мс, плохо больше 500 мс. По 75-му перцентилю реальных пользователей.

Где обычно проседает INP на типичном сайте малого бизнеса:

• Тяжёлый JS на странице, который занимает основной поток при клике.
• Метрика и пиксели в формах, которые синхронно блокируют отправку.
• Аккордеоны и табы на чистом JS без debounce, по клику пересчитывающие layout всей страницы.
• Сторонние виджеты (чаты, формы, рекомендательные системы), которые перехватывают события.
• Слайдеры с тяжёлой инициализацией всех слайдов сразу.

Если ваш сайт на Astro или Hugo и без интерактива — INP по умолчанию идеальный, потому что JS на клиенте почти нет. Если на WordPress с десятком плагинов — INP будет основной болью после LCP.

Что можно сделать прямо сейчас

Самое быстрое — снести лишние плагины. WordPress позволяет в админке быстро отключить и оценить эффект. Я как-то на сайте автосервиса убрал три популярных плагина «социальные кнопки», «счётчик посетителей» и «анимации при скролле» — INP упал с 800 мс до 180 мс за один заход.

Дальше — проверить, какие сторонние скрипты грузятся. В DevTools, вкладка Coverage, видно, сколько кода реально использовано. Если 80 процентов JS не нужно для текущей страницы — это повод вынести его в defer или вообще убрать.

Метрика и пиксели — всегда async. Никогда не sync. Это единственная метрика, на которой реально можно сэкономить десятки миллисекунд:

<script async src="https://mc.yandex.ru/metrika/tag.js"></script>

Какие пороги в 2026 и как поведение Google и Яндекс отличается

Сводная таблица актуальных порогов:

Метрика	Хорошо	Улучшить	Плохо
LCP	до 2,5 с	2,5 — 4,0 с	> 4,0 с
CLS	до 0,1	0,1 — 0,25	> 0,25
INP	до 200 мс	200 — 500 мс	> 500 мс

Google оценивает в 75-м перцентиле, отдельно для мобильной и десктопной версии. То есть для одной и той же страницы у вас будут две разные оценки. На мобильном обычно хуже, потому что 4G и более слабый процессор.

Яндекс официально не публиковал, что именно использует CWV в формуле ранжирования. Но Я.Вебмастер показывает скорость загрузки в разделе «Скорость загрузки страниц», и там видны те же три метрики плюс TTFB. Алгоритм Яндекса оценивает поведенческие, а они напрямую страдают от плохих CWV. Косвенно влияние есть.

Практически: если вы делаете сайт под обе поисковые системы, ориентируйтесь на пороги Google. Они строже, и при их соблюдении Яндекс точно не пострадает.

Какой минимум считается приличным для бизнеса

Чек-лист, который я применяю на новых проектах:

• LCP мобильный: хочется до 2,5 с, допускается до 3 с в первые недели после запуска.
• LCP десктоп: до 1,8 с, иначе позорно.
• CLS: до 0,05 на всех типах страниц.
• INP: до 200 мс на главной и формах.
• TTFB: до 600 мс на shared, до 300 мс на VPS.

Если по какой-то метрике уехали — смотрите карту правок ниже.

Что чинить в первую очередь и в каком порядке

Список приоритетов, который работает в 9 случаях из 10:

1. Картинки: правильный формат (WebP/AVIF), размеры в HTML, fetchpriority на hero, lazy на всё кроме первого экрана.
2. Шрифты: предзагрузка основного веса, font-display: optional, не больше двух семейств.
3. JS: убрать лишние плагины и виджеты, defer на остальное, async на счётчики.
4. CSS: критический инлайн, остальное media="print" onload="this.media='all'" или с разделением.
5. Хостинг: PHP последней стабильной версии, OPcache включён, Memcached/Redis если CMS поддерживает.
6. CDN: для статики и картинок. На российской аудитории — российский CDN или edge от хостера.

После каждого пункта замеряйте PageSpeed. Иногда один пункт даёт +30 баллов, иногда ноль, и тогда надо понять почему.

Когда уже хватит и можно жить дальше

CWV — это не олимпийские игры. Если у вас на мобильном LCP 2,3 секунды, CLS 0,04, INP 180 мс — вы зелёный. Дальше копать имеет смысл только если в нише плотная конкуренция и оппоненты выжимают каждую десятую балла.

Я регулярно встречаю владельцев, которые гоняются за 100/100 в PageSpeed на главной и при этом не замечают, что страница услуги весит 5 мегабайт и грузится 8 секунд. Балл на главной и реальная производительность сайта — не одно и то же. Меряйте те страницы, на которые приходит трафик, а не только корень.

Цены на работы по ускорению я свёл в обзор — смотрите тарифы. Базовый аудит CWV занимает у меня 3-4 часа и даёт письменный план правок с приоритетами и оценкой эффекта в баллах. Если нужен полный цикл с реализацией — есть пакет на месяц с гарантированным выводом основных страниц в зелёную зону.

Если ваш сайт сейчас в красном по CWV и трафик из поиска просел за последние пару месяцев, это срочный кейс — напишите через форму или в Telegram, в течение дня посмотрю и пришлю предварительную оценку. Другие материалы по теме скорости — в рубрике speed.

Частые вопросы

Что такое Core Web Vitals простыми словами

Три показателя того, как сайт ощущается человеком: быстро ли появляется главное на экране (LCP), не прыгает ли вёрстка во время загрузки (CLS), быстро ли страница отвечает на клик (INP). Описание метрик ведёт web.dev.

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

LCP до 2,5 секунды, CLS до 0,1, INP до 200 миллисекунд. Диапазон от 2,5 до 4 секунд по LCP это жёлтая зона, дальше красная. Методика измерения разобрана в материале про LCP.

Чем INP отличается от FID

FID измерял задержку до первой реакции, INP смотрит на всё, что человек нажал за визит, и берёт худший случай. Замена произошла в марте 2024 года, разбор есть на web.dev.

Влияют ли Core Web Vitals на позиции в Яндексе

Напрямую Яндекс их не использует, но медленный сайт теряет позиции через поведенческие факторы. Свои значения можно посмотреть в PageSpeed Insights.