Коротко: Core Web Vitals — три метрики Google, по которым поисковик оценивает реальную скорость и стабильность страницы: LCP (когда появился главный контент), INP (как быстро интерфейс реагирует на клики) и CLS (насколько прыгает макет). С 2026 года это подтверждённый фактор ранжирования. Чтобы попасть в «зелёную зону», нужны LCP < 2.5 сек, INP < 200 мс и CLS < 0.1 на 75% посещений.

Если сайт теряет позиции в выдаче, а контент при этом сильный — проверяйте Core Web Vitals. Это первое, что стоит смотреть, когда «всё хорошо написано, но трафика нет». В 2026 году три метрики скорости (LCP, INP, CLS) учитываются в ранжировании напрямую, и медленная страница с отличным текстом проигрывает быстрой странице с тем же текстом. Особенно в коммерческих нишах, где разница между первой и третьей позицией — сотни кликов в месяц. Разбираем по шагам, что означает каждая метрика, чем её мерить и как быстро выйти в зелёную зону.

Что такое Core Web Vitals

Core Web Vitals — инициатива Google, запущенная в 2020 году и ставшая фактором ранжирования в мае 2021. Три метрики измеряют то, что пользователь реально чувствует: скорость появления главного контента, отзывчивость интерфейса на действия и визуальную стабильность страницы. До Core Web Vitals поисковики оценивали технические показатели сервера и HTML-парсинга — впервые фокус сместился именно на пользовательский опыт.

В марте 2024 года состав метрик изменился: вместо FID (First Input Delay) в Core Web Vitals вошёл INP (Interaction to Next Paint). FID измерял только первую задержку перед взаимодействием и не описывал общую отзывчивость — например, открытие меню или отправку формы. INP смотрит на все взаимодействия со страницей за сессию и показывает реальную картину «живости» интерфейса. Это важное изменение: если раньше сайт мог пройти проверку с тормозящими кнопками после первого клика, то теперь такие проблемы режут оценку напрямую.

По данным Google (2026), Core Web Vitals учитываются при ранжировании как «page experience signal» — совокупный сигнал наряду с HTTPS, отсутствием навязчивых межстраничных баннеров и адаптивностью для мобильных.

LCP — что это и почему за неё отвечает сервер

LCP (Largest Contentful Paint) — время от начала загрузки страницы до момента, когда браузер отрисовал самый крупный элемент в области просмотра. Обычно это изображение-герой, большой блок текста с заголовком или видео-постер. По сути LCP отвечает на вопрос «когда пользователь видит смысл страницы?».

Главный враг хорошего LCP — медленный TTFB (Time To First Byte). Это время от отправки запроса браузером до получения первого байта от сервера. Если TTFB выше 800 мс, никакая клиентская оптимизация не вытянет LCP в зелёную зону: пока сервер думает, браузер физически не может начать рендерить контент. По нашей практике, примерно в 60% случаев проблемы с LCP решаются на стороне сервера, а не в коде.

Метрика Хорошо Требует улучшения Плохо
LCP — загрузка главного контента < 2.5 сек 2.5–4.0 сек > 4.0 сек
INP — реакция на взаимодействие < 200 мс 200–500 мс > 500 мс
CLS — визуальная стабильность < 0.1 0.1–0.25 > 0.25
TTFB — время до первого байта < 800 мс 800–1800 мс > 1800 мс

Как улучшить LCP

  • Сжать LCP-изображение в WebP или AVIF — убрать лишние мегабайты с героя страницы;
  • Перенести шрифты в preload, чтобы они не блокировали отрисовку текста;
  • Настроить серверный кеш и CDN — это сразу режет TTFB в 2–3 раза на типовом shared-хостинге;
  • Убрать блокирующие скрипты в шапке — defer и async для всего, что не критично для первого экрана;
  • Использовать быстрый хостинг — переехать с VPS на managed-решение с NVMe и HTTP/3.

INP — главный враг тяжёлого JavaScript

INP (Interaction to Next Paint) — время от момента, когда пользователь нажал на кнопку или ввёл символ, до момента, когда браузер отрисовал следующий кадр с учётом этого действия. Метрика смотрит на все клики, тапы и нажатия клавиш за время сессии и фиксирует самое медленное (или близкое к нему) взаимодействие.

Если LCP в основном зависит от сервера и веса критического контента, то INP — почти целиком про JavaScript. Главный поток main thread блокируют обработчики событий, тяжёлые React-компоненты без SSR, аналитические скрипты, рекламные теги и сторонние виджеты. Чем больше JS и чем дольше он блокирует главный поток, тем хуже INP.

