Core Web Vitals — три метрики Google, по которым он оценивает удобство сайта для реальных пользователей: LCP (когда виден главный блок первого экрана), INP (насколько сайт быстро реагирует на клики и тапы, заменил FID в марте 2024), CLS (насколько прыгает вёрстка при загрузке). Пороги: LCP до 2.5 сек, INP до 200 мс, CLS до 0.1. Мерить надо полевые данные (CrUX / GSC → «Основные интернет-показатели»), а не только PageSpeed Insights одной страницы. Плохие CWV = красная зона в GSC и просадка позиций на конкурентных запросах. Чинится в 80% случаев тремя правками: не грузить hero-картинку лениво, вынести тяжёлые скрипты после First Paint, зарезервировать место под баннеры и iframe.
Каждый второй сайт, который ко мне приходит на аудит, лежит в красной зоне по Core Web Vitals — и владелец даже не в курсе, что такие метрики существуют. Между тем это не «маркетинговая штука Google», а фактор ранжирования: при прочих равных сайт с зелёными показателями обгоняет сайт с красными. Разница на конкурентных запросах — 2-5 позиций стабильно, я мерил.
Дальше — что это за метрики, где реально их посмотреть (не в PSI на одну страницу, а полевые данные по всему сайту), какие пороги считаются «зелёными» в 2026, откуда обычно берутся плохие значения и что чинить в первую очередь. Без «включите gzip» и «оптимизируйте JavaScript» на общих словах.
Что такое Core Web Vitals и зачем они Google
Core Web Vitals (CWV) — набор из трёх метрик, которые Google собирает у реальных пользователей Chrome через CrUX (Chrome User Experience Report) и использует как один из сигналов ранжирования в блоке Page Experience. Официально это подтверждено с 2021 года, никаких секретов.
Логика простая: если сайт медленный, дёргается или не реагирует на тапы — пользователь закрывает вкладку. Google хочет отдавать людям сайты, где они остаются. Значит, среди двух похожих по релевантности страниц предпочтение — той, что грузится быстрее и не бесит.
В 2026 в наборе три метрики. Две — про скорость (LCP и INP), одна — про стабильность (CLS). У каждой три зоны: Good (зелёная — хорошо), Needs Improvement (жёлтая — терпимо), Poor (красная — плохо). Чтобы страница считалась «здоровой», ВСЕ три метрики должны быть в зелёной зоне у 75% пользователей за последние 28 дней.
LCP — Largest Contentful Paint (загрузка главного блока)
LCP отвечает на вопрос: через сколько миллисекунд пользователь видит основной контент первого экрана? «Основной» — самый крупный видимый элемент: обычно hero-картинка, крупный H1 с фоном или главный видео-баннер.
Пороги в 2026:
| Зона | LCP | Что значит |
|---|---|---|
| Good | ≤ 2.5 сек | Пользователь видит контент быстро, вопросов нет |
| Needs Improvement | 2.5-4.0 сек | Терпимо, но есть куда расти |
| Poor | > 4.0 сек | Красная зона, GSC ругается, ранжирование страдает |
Типовые причины плохого LCP на белорусских и российских сайтах:
- Hero-картинка загружается лениво (
loading="lazy"). Классика: разработчик прочитал «ставь lazy на все картинки, будет быстрее» и повесил lazy на первый экран. Итог: браузер откладывает загрузку, LCP улетает в 3-5 секунд. Правило:loading="lazy"только для картинок НИЖЕ первого экрана. Hero —loading="eager"плюсfetchpriority="high". - Огромные несжатые JPEG/PNG. Hero весом 800 КБ на канале 3G грузится 4-6 секунд. Норма для hero — 80-150 КБ WebP или AVIF при исходном разрешении 1920×1080. Уменьшил вес в 6 раз — LCP сократился с 3.8 до 1.6 секунд у клиента 09-16, проверено.
- Тяжёлые сторонние шрифты, которые блокируют рендер. Подключён Google Fonts без
font-display: swap— браузер ждёт загрузки шрифта, чтобы отрисовать текст. Плюс несколько килобайт CSS-заказа сверху. Фикс: локальные шрифты +font-display: swap, либо system-fonts стек, если брендинг терпит. - Тяжёлый CSS-файл на 300+ КБ. Классика на Bitrix / WordPress: подключены 5 плагинов, каждый тащит свой стиль, финальный
main.css— 400 КБ. Пока не загрузился — рендера нет. Правь через критический CSS (первый экран inline в<head>) и деферни остальное. - Сервер тупит. TTFB (время до первого байта) > 800 мс — половина LCP уходит на ожидание сервера. Причина обычно в неоптимизированной админке (Bitrix админ-панель тянет 20 запросов в БД на каждый визит) или на shared-хостинге в час пик. Решается кэшем и/или переездом на нормальный VPS.
INP — Interaction to Next Paint (отзывчивость)
Метрика новая: INP заменил FID в марте 2024. FID мерил только первое взаимодействие, INP — весь цикл: как быстро сайт реагирует на любой клик, тап или нажатие клавиши в течение всей сессии. Более честная метрика.
Формально: INP — задержка между действием пользователя и следующим отрисованным кадром, взятая по 98-му перцентилю всех взаимодействий за визит. Проще: сколько миллисекунд пользователь ждёт, пока сайт «отвиснет», когда он тапает по кнопке или открывает меню.
| Зона | INP | Что значит |
|---|---|---|
| Good | ≤ 200 мс | Реакция моментальная, пользователь не замечает |
| Needs Improvement | 200-500 мс | Заметное подтормаживание |
| Poor | > 500 мс | «Сайт лагает», раздражает |
INP чинится сложнее LCP, потому что причина обычно — тяжёлые JavaScript-обработчики, которые блокируют main thread во время взаимодействия. Типовые виновники:
- Тяжёлые аналитические скрипты, которые не деферились. Метрика + GTM + FB Pixel + Hotjar + куча пикселей ретаргетинга — всё это грузится синхронно, парсится, инициализируется. При каждом клике часть кода выполняется, main thread блокирован. Фикс:
deferилиasyncна всех сторонних скриптах, инициализация послеDOMContentLoaded. - Big JS-фреймворки на статичном сайте. Подключён React или Vue на сайте с формой обратной связи и парой картинок. Бандл 300 КБ гидратируется на каждой странице. INP улетает. Правь через переход на нативный JS для простых сайтов, либо через код-сплиттинг, если фреймворк реально нужен.
- Долгие обработчики
onclick. Клик по кнопке запускает функцию, которая делает 5 сетевых запросов подряд, парсит JSON, перерисовывает половину DOM. Пользователь ждёт секунду, пока меню откроется. Правь через: (1) вынести тяжёлые вычисления вrequestIdleCallback, (2) разбить длинные задачи черезsetTimeout, (3) не блокировать UI, отдавать промежуточный feedback. - Popup-формы и модалки на «тяжёлых» библиотеках. Модалку подключили через Bootstrap + jQuery + плагин с 50 КБ CSS — при открытии всё это парсится. Замена на 20 строк нативного JS убирает 300 мс из INP.
- Реклама в контенте, которая перестраивается на каждый скролл. AdSense-блоки с дополнительной автозагрузкой контента при видимости — регулярно генерируют долгие задачи. Смягчается через
content-visibility: autoна контейнерах вне первого экрана.
CLS — Cumulative Layout Shift (прыгающая вёрстка)
CLS мерит, насколько вёрстка «прыгает» после первой отрисовки. Классическая раздражающая ситуация: открываешь статью, начинаешь читать, через секунду сверху загружается баннер и весь текст скачет вниз. Ты промахиваешься по кнопке. Пользователь бесится, закрывает вкладку.
Метрика — безразмерная (произведение сдвинутой площади на дистанцию сдвига), в 2026 пороги:
| Зона | CLS | Что значит |
|---|---|---|
| Good | ≤ 0.1 | Мелкие визуальные сдвиги, незаметно |
| Needs Improvement | 0.1-0.25 | Есть заметные прыжки |
| Poor | > 0.25 | Вёрстка скачет постоянно, пользователь бесится |
Причины плохого CLS в 90% случаев:
- Картинки без указанных
widthиheight. Браузер не знает, сколько места зарезервировать, размещает контент, потом картинка догружается — сдвигает всё вниз. Указывай реальные размеры атрибутами. Это работает и в 2026: браузер вычисляет aspect-ratio и держит место, пока картинка грузится. - Динамически подгружаемые баннеры/iframe. Рекламный блок или встроенное видео вставляются через JS после DOMContentLoaded. Место под них не зарезервировано — контент едет. Фикс: указать
min-heightконтейнеру заранее (400px для баннера, 315px для youtube-iframe и т.д.). - Веб-шрифты, которые сильно отличаются габаритами от fallback-шрифта. Пока грузится Circe, показывается Arial, буквы шире/уже, строки перестраиваются. Смягчается через
size-adjustв@font-face— подгоняешь fallback под метрики целевого шрифта. - Модалки/попапы/куки-баннеры, которые появляются с задержкой. Куки-баннер прилетает сверху через 2 секунды после загрузки, весь контент едет вниз. Решение: рендерить баннер сразу (может быть скрыт CSS до готовности), либо позиционировать
fixed, чтобы он не влиял на layout. - Формы с валидацией, которая добавляет сообщения об ошибке. Ошибка вылезает под инпутом, сдвигая submit-кнопку. Резервируй место под возможные ошибки заранее.
Где смотреть Core Web Vitals: 4 инструмента
Порядок важен: сначала полевые данные (то, что реально видит Google по 75% пользователей), потом лабораторные (для дебага конкретной страницы).
1. Google Search Console → «Основные интернет-показатели»
Главный отчёт. GSC агрегирует полевые данные CrUX по всему сайту, показывает разбивку на «Хорошие», «Требуют улучшения» и «Плохие» URL — отдельно для мобильных и десктопа. Даёт список конкретных URL в каждой категории.
Открывай раз в неделю, смотри тренд. Резкий рост «плохих» URL после релиза — сигнал, что что-то сломалось. Обычно новая версия темы или новый плагин зацепил hero-изображение или добавил скрипт, который блокирует thread.
2. PageSpeed Insights (pagespeed.web.dev)
Открываешь конкретный URL, получаешь и полевые данные (если они есть у CrUX для этой страницы), и лабораторный тест. Плюс — конкретный список проблем и рекомендаций.
Осторожно: лабораторный балл 95+ ≠ зелёные CWV в поле. У свежих или малопосещаемых сайтов CrUX-данных нет, тогда Google берёт только лабораторные. Не расслабляйся: то, что «в лабораторных 90», не значит, что у 75% пользователей всё хорошо на 4G-соединении в Гомеле.
3. Chrome DevTools → Lighthouse + Performance
Для дебага. Lighthouse-отчёт даёт тот же аналог PSI, но локально. Performance-таб — единственный способ увидеть, что реально происходит в main thread во время загрузки и взаимодействий. Смотри «Long Tasks» и «Layout Shift» в таймлайне.
4. web-vitals JS-библиотека (для своей телеметрии)
Библиотека от Google — 3 КБ, ставится через <script>. Собирает LCP, INP, CLS для КАЖДОГО реального визита и отправляет в Метрику/GA как события. Полезно для крупных сайтов: видишь метрики в разрезе страниц, устройств, географии. Для малых сайтов достаточно GSC + PSI.
Что чинить в первую очередь: приоритеты
На реальном аудите я обычно нахожу 10-20 проблем разного калибра. Всё сразу чинить невозможно — расставляй приоритет по правилу: максимум эффекта / минимум работы. Порядок обычно такой:
- Hero-картинка (первое, 30 минут работы, сразу минус 1-2 сек к LCP). Убрать
loading="lazy", поставитьfetchpriority="high", пережать в WebP до 100-150 КБ, указатьwidth/height. Это самый быстрый и большой выигрыш. - Все картинки в атрибутах
width/height(полдня работы, CLS падает до нуля). Прогоняешь HTML-темплейты и посты, где картинки без размеров, добавляешь. В CMS обычно есть плагин, который делает это автоматом при загрузке в медиатеку. - Дефер всех сторонних скриптов (час, INP улучшается сразу). Метрика, GTM, чат-виджеты, пиксели — всё через
asyncилиdefer. Метрика — толькоasync, чтобы не терять первые визиты. Всё остальное —defer. Инициализируй послеDOMContentLoaded. - Резерв места под баннеры и iframe (2 часа). Проходишь по всем страницам, где вставляются AdSense, YouTube, карта Яндекса — ставишь контейнерам
min-height. CLS падает. - Критический CSS в
<head>inline (полдня, LCP улучшается ещё на 0.5-1 сек). Извлекаешь CSS первого экрана (можно через инструментcriticalили руками), инлайнишь в head, остальной CSS деферишь. Работает для сайтов, где CSS-бандл > 100 КБ. - WebP/AVIF на все изображения (2 дня, LCP+TTFB на всех страницах вниз). Пережимаешь всю медиатеку, отдаёшь через
<picture>с фолбэком на JPG для старых Safari. Средний вес страницы уходит на 40-60%. - Разбирать долгие JS-задачи (день на страницу, INP чинится точечно). Уже когда всё выше сделано, если INP всё ещё в жёлтой зоне — идёшь в Performance-таб и находишь конкретные функции, которые блокируют thread. Это самая долгая часть, оставляй на потом.
По моим клиентам: первые три пункта обычно вытаскивают сайт из красной зоны в жёлтую или зелёную за 2-3 дня работы. Дальше — тонкая настройка, если хочется зелёного во всех трёх метриках у 90%+ пользователей.
Частые вопросы
Core Web Vitals — это фактор ранжирования на самом деле?
Да, официально с 2021 года подтверждён как один из сигналов Page Experience. Но не решающий: релевантность и авторитет важнее. Если у тебя контент лучше конкурентов — обгонишь их и с жёлтыми CWV. Если контент паритетный — зелёные CWV дают преимущество. На конкурентных коммерческих запросах разница в позициях от 1 до 5.
Яндекс учитывает Core Web Vitals?
Формально нет — у Яндекса свой набор факторов, включая поведенческие (Метрика видит бегство пользователей). По факту: медленный сайт даёт худшие поведенческие метрики (отказы, время на сайте), и Яндекс это учитывает косвенно. Плюс с 2023 у Яндекса в Вебмастере появился раздел «Скорость загрузки», где показываются похожие на CWV метрики. Не игнорируй.
У меня всё зелёное в PageSpeed Insights, но в GSC — красная зона. Почему?
PSI показывает результаты одного теста в дата-центре Google, обычно 4G-профиль эмулируется. GSC берёт реальных пользователей: 3G, старые смартфоны, слабый Wi-Fi. Полевые данные всегда хуже лабораторных. Ориентируйся на GSC — там правда о том, что видят пользователи.
Сколько времени занимает вывести сайт в зелёную зону?
Средний сайт услуг (10-30 страниц) — 3-5 дней работы. Интернет-магазин с сотнями товаров — 2-3 недели. Особенности: у e-commerce обычно проблема в тяжёлых скриптах корзины и фильтров, чинить дольше. Плюс переиндексация занимает 28 дней (CrUX собирает данные за скользящее окно).
Есть ли смысл ставить web-vitals JS на маленький сайт?
Нет. Для сайтов до 5000 визитов/месяц данных в CrUX часто мало, но и в web-vitals-скрипте выборка будет крошечная. Хватит GSC + PSI по 5-10 ключевым страницам раз в месяц. Собственная телеметрия оправдана от 20-30k визитов/мес.
Core Web Vitals — это не «оптимизируйте всё что можно». Это про 3 конкретные цифры и 5-7 правок, которые дают 80% результата. LCP и CLS чинятся руками разработчика за неделю, INP — сложнее, но начинай с дефера всех аналитических скриптов, дальше по ситуации. Красная зона в GSC — не приговор, но игнорировать её глупо: конкуренты уже фиксят.
Нужен разбор твоего сайта по Core Web Vitals с приоритетным списком правок — mostlycorp@gmail.com или форма ниже. Экспресс-аудит с планом фиксов — 150-300 BYN, полная реализация правок — от 300 BYN в зависимости от объёма.