Core Web Vitals 2026 - три метрики Google, которые описывают пользовательский опыт сайта в цифрах. От них зависит позиция в выдаче, доля отказов и в конечном счёте выручка. В этом гайде разберём каждую из них (LCP, INP, CLS) отдельно: что измеряет, какие целевые значения, какие техники реально сдвигают цифры в зелёную зону.
Материал собран по 550+ проектам веб-студии Сайты2.рф из Кронштадта с 2008 года. Внутри: история метрик с 2020 года, 16 техник улучшения, особенности Битрикс, WordPress и Tilda, инструменты измерения. Время чтения - 14 минут.
Что такое Core Web Vitals и почему важны
Core Web Vitals - набор из трёх метрик Google, которые отражают реальный опыт пользователя на сайте: насколько быстро появляется основной контент, насколько отзывчив интерфейс, не прыгает ли вёрстка при загрузке. Это основные веб-показатели, которые Google рекомендует контролировать любому сайту.
С июня 2021 года Google официально включил CWV в факторы ранжирования. Метрики попадают в поле выдачи через Chrome User Experience Report (CrUX) - анонимные данные миллионов реальных Chrome-пользователей. Если ваш сайт в красной зоне у 75% посетителей, Google понижает его при прочих равных.
Яндекс прямо CWV не использует, но опирается на собственные показатели скорости и поведенческие факторы. Медленный сайт получает больше отказов, отказы попадают в формулу ранжирования. Связь та же, путь - другой.
Пользовательский опыт - это деньги. По данным Akamai, каждая секунда задержки забирает 7% конверсии. Сайт с LCP 4,5 секунды теряет вдвое больше заявок, чем сайт с LCP 1,5 секунды. Метрики веб-витальс не про техническую гигиену, а про выручку напрямую.
История метрик 2020-2026
Google анонсировал Core Web Vitals в мае 2020 года. Первый состав: LCP (скорость), FID (отзывчивость), CLS (стабильность). С июня 2021 эти три метрики начали влиять на ранжирование в мобильной выдаче, с февраля 2022 - в десктопной.
В марте 2024 года FID (First Input Delay) был заменён на INP (Interaction to Next Paint). FID измерял только задержку первого взаимодействия, INP оценивает все клики, тапы и нажатия за сессию. Это намного жёстче: один тяжёлый JS-обработчик в середине сайта теперь портит метрику целиком.
К 2026 году целевые значения не изменились, но Google ужесточил трактовку. Раньше сайт считался прошедшим CWV, если 75% сессий укладывались в "хорошие" пороги. Сегодня тот же порог, но Google больше веса даёт мобильному трафику и сложным интерактивным страницам.
Параллельно появились дополнительные диагностические метрики (TTFB, FCP, TBT), но они не входят в Core Web Vitals. Их используют для углублённого аудита, не для оценки в выдаче.
LCP - Largest Contentful Paint
LCP - время от запроса страницы до отрисовки самого крупного элемента на первом экране. Целевое значение: до 2,5 секунды. Зелёная зона по Google: 75% сессий укладываются в 2,5 секунды и меньше.
Что попадает в LCP-элемент
Браузер сам определяет, какой элемент крупнейший. Кандидаты:
- Главное изображение первого экрана (hero-баннер, фото товара)
- Фоновое изображение блока через background-image
- Видео-постер (атрибут poster тега video)
- Крупный заголовок H1 при отсутствии большого изображения
- Блочный элемент с текстом (если изображений нет)
LCP-элемент меняется по мере загрузки. Сначала это может быть H1, потом - подгрузившийся баннер. Финальный LCP - самый поздний крупный элемент, отрисованный до взаимодействия пользователя.
6 техник улучшения LCP
1. Preload главного изображения. Подсказывает браузеру: грузи эту картинку сразу, не жди парсинга. В шапке HTML:
<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">
Эффект: ускоряет LCP на 0,3-1,2 секунды на типовых корпоративных сайтах.
2. Оптимизация веса (WebP/AVIF). JPEG-баннер 2 МБ грузится 4 секунды на 4G. Тот же кадр в WebP - 600 КБ, в AVIF - 350 КБ. Перекодируйте через Squoosh, ImageMagick или плагины CMS. Качество 75-82 - незаметно для глаза, экономит 40-60% веса.
3. Убрать render-blocking JS/CSS. Каждый внешний скрипт в шапке без атрибута defer задерживает парсинг страницы. CSS блокирует рендер по умолчанию. Решения: defer на все некритичные скрипты, инлайн критического CSS, остальной CSS грузить через preload с onload.
4. Атрибут fetchpriority="high". Браузер по умолчанию даёт высокий приоритет первым 5 изображениям, но не всегда угадывает. Явное указание:
<img src="/img/hero.webp" fetchpriority="high" alt="...">
Снижает LCP на 0,1-0,5 секунды на мобильных, особенно при медленном 4G.
5. Быстрый TTFB через CDN. Time to First Byte - время от запроса до первого байта ответа сервера. TTFB больше 600 мс делает зелёный LCP практически недостижимым. Решения: CDN (Cloudflare, BunnyCDN, Selectel CDN), серверный кеш страниц, выбор хостинга в России для российской аудитории.
6. Браузерное и серверное кеширование. Заголовки Cache-Control: max-age=31536000 на статику (картинки, шрифты, CSS, JS). Service Worker для второго и последующих визитов. На Битрикс - встроенный кеш страниц и компонентов. На WordPress - WP Rocket, LiteSpeed Cache.
Если у вас интернет-магазин с большим первым экраном, тема LCP подробно разобрана в гайде Как ускорить сайт до 1,5 секунды.
INP - Interaction to Next Paint
INP - максимальная задержка между действием пользователя и визуальным откликом интерфейса. Целевое значение: до 200 миллисекунд. Жёлтая зона: 200-500 мс. Красная: больше 500 мс.
Метрика заменила FID в марте 2024 года. Главное отличие: FID измерял только первое взаимодействие, INP смотрит на все клики, тапы и ввод текста за сессию и берёт практически худший результат (98-й перцентиль).
Что измеряется
INP считается для трёх типов событий:
- Клик мышью (click, mousedown, mouseup)
- Тап на тачскрине (touchstart, touchend)
- Нажатие клавиши (keydown, keyup) - ввод текста в поля, использование клавиатурной навигации
Прокрутка и hover не учитываются. Время измеряется от момента события до следующей отрисовки кадра, в которой видны изменения интерфейса.
5 техник улучшения INP
1. Разбить длинные JS-задачи на чанки. Любая JS-функция дольше 50 мс блокирует главный поток и портит INP. Делите тяжёлые операции на части через setTimeout(fn, 0) или новый API scheduler.yield(). Браузер вставляет между чанками отрисовку и обработку событий.
2. requestIdleCallback для некритичных задач. Аналитика, отправка событий, прогрев кеша - всё это вешайте на requestIdleCallback. Браузер выполнит функцию в момент простоя, не мешая основному взаимодействию.
3. Отложить аналитику и сторонние скрипты. Яндекс.Метрика, Google Analytics, чат-боты, пиксели соцсетей грузите после события load или через 3-5 секунд бездействия. Tag Manager позволяет настроить отложенную загрузку триггерами. Эффект: INP падает на 100-300 мс на сайтах с десятком счётчиков.
4. Убрать тяжёлые обработчики на input. Обработчики oninput, которые на каждый символ дёргают серверный поиск, фильтруют большой список или пересчитывают форму, - частая причина INP под 800 мс. Решения: дебаунс (debounce 200-300 мс), throttle, перенос вычислений в отдельный таск.
5. Web Workers для сложных вычислений. Сортировка больших массивов, парсинг JSON, работа с изображениями на клиенте - всё это в Web Worker. Главный поток остаётся свободным для обработки кликов и отрисовки. На Битрикс и WordPress воркеры подключаются обычным JS, специальной поддержки от CMS не нужно.
INP сложнее всего исправить пост-фактум. Архитектура клиентского JS закладывается на этапе вёрстки. Если переписываете сайт, смотрите услугу редизайн сайта - там INP закладывается на старте.
CLS - Cumulative Layout Shift
CLS - суммарный сдвиг макета за время жизни страницы. Целевое значение: до 0,1. Жёлтая зона: 0,1-0,25. Красная: больше 0,25.
Метрика без единиц измерения, считается как доля сдвинувшейся площади экрана, помноженная на расстояние сдвига. Сдвиг 30% экрана на 20% высоты = 0,06. Несколько таких прыжков подряд - и CLS улетает в красное.
Что вызывает сдвиги
Пять главных источников CLS на корпоративных сайтах:
- Изображения и iframe без указанных размеров (width, height или aspect-ratio)
- Шрифты, которые подгружаются позже текста, и буквы меняют ширину
- Динамический контент: всплывающие баннеры, плашки cookies, реклама
- Внедрённые позже блоки (карты, отзывы, виджеты соцсетей)
- Анимации через свойства top, left, margin - они перерасчитывают вёрстку
5 техник улучшения CLS
1. width/height на всех img и iframe. Браузер резервирует место под картинку до её загрузки, если знает пропорции. Пишите явные атрибуты или CSS aspect-ratio:
<img src="/img/case.webp" width="800" height="450" alt="...">
Альтернатива через CSS:
img { aspect-ratio: 16 / 9; width: 100%; height: auto; }
2. font-display: swap + preload шрифтов. Без font-display браузер ждёт шрифт до 3 секунд, потом показывает запасной. Когда основной приходит, текст перепрыгивает. Решение: font-display: swap (моментально показать запасной) + preload основного шрифта:
<link rel="preload" href="/fonts/onest.woff2" as="font" type="font/woff2" crossorigin>
3. Резервирование места под рекламу и баннеры. Если на странице есть слот под баннер 300×250, выделите контейнер min-height: 250px до загрузки. Иначе баннер вставится в готовый текст и сдвинет всё ниже. То же касается плашки cookies - её показывают через position: fixed снизу, чтобы не двигать контент.
4. transform вместо top/left для анимаций. Свойства transform: translate и opacity не пересчитывают вёрстку. Они выполняются на GPU, не дают CLS. Анимация появления блока: transform: translateY(20px) → translateY(0), opacity: 0 → 1. Запрещены: анимация через top, left, margin, height, width.
5. aspect-ratio для адаптивного видео и эмбедов. YouTube-плеер, карта Яндекса, виджет отзывов - оборачивайте в контейнер с фиксированной пропорцией. CSS:
.embed { aspect-ratio: 16 / 9; }
Контейнер занимает место сразу, виджет грузится внутрь без сдвига соседних блоков.
CLS видно невооружённым глазом. Если открываешь сайт и текст прыгает - CLS красный. Если ничего не двигается - почти наверняка зелёный.
Как измерить CWV правильно
Главное правило измерения: разделять полевые данные (поле, реальные пользователи) и лабораторные (лаб, синтетический тест в идеальных условиях). Поле - правда. Лаб - инструмент диагностики.
Поле: PageSpeed Insights и Search Console
PageSpeed Insights - первичная диагностика. В верхней части отчёта - реальные данные CrUX за 28 дней. Это то, что видит Google и учитывает в ранжировании. Цифры по LCP, INP, CLS отдельно для мобильных и десктопа.
Search Console - раздел "Основные интернет-показатели". Показывает динамику CWV по группам URL за 3 месяца. Удобно отслеживать, какие шаблоны страниц проседают: главная, карточки товаров, страницы каталога.
Яндекс.Метрика тоже собирает LCP, INP, CLS с реальных посетителей. Отчёт в разделе "Технологии - Скорость загрузки".
Лаб: Lighthouse и WebPageTest
Lighthouse встроен в Chrome DevTools (вкладка Performance Insights). Запускаете одну страницу - получаете оценку 0-100, список проблем с приоритетом. Показывает синтетические LCP и CLS, но не INP (для INP нужен реальный пользователь).
WebPageTest - детальный аудит с waterfall-графиком, тестом из разных стран, проверкой на разной скорости интернета. Используем для углублённой диагностики сложных кейсов.
Чем поле отличается от лаба
Лаб запускает тест с быстрого сервера, без расширений, без активного антивируса, на свежем устройстве. Поле собирает данные у реальных людей на старых телефонах, со слабым 4G, с десятком вкладок в браузере.
Цифры расходятся в 1,5-3 раза. Зелёный Lighthouse при красном CrUX - типичная ситуация. Доверяйте полю, лаб используйте для поиска причин.
CWV в Битрикс, WordPress, Tilda
Подход к улучшению CWV зависит от стека. Быстрые победы на каждой CMS разные.
1С-Битрикс
Главные проблемы: тяжёлый ядерный JS, шаблоны компонентов с лишними обёртками, большой prolog/epilog.
Быстрые победы:
- Включить композитный кеш через Производительность - Композитный сайт
- Включить кеширование компонентов и автокомпозит
- Отключить ненужные модули (форум, опросы, обучение) если не используются
- Использовать оптимизатор медиа в свойствах структуры
- Перенести JS в подвал через AddString с типом END_BODY
Средний результат на коробке "Стандарт" после оптимизации: LCP с 4,2 до 1,8 секунды, CLS с 0,28 до 0,06.
WordPress
Главные проблемы: десятки плагинов добавляют каждый свой CSS и JS, тяжёлые темы с встроенным конструктором, слабый хостинг.
Быстрые победы:
- Кеш-плагин WP Rocket или LiteSpeed Cache
- Asset CleanUp для удаления CSS/JS на страницах, где они не нужны
- ShortPixel или Imagify для конвертации в WebP
- Отключение Heartbeat API на фронте через wp-config или плагин
- Аудит активных плагинов - удалить всё, чем не пользуетесь 30 дней
Конструкторы Elementor, WPBakery дают +0,8-1,5 секунды к LCP. Если CWV критичны, переход на блочный редактор или Bricks Builder снимает основную нагрузку.
Tilda
Главные проблемы: ограниченная гибкость, общий шаблонный JS блоков, шрифты без оптимизации.
Быстрые победы:
- Включить ускорение в настройках сайта (Сайт - Ещё - Ускорение)
- Использовать AMP-блоки для главной и посадочных
- Грузить кастомные шрифты через CSS с font-display: swap
- Минимизировать количество T-блоков на странице (каждый добавляет свой JS)
- Отключить неиспользуемые блоки в шаблоне через Zero Block
Tilda даёт средний LCP 1,7-2,3 секунды из коробки на простых лендингах. CLS обычно зелёный благодаря фиксированным размерам блоков.
Если выбираете CMS под скорость, сравнение есть в статье Битрикс vs WordPress и общем гайде технический SEO-аудит.
Приоритизация работ
С чего начинать оптимизацию: смотрим в PageSpeed Insights полевые данные. Та метрика, которая в красной зоне (или дальше всех от зелёной), - первая на улучшение.
Типовая последовательность:
- Замер исходных значений LCP, INP, CLS в поле (через PageSpeed Insights, Search Console, Яндекс.Метрику)
- Определение шаблонов страниц с худшими показателями (главная, каталог, карточки)
- Гипотезы по каждой метрике (что технически вызывает плохую цифру)
- Внедрение 3-5 техник на одной странице как пилот
- Замер через 28 дней (поле обновляется не сразу)
- Откат или масштабирование на остальные шаблоны
Не пытайтесь улучшать все три метрики одновременно. Команда теряет фокус, изменения накладываются, понять что сработало - невозможно. Один спринт = одна метрика = одна группа техник.
Если все три метрики красные, начинайте с LCP: он легче всего сдвигается, влияет на общее ощущение скорости и часто тянет за собой INP. CLS обычно правится за 1-2 дня и закрывается навсегда.
Полную приоритизацию работ за неделю расписали в гайде по ускорению сайта.
CWV и SEO: связь с ранжированием
Google официально подтвердил CWV как фактор ранжирования в мае 2020 и активировал влияние в июне 2021. Это не главный фактор, но при равных условиях быстрый сайт обходит медленный.
Дополнительно с 2023 года Google прямо рекомендует CWV как сигнал для оценки сайта алгоритмом Page Experience. Туда же входят: HTTPS, отсутствие назойливых интерстишиалов, мобильная адаптация. CWV - самая измеримая часть этого комплекса.
Яндекс в апреле 2023 включил в формулу "новые сигналы качества", куда вошли поведенческие факторы и скорость. Прямого аналога CWV у Яндекса нет, но скорость загрузки и доля отказов - известные факторы YMW и MatrixNet.
В нашей практике после улучшения CWV из красной зоны в зелёную позиции в Google растут на 8-15 пунктов в среднем по 50-100 ключам. В Яндексе эффект меньше (4-7 пунктов), но виден на горизонте 2-3 месяцев. Это видно по статистике 80+ SEO-проектов в студии за 2023-2025 годы.
Связка работает в обе стороны. Хороший контент на медленном сайте получает меньше трафика. Слабый контент на быстром сайте не вытаскивается одной скоростью. CWV - множитель, а не замена SEO. Про систему продвижения подробно - в гайде SEO-продвижение: с чего начать.
FAQ
Что такое Core Web Vitals в 2026 году
Три метрики Google для оценки пользовательского опыта: LCP (скорость отрисовки основного контента), INP (отзывчивость интерфейса на действия), CLS (стабильность вёрстки). Целевые значения: LCP до 2,5 секунды, INP до 200 мс, CLS до 0,1.
Чем INP отличается от FID
FID измерял только задержку первого взаимодействия и редко показывал реальные проблемы. INP смотрит на все клики, тапы и ввод текста за сессию и берёт практически худший результат. Метрика жёстче и точнее отражает опыт. INP заменил FID в марте 2024 года.
Что важнее: поле или лаб
Поле важнее для ранжирования и для понимания реального опыта. Лаб - инструмент для поиска причин. Никогда не оценивайте сайт только по Lighthouse - там идеальные условия, а Google учитывает CrUX-данные реальных пользователей.
За сколько обновляются данные CWV в Search Console
CrUX-данные собираются за 28-дневное окно. После изменений на сайте улучшения видны в Search Console через 14-21 день и полностью обновляются через 28 дней. Не делайте выводы по первой неделе - данных мало.
Можно ли пройти CWV на бесплатном хостинге
Технически да, если хостинг даёт TTFB до 400 мс и поддерживает HTTPS, кеширование, современные форматы изображений. На практике большинство бесплатных хостингов не вытягивают зелёный LCP. Минимум: shared-хостинг от 300 ₽ в месяц или VPS от 600 ₽.
Сколько стоит оптимизация под Core Web Vitals
В студии Сайты2.рф базовая оптимизация под CWV - от 25 000 ₽ за корпоративный сайт до 30 страниц. Глубокая оптимизация интернет-магазина с переработкой архитектуры - от 80 000 ₽. Срок: 2-4 недели. Точный расчёт - на странице цены или через калькулятор.
Что в итоге
Core Web Vitals 2026 - не абстрактная техническая гигиена, а измеримый показатель качества сайта, влияющий на позиции и выручку. Три метрики (LCP, INP, CLS) разбирают по очереди, по одной за спринт, с замером в поле через 28 дней.
Главные принципы:
- Поле важнее лаба, оценка - по реальным пользователям
- Одна метрика - один спринт, не размазывайте усилия
- Начинайте с самой плохой метрики, обычно это LCP
- CLS закрывается быстро и навсегда, INP - сложнее всего
- CMS определяет 60% быстрых побед, выбирайте по задаче
Если нужен аудит CWV вашего сайта - в Сайты2.рф делаем бесплатную проверку через инструмент проверки скорости и платный глубокий аудит за 3 рабочих дня. По итогам - список 15-30 точек роста с оценкой эффекта по каждой метрике.
Получить аудит Core Web Vitals · Telegram: @t9424744