Типичная картина из нашей практики: сайт на WordPress с 15 плагинами, на каждой странице подключается jQuery и ещё 8 скриптов. Тест показывает INP около 350 мс — жёлтая зона. После отключения половины плагинов и перевода остальных на defer — 180 мс, зелёная. Без рефакторинга, просто за счёт порядка загрузки. Оптимизация скорости загрузки сайта в таких случаях начинается не с сервера, а с аудита JS-зависимостей.

Как улучшить INP

  1. Сократить объём JS — убрать библиотеки, которые подключены ради одной кнопки на лендинге;
  2. Разбить длинные задачи (long tasks) — любая задача дольше 50 мс уже тормозит главный поток;
  3. Использовать scheduler.yield() и requestIdleCallback для отложенной работы;
  4. Не блокировать рендеринг сторонними скриптами — аналитику и чаты подключать после onload;
  5. Переехать с React CSR на Next.js или Astro SSR для критических по конверсии страниц.

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

CLS — почему прыгают кнопки и как это чинить

CLS (Cumulative Layout Shift) — суммарное смещение элементов на странице во время загрузки. Каждый раз, когда контент прыгает из-за поздно подгрузившейся картинки, шрифта или баннера, растёт CLS. Высокий CLS — это раздражающий опыт: пользователь хочет нажать «Купить», а кнопка уехала под рекламный блок, и он нажал рекламу. На мобильных это особенно болезненно — там меньше места для манёвра и выше цена ошибки.

Главная причина CLS — отсутствие размеров у изображений, баннеров и iframe. Если у тега <img> не указаны width и height, браузер не знает, сколько места зарезервировать. Когда картинка наконец загрузится, она вытолкнет текст вниз. Аналогично с динамическими блоками: баннер «Скидка дня», который появляется через 2 секунды после загрузки — гарантированный CLS.

Как улучшить CLS

  • Указывать width и height у всех <img> и <iframe> — обязательно;
  • Резервировать место под рекламу и динамические блоки через min-height;
  • Использовать font-display: swap и подгружать fallback-шрифт того же метрического размера;
  • Не вставлять контент выше существующего — только добавлять вниз или заменять;
  • Проверять анимации — анимация через transform не вызывает CLS, через top/left — вызывает.

Чем измерять Core Web Vitals

Google раздаёт данные о Core Web Vitals из нескольких источников, и у каждого своё назначение. Не путайте их: PageSpeed Insights, Lighthouse и Search Console показывают разное — и для ранжирования работает только одно.

Инструмент Что показывает Тип данных Где смотреть
PageSpeed Insights LCP, INP, CLS + рекомендации Полевые и лабораторные pagespeed.web.dev
Lighthouse Полный аудит страницы Только лабораторные Chrome DevTools → Lighthouse
Search Console Групповые данные по сайту Полевые (CrUX) Раздел «Основные интернет-показатели»
Chrome UX Report (CrUX) Сырые данные по URL Полевые developer.chrome.com/docs/crux
web-vitals JS library Реальные замеры на своём сайте Полевые (свой трафик) npm/web-vitals

Для ежедневной работы удобнее всего PageSpeed Insights: вводите URL — получаете оценку и список конкретных рекомендаций. Для отслеживания динамики по всему сайту — Search Console, раздел «Основные интернет-показатели». Он сразу показывает, какие группы URL в красной зоне и за какой период. Lighthouse хорош как отладочный инструмент — показывает дерево критических ресурсов и waterfall загрузки, но для оценки реальных пользователей бесполезен.

Полевые и лабораторные данные — в чём разница

Полевые данные (field data) — реальные измерения от пользователей Chrome через Chrome UX Report. Они показывают, что видят обычные посетители на разных устройствах, сетях и в разных регионах. Лабораторные данные (lab data) — синтетический тест в контролируемых условиях: один девайс, один регион, чистый кеш. PageSpeed Insights выдаёт оба типа в одном отчёте.

Google использует для ранжирования только полевые данные CrUX. Поэтому лабораторный тест на десктопе с быстрым интернетом не гарантирует хорошее ранжирование: на слабом Android в регионе с 3G картина может быть совсем другой. Смотреть нужно прежде всего на раздел «Реальные пользователи» в PageSpeed Insights и на отчёт Core Web Vitals в Search Console.

По данным Google (2026), пороговые значения Core Web Vitals применяются на уровне 75-го перцентиля — это значит, что в зелёной зоне должны быть минимум 75% загрузок страницы за период сбора.

Типичный провал из нашей практики: лабораторный тест на быстрой машине показывает LCP 1.8 секунды, а Search Console — красную зону. Причина проста: тест на одной машине в одном регионе, а реальные пользователи сидят на старых телефонах через медленный мобильный интернет. Если видите такое расхождение — оптимизируйте под слабые устройства, а не под эталонную конфигурацию.

Как улучшить Core Web Vitals — пошаговый план

Когда вы впервые открываете отчёт Core Web Vitals и видите красную зону по всем метрикам — хочется править всё сразу. Не надо. Оптимизация идёт по приоритетам: сначала самое дешёвое и быстрое, потом сложные изменения. Вот порядок, который работает в 80% случаев.

  1. Открыть Search Console → раздел «Основные интернет-показатели». Зафиксировать, какие группы URL в красной зоне и по каким именно метрикам;
  2. Прогнать 10 самых посещаемых страниц через PageSpeed Insights — увидеть паттерн (например, у всех плохой LCP из-за одной и той же картинки);
  3. Измерить TTFB на проблемных URL через WebPageTest или встроенный замер в PageSpeed Insights — если выше 800 мс, чинить серверную часть;
  4. Оптимизировать LCP-элемент на каждой странице — сжать картинку, перенести в preload, убрать блокирующие скрипты;
  5. Сократить JS для INP — отключить ненужные плагины, перевести скрипты на defer/async, убрать сторонние виджеты, которые грузятся синхронно;
  6. Проверить CLS — пройтись по всем изображениям и iframe, добавить width/height, зарезервировать место под баннеры;
  7. Дождаться обновления данных в Search Console — это занимает до 28 дней, ускорить нельзя.
Нужна помощь с Core Web Vitals?
Сделаем аудит скорости, найдём узкие места и доведём сайт до зелёной зоны. Первая консультация бесплатно.
Написать в Telegram →

Что проверить за один вечер — быстрые победы

Часть улучшений даёт результат буквально за вечер и не требует программиста. Начните с них, прежде чем лезть в рефакторинг.

  • Сжать все LCP-изображения в WebP — обычно режет размер на 30–50%;
  • Добавить width и height ко всем <img> — моментально снижает CLS;
  • Поставить font-display: swap и подобрать системный fallback того же размера — решает CLS от шрифтов;
  • Перевести скрипты в defer — все, что не критичны для первого экрана;
  • Включить сжатие Brotli на сервере — режет вес HTML и CSS на 15–20%;
  • Настроить кеш статики через Cache-Control: max-age — повторные визиты ускоряются в разы.

Частые ошибки, которые мы видим постоянно

За последние пару лет мы проверили сотни сайтов на Core Web Vitals — и есть ошибки, которые повторяются у 7 из 10 проектов. Чеклист, по которому стоит пройтись перед тем, как считать задачу закрытой.

  • Установлен jQuery и Bootstrap ради одной формы на лендинге — это лишние 90 КБ JS, которые вредят INP;
  • Скрипты аналитики подключены в <head> синхронно — блокируют рендеринг и ухудшают LCP;
  • Hero-изображение весит 1.5 МБ — загружается в полном разрешении, без srcset;
  • Шрифты подключены через @import в середине CSS — приходят с задержкой и вызывают CLS;
  • TTFB > 1.5 секунды из-за shared-хостинга и отсутствия серверного кеша.

Если ваш проект тормозит из-за всех пяти пунктов сразу — начните с TTFB: смена хостинга или включение кеша моментально облегчает все три метрики разом. Подробнее о комплексном подходе к продвижению в современных условиях — в статье про стратегии SEO в 2025 году, там разобрано, как скорость укладывается в общую картину факторов ранжирования.

Коротко о главном

Core Web Vitals — три метрики, которые показывают, насколько сайт быстрый и стабильный с точки зрения пользователя. Чтобы пройти проверку Google, нужны LCP < 2.5 сек, INP < 200 мс и CLS < 0.1 на 75% посещений. Измерять стоит прежде всего через Search Console и PageSpeed Insights — это полевые данные CrUX, которые Google использует для ранжирования. Лабораторные тесты (Lighthouse, синтетика) полезны для отладки, но не показывают реальную картину. Начинайте оптимизацию с TTFB и сжатия LCP-картинок — это даёт максимальный эффект за минимальное время. Если нужна помощь — напишите нам, проведём аудит и доведём сайт до зелёной зоны.

Поделиться: ВК TG