В 2026 году каждый второй потенциальный клиент уходит с сайта, не дождавшись его загрузки. Google и Яндекс фиксируют это и понижают такие сайты в выдаче. Core Web Vitals — набор из трёх измеримых метрик, которые описывают пользовательский опыт загрузки. Если ваш сайт не проходит по этим порогам, он платит двойную цену: теряет позиции и теряет конверсию.
По данным Think with Google, пользователи 53% мобильных сессий покидают страницу, если она не загрузилась за 3 секунды. В B2B-сегменте это означает потерянные заявки — потенциальный клиент уходит к конкуренту, сайт которого открылся быстрее. Core Web Vitals дают конкретные, измеримые пороги, чтобы понять: ваш сайт попадает в 47% быстрых или в 53% медленных.
В этой статье разберём, что именно измеряет каждая метрика, какие пороги актуальны в 2026 году и как привести сайт в норму — без переписывания с нуля.
Что такое Core Web Vitals и почему они важны
Core Web Vitals (CWV) — три метрики, которые Google официально включил в факторы ранжирования в 2021 году. Яндекс не публикует их веса явно, но скорость загрузки учитывается в ИКС (индекс качества сайта) и влияет на позиции в российском поиске с 2018 года.
Принципиальное отличие CWV от предыдущих метрик скорости: они измеряют реальный пользовательский опыт, а не синтетическую скорость в тепличных условиях. Google собирает данные через Chrome User Experience Report (CrUX) — это реальные замеры с устройств ваших пользователей за последние 28 дней.
Три метрики отвечают на три вопроса:
- LCP: как быстро пользователь видит главный контент?
- CLS: не «прыгает» ли страница пока грузится?
- INP: насколько быстро страница реагирует на действия?
LCP — Largest Contentful Paint: скорость отрисовки главного контента
LCP измеряет время от начала загрузки страницы до момента, когда в вьюпорте отрисовался самый крупный элемент. Чаще всего это Hero-изображение на главной, заголовок статьи или баннер.
Пороги 2026 года:
- ✅ Хорошо: ≤ 2.5 секунды
- ⚠️ Требует улучшений: 2.5–4.0 секунды
- ❌ Плохо: > 4.0 секунды
Что убивает LCP чаще всего на российских сайтах:
- Тяжёлые изображения без конвертации. Картинка в PNG 2 МБ вместо WebP 200 КБ — главная причина провала. Браузер вынужден скачать весь файл до отрисовки.
- Медленный хостинг. TTFB (Time to First Byte) больше 600 мс означает, что сервер «думает» полсекунды до того, как начать отдавать HTML. Дешёвый shared-хостинг на HDD — типичная причина.
- Рендеринг на клиенте. Vue/React-сайты без SSR/SSG отдают пустой HTML — браузер ждёт пока JS загрузится и создаст DOM.
- Отсутствие preload для Hero-изображения. Браузер «узнаёт» об изображении только после парсинга CSS — добавление
<link rel="preload">сокращает LCP на 400–800 мс.
CLS — Cumulative Layout Shift: стабильность вёрстки
CLS описывает, насколько визуально стабильна страница пока загружается. Каждый раз, когда элемент «прыгает» и смещает содержимое — пользователь может случайно нажать не на ту кнопку или потерять место чтения.
Пороги 2026 года:
- ✅ Хорошо: ≤ 0.1
- ⚠️ Требует улучшений: 0.1–0.25
- ❌ Плохо: > 0.25
На проектах АйТи-Стандарт мы держим CLS = 0 (не ≤ 0.1, а именно ноль) — это требование нашего внутреннего стандарта качества.
Типичные причины CLS:
- Изображения без явных размеров. Браузер не знает, сколько места зарезервировать до загрузки — и вёрстка «дышит». Решение: атрибуты
widthиheightили CSSaspect-ratio. - Веб-шрифты без font-display: swap. Браузер сначала показывает системный шрифт, потом меняет на загруженный — текстовые блоки смещаются.
- Динамические блоки без зарезервированного пространства. Баннеры, cookie-уведомления, чат-виджеты — всё, что появляется после первой отрисовки, должно иметь фиксированное место в вёрстке.
- Сторонние скрипты. Виджеты обратного звонка, онлайн-консультанты и счётчики аналитики часто вставляют DOM-элементы в видимую зону после загрузки.
INP — Interaction to Next Paint: отзывчивость интерфейса
INP заменил FID (First Input Delay) в марте 2024 года. Он измеряет задержку от любого взаимодействия пользователя (клик, тап, ввод с клавиатуры) до следующей отрисовки страницы. FID измерял только первое взаимодействие — INP анализирует ВСЕ взаимодействия за сессию и берёт 75-й перцентиль.
Пороги 2026 года:
- ✅ Хорошо: ≤ 200 мс
- ⚠️ Требует улучшений: 200–500 мс
- ❌ Плохо: > 500 мс
На большинстве WordPress-сайтов с минимальным JS проблем с INP нет — метрика критична для SPA-приложений и страниц с тяжёлыми сторонними скриптами (онлайн-чат, калькуляторы, сложные фильтры).
Как Core Web Vitals влияют на позиции и трафик
Google учитывает CWV в алгоритме «Page Experience». Сайты с хорошими показателями получают небольшой буст в ранжировании. Само по себе это не отправит вас на первое место — контент и ссылки важнее. Но при прочих равных сайт с хорошим CWV обгоняет аналогичный медленный сайт.
Реальный эффект заметен в нишах с высокой конкуренцией. По данным Think with Google, сайты в «зелёной» зоне по всем трём CWV-метрикам на 24% реже теряют позиции при алгоритмических обновлениях.
Для Яндекса прямых публичных данных меньше, но картина схожая: поведенческие факторы (отказы, время на сайте, глубина просмотра) зависят от скорости, а поведенческие факторы — подтверждённый сигнал ранжирования в Яндексе.
Как Core Web Vitals влияют на конверсию и заявки
Связь скорости с конверсией — это не маркетинговая теория, а измеренные данные крупных компаний:
- Google, 2021: рост LCP с 2.5 до 4 секунд увеличивает вероятность отказа на 32%. При 5 секундах — на 90%.
- Vodafone, 2021: улучшение LCP на 31% дало рост конверсии на 8% и рост среднего чека на 15%.
- Нестандартное исследование Deloitte (e-commerce): ускорение мобильной загрузки на 0.1 секунды увеличило конверсию на 8.4%, средний чек — на 9.2%.
Для B2B-сайтов, где клиент изучает услуги, а не покупает в один клик, эффект другой: медленный сайт формирует негативное первое впечатление о профессионализме студии или агентства. Если сайт веб-студии грузится 6 секунд — как она будет делать ваш сайт?
Как проверить Core Web Vitals своего сайта
Несколько инструментов дают разную картину — важно понимать отличия:
PageSpeed Insights (pagespeed.web.dev)
Самый простой способ. Показывает реальные данные CrUX (если набралось достаточно трафика) и синтетический аудит Lighthouse. Запускайте проверку мобильной версии — именно она влияет на ранжирование в Google.
Google Search Console → Core Web Vitals
Раздел «Core Web Vitals» в Search Console показывает агрегированные данные по всем страницам сайта за 28 дней. Здесь видны системные проблемы: «100 страниц с плохим LCP» — это уже повод для срочного аудита.
Lighthouse в Chrome DevTools
Синтетический тест — запускается на вашей машине в изолированном окружении. Полезен для отладки в процессе разработки, но не отражает реального опыта пользователей из регионов с медленным интернетом.
Web Vitals Extension
Расширение Chrome от Google — показывает реальные CWV при каждом просмотре страницы. Удобно для быстрой проверки без лишних инструментов.
Типичные проблемы WordPress и как их исправить
WordPress — самая популярная CMS в Рунете, и у неё есть типовые проблемы с CWV, которые легко воспроизводятся:
Тяжёлые изображения (LCP)
Решение: конвертировать все изображения в WebP или AVIF. На WordPress это делает плагин ShortPixel, Imagify или встроенная конвертация при загрузке. Дополнительно: включить lazy loading для изображений ниже первого экрана и fetchpriority="high" для LCP-изображения.
Блокирующий JavaScript (LCP + INP)
Любой <script> без атрибута defer или async останавливает парсинг HTML — браузер ждёт загрузки и выполнения скрипта. Решение: все JS через defer. Для критичных скриптов — перенести в <body> перед закрывающим тегом.
Google Fonts вместо self-hosted (CLS + LCP)
Google Fonts требуют DNS-запрос к googleapis.com + загрузку CSS + загрузку файла шрифта. В России скорость соединения с Google нестабильна. Решение: скачать шрифты и подключать локально с font-display: swap и preload.
Нет page cache (LCP, TTFB)
WordPress генерирует страницу динамически при каждом запросе. Без кеширования TTFB легко уходит за 1 секунду. Решение: WP Rocket, FlyingPress или WP Super Cache. На правильном хостинге включить Redis или Memcached.
Медленный хостинг (LCP, TTFB)
TTFB > 600 мс — сигнал проблемы на уровне сервера. Перенос с shared-хостинга на VPS с SSD NVMe сокращает TTFB до 100–200 мс. Для Москвы и Санкт-Петербурга оптимален дата-центр в России.
Кейс АйТи-Стандарт: сайт с Performance 47 → 96
Клиент: региональный застройщик, корпоративный сайт на WordPress с 80+ страниц. По данным Google Search Console — 73% страниц в «красной» зоне по LCP.
Проблемы при аудите:
- Hero-секция: JPG 3.2 МБ без конвертации и без preload → LCP 7.8 сек
- 15 активных плагинов подключали 23 JS-файла без defer
- Google Fonts: Montserrat + Roboto с googleapis.com
- Хостинг: shared, HDD, TTFB 1.1 сек
- Нет page cache
Что сделали за 3 недели:
- Перенос на VPS NVMe + Nginx + Redis → TTFB упал до 80 мс
- Все изображения → WebP через ShortPixel + явные width/height
- Preload для Hero + fetchpriority=high
- Шрифты self-hosted + font-display:swap
- WP Rocket с полным page cache + CDN
- Аудит JS: 11 плагинов отключены/заменены, defer на оставшиеся
Результат: Performance mobile 47 → 96, LCP 7.8 → 1.9 сек, CLS 0.31 → 0.0, INP 380 → 95 мс. Через 2 месяца органический трафик вырос на 34% — часть роста объяснима улучшением позиций, часть — снижением отказов с 71% до 44%.
Как наладить постоянный мониторинг Core Web Vitals
Разовая оптимизация — это хорошо, но CWV-показатели меняются. Новый плагин, обновление темы или появление тяжёлого стороннего виджета могут вернуть сайт в красную зону незаметно. Вот минимальный стек для постоянного контроля:
- Google Search Console: проверяйте раздел «Core Web Vitals» раз в две недели. Search Console присылает письмо, если страницы переходят из зелёной зоны в жёлтую — подпишитесь на уведомления.
- Яндекс.Вебмастер → «Метрика загрузки страниц»: показывает TTFB и полное время загрузки по разделам сайта. Полезно для сравнения динамики после изменений.
- Uptime Robot + PageSpeed API: можно настроить автоматическую проверку Performance Score раз в сутки с алертом при падении ниже порога. Бесплатно на уровне одного сайта.
- Регрессионные тесты в CI/CD: для разработчиков — запуск Lighthouse в GitHub Actions при каждом деплое блокирует выкатку, если Performance < 90.
На проектах, которые мы ведём на техподдержке, мониторинг производительности входит в стандартный отчёт. Клиент получает ежемесячный срез CWV-показателей с пояснением динамики.
Core Web Vitals и новый сайт: как получить зелёные метрики с первого дня
Исправлять CWV на существующем сайте дороже, чем заложить правильные технические решения при разработке. Если вы сейчас заказываете новый сайт — убедитесь, что в техническом задании прописаны конкретные пороги:
- Performance Mobile ≥ 90 (PageSpeed Insights)
- LCP ≤ 2.5 секунды
- CLS = 0
- INP ≤ 200 мс
- TTFB ≤ 300 мс
Это не экзотические требования — это базовый профессиональный стандарт в 2026 году. В нашем процессе разработки Lighthouse-аудит проходит перед каждым релизом, и сдача проекта клиенту невозможна без зелёных показателей.
Часто задаваемые вопросы про Core Web Vitals
Влияют ли Core Web Vitals на позиции в Яндексе?
Прямого подтверждения от Яндекса нет, но скорость загрузки учитывается через поведенческие факторы: если пользователи быстро уходят с медленного сайта — позиции падают. Используйте Яндекс.Вебмастер → «Метрика загрузки страниц» для мониторинга.
Насколько сильно CWV влияют на ранжирование Google?
Google публично называет CWV «small ranking signal» — небольшим сигналом. Контент, ссылки и E-E-A-T важнее. Но в нишах с высокой конкуренцией этот «небольшой сигнал» часто решает, кто занимает место 3, а кто — место 5.
Мой сайт медленный в PageSpeed, но позиции хорошие. Нужно ли что-то делать?
Да. CrUX собирает реальные данные — если ваши посетители в основном приходят с быстрым интернетом, синтетический PageSpeed покажет хуже, чем реальность. Проверьте данные в Search Console → Core Web Vitals: там видна реальная картина. Если там зелёный — повода для паники нет.
Сколько стоит улучшение Core Web Vitals?
Зависит от масштаба проблем. Базовая оптимизация (изображения, кеш, defer) на типовом WordPress-сайте — 20–30 часов работы, от 150 000 ₽. Сложная оптимизация с переносом хостинга и рефакторингом JS — 50–80 часов. В нашем пакете технической поддержки базовая оптимизация производительности включена в стандартный тариф.
Можно ли получить 100 баллов в PageSpeed Insights?
Технически да, но это не цель. 100/100 — лабораторный результат на синтетическом тесте. Реальные CWV из CrUX важнее. Цель — зелёные значения в Search Console (LCP ≤ 2.5с, CLS ≤ 0.1, INP ≤ 200 мс) по реальным данным ваших пользователей.
Помогают ли плагины ускорения WordPress (WP Rocket и др.)?
Да, это один из самых эффективных рычагов на WordPress. WP Rocket, FlyingPress или LiteSpeed Cache дают прирост 20–40 баллов PageSpeed без изменения кода. Но они не заменяют правильную оптимизацию изображений и нормальный хостинг — это три разных слоя. Оптимальный стек: хороший VPS + Redis-кеш + WP Rocket + ShortPixel для изображений. Все четыре компонента вместе дают максимальный результат.
Что делать, если сайт уже давно индексируется и CWV плохие?
Улучшение CWV даёт отложенный эффект: Google переиндексирует данные CrUX раз в 28 дней. После оптимизации ждите от 4 до 8 недель, чтобы увидеть изменение в Search Console. Позиции обычно корректируются в течение одного-двух плановых обновлений алгоритма. Не стоит ожидать мгновенного роста, но мониторинг начинайте сразу после внедрения изменений.
АйТи-Стандарт проводит аудит производительности и доводит CWV до зелёных значений. Если ваш сайт теряет позиции или конверсию из-за скорости — расскажите нам о задаче, оценим за 1 день.
→ Заказать аудит и оптимизацию производительности | Разработка быстрых сайтов с CWV ≥ 95 →
