Core Web Vitals (основные интернет-показатели) — это набор метрик, которыми Google оценивает реальный пользовательский опыт на странице. Их три, и каждая отвечает на свой вопрос: как быстро появился главный контент, как быстро страница реагирует на действия и не «прыгает» ли макет во время загрузки. Метрики входят в сигналы удобства страницы в Google и полезны как объективный ориентир для любой оптимизации.
Три метрики и их пороги
| Метрика | Что измеряет | Хорошо | Нужно улучшить | Плохо |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Время отрисовки самого крупного элемента первого экрана | ≤ 2,5 с | 2,5–4 с | > 4 с |
| INP (Interaction to Next Paint) | Задержка между действием пользователя и обновлением экрана | ≤ 200 мс | 200–500 мс | > 500 мс |
| CLS (Cumulative Layout Shift) | Суммарные неожиданные сдвиги макета | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Страница проходит оценку, если 75 % визитов укладываются в «хорошую» зону по всем трём метрикам. Мобильные устройства и десктопы оцениваются отдельно. В марте 2024 года INP заменил прежнюю метрику FID.
Полевые и лабораторные данные
Это главный источник путаницы.
- Полевые данные (field data) — статистика реальных пользователей Chrome из отчёта CrUX за последние 28 дней. Их показывают PageSpeed Insights (блок «Данные о реальных пользователях») и отчёт «Основные интернет-показатели» в Google Search Console. Именно они используются в поиске.
- Лабораторные данные (lab data) — один замер Lighthouse в эмуляции: определённый телефон, определённая скорость сети. Удобно для отладки, но это не то, что видят пользователи.
INP вообще нельзя честно измерить в лаборатории — нужен реальный пользователь, который нажимает кнопки. В лабораторном отчёте его заменяет косвенная метрика TBT (общее время блокировки).
Если у сайта мало трафика, полевых данных по отдельному URL может не быть — тогда Google использует данные по группе похожих страниц или по сайту целиком.
Быстрый лабораторный замер можно сделать в нашей проверке скорости сайта.
Как улучшить LCP
LCP-элемент — обычно главный баннер, крупное фото товара или заголовок. Время LCP складывается из четырёх частей: ответ сервера, задержка начала загрузки ресурса, сама загрузка и отрисовка.
- Ускорьте ответ сервера. TTFB больше 0,8 секунды съедает треть бюджета. Помогают кэш страниц, более быстрый хостинг, сервер ближе к аудитории.
- Не прячьте LCP-изображение. Оно должно быть в HTML как
<img>, а не подгружаться скриптом или как фон в CSS. - Дайте ему приоритет:
<img src="/img/hero-1200.avif" width="1200" height="600"
fetchpriority="high" alt="Новая коллекция">
- Не ставьте
loading="lazy"на главное изображение первого экрана. - Облегчите файл: правильный размер, формат WebP или AVIF.
- Уберите блокирующие ресурсы: тяжёлый CSS, синхронные скрипты в
<head>, шрифты безfont-display.
Как улучшить INP
INP показывает, насколько «вязкой» ощущается страница. Плохой INP почти всегда означает одно: основной поток браузера занят выполнением JavaScript.
- Разбивайте длинные задачи. Задача дольше 50 мс блокирует отклик. Тяжёлые вычисления делите на части или переносите в Web Worker.
- Сокращайте сторонние скрипты. Чаты, виджеты, A/B-тесты, рекламные теги — частые виновники.
- Сначала обновляйте интерфейс, потом делайте тяжёлую работу. Покажите, что нажатие принято, а отправку аналитики отложите.
- Уменьшите DOM. Страница с десятками тысяч элементов медленнее перерисовывается.
- Проверяйте на среднем Android-смартфоне, а не на мощном ноутбуке разработчика.
Как улучшить CLS
Сдвиг макета — это когда вы собираетесь нажать кнопку, а она уезжает вниз из-за подгрузившегося баннера.
- Задавайте
widthиheight(илиaspect-ratio) всем изображениям, видео и iframe. - Резервируйте место под рекламные блоки и виджеты заранее.
- Не вставляйте контент над уже показанным (например, плашку cookie сверху страницы — лучше снизу поверх контента).
- Для шрифтов используйте
font-display: swapвместе с подобранным запасным шрифтом, чтобы смена шрифта не меняла высоту строк. - Анимируйте через
transform, а не черезtop,heightилиmargin.
Сдвиги в течение 500 мс после действия пользователя (например, раскрытие меню по клику) в CLS не учитываются.
Как найти проблемные страницы
Работать по одной странице неэффективно — проблемы обычно повторяются на целом шаблоне.
- Откройте в Google Search Console отчёт «Основные интернет-показатели». Он группирует URL с похожими проблемами: например, «LCP больше 4 с (мобильные)» для всех карточек товаров.
- Возьмите один пример из группы и проверьте его в PageSpeed Insights или в нашей проверке скорости: лабораторный отчёт покажет, какой элемент стал LCP, какие скрипты блокируют поток и какие элементы сдвигаются.
- Исправьте шаблон (а не отдельную страницу) и нажмите «Проверить исправление» в Search Console — начнётся 28-дневный период наблюдения.
- Для точной диагностики INP подключите библиотеку
web-vitalsи отправляйте метрики реальных пользователей в свою аналитику. Так вы увидите, какие именно элементы — кнопка «В корзину», фильтр каталога, меню — дают медленный отклик.
В Chrome DevTools на вкладке Performance можно включить замедление процессора в 4–6 раз, чтобы увидеть сайт глазами владельца бюджетного смартфона.
Типичные ошибки
- Ориентироваться только на балл Lighthouse вместо полевых данных.
- Ждать изменений в Search Console на следующий день: данные накапливаются 28 дней.
- Оптимизировать десктоп, когда проблемы на мобильных.
- Подгружать главный баннер через JavaScript-слайдер.
- Добавлять «ускоряющие» плагины, которые сами внедряют много скриптов.
Чек-лист
- Посмотрели полевые данные в PageSpeed Insights и Search Console.
- Определили LCP-элемент для ключевых шаблонов страниц.
- LCP-изображение в HTML, с
fetchpriority="high", без ленивой загрузки. - TTFB меньше 0,8 секунды.
- Лишние сторонние скрипты удалены или отложены.
- У всех медиа заданы размеры, место под баннеры зарезервировано.
- После исправлений отслеживаете метрики не меньше 28 дней.
Core Web Vitals — часть общей работы над скоростью. Пошаговый план для всего сайта — в гайде Как ускорить сайт, а про облегчение картинок — в материале Оптимизация изображений.