Core Web Vitals — что это такое

Core Web Vitals — набор метрик Google для измерения качества пользовательского опыта на веб-страницах. Три показателя оценивают скорость загрузки основного контента, отзывчивость страницы на действия пользователя и визуальную стабильность верстки. С мая 2021 года Core Web Vitals входят в алгоритм ранжирования Google как часть сигнала Page Experience.

Что такое Core Web Vitals

Core Web Vitals — подмножество метрик Web Vitals которые Google выделил как наиболее важные для пользовательского опыта. Впервые анонсированы в мае 2020 года, вошли в алгоритм ранжирования в мае 2021 года.

Набор метрик не статичен — Google обновляет его по мере развития веб-стандартов и накопления данных о поведении пользователей. Последнее значимое изменение: в марте 2024 года метрика FID (First Input Delay) официально заменена на INP (Interaction to Next Paint) как более точный измеритель отзывчивости страницы.

Актуальный состав Core Web Vitals на 2024–2025 годы: LCP (Largest Contentful Paint) — скорость загрузки основного контента, INP (Interaction to Next Paint) — отзывчивость на взаимодействие, CLS (Cumulative Layout Shift) — визуальная стабильность.

Данные Core Web Vitals собираются двумя способами. Полевые данные (Field Data) — реальные измерения от пользователей Chrome собранные за последние 28 дней, доступны через Chrome User Experience Report (CrUX). Лабораторные данные (Lab Data) — измерения в контролируемых условиях, доступны через Lighthouse и PageSpeed Insights. Google использует для ранжирования полевые данные — реальный опыт реальных пользователей вашего сайта.

LCP — Largest Contentful Paint

LCP измеряет время от начала загрузки страницы до момента когда наибольший видимый элемент контента отрисован в области просмотра. Наибольший элемент — изображение, видео, блок текста — тот который занимает максимальную площадь в viewport при первой загрузке.

Пороговые значения LCP:

Оценка	Значение LCP
Хорошо (Good)	До 2,5 секунды
Требует улучшения (Needs Improvement)	2,5 — 4,0 секунды
Плохо (Poor)	Более 4,0 секунды

Google оценивает страницу по 75-му перцентилю полевых данных — то есть 75% посещений страницы должны укладываться в пороговое значение «хорошо» чтобы страница получила зелёную оценку.

• Что чаще всего является LCP-элементом: изображение в области hero-секции, большое фоновое изображение загружаемое через CSS, постер видео, крупный блок текста в первом экране. Для большинства коммерческих сайтов LCP-элемент — изображение в шапке или первом блоке страницы.
• Основные причины плохого LCP: медленный ответ сервера, блокирующие рендеринг ресурсы (CSS, JavaScript), медленная загрузка изображений, клиентский рендеринг контента (JavaScript генерирует контент после загрузки страницы).

INP — Interaction to Next Paint

INP измеряет общую отзывчивость страницы на все взаимодействия пользователя за время посещения. Отслеживает задержку от момента нажатия, клика или нажатия клавиши до следующей визуальной отрисовки страницы.

INP заменил FID (First Input Delay) в марте 2024 года. FID измерял только первое взаимодействие пользователя со страницей. INP оценивает все взаимодействия за сессию — это более полная характеристика отзывчивости.

Пороговые значения INP:

Оценка	Значение INP
Хорошо (Good)	До 200 миллисекунд
Требует улучшения (Needs Improvement)	200 — 500 миллисекунд
Плохо (Poor)	Более 500 миллисекунд

Высокий INP означает что страница долго реагирует на действия пользователя — кнопки не реагируют на клик, поля ввода запаздывают, меню открывается с задержкой. Основная причина — тяжёлые JavaScript-задачи блокирующие главный поток браузера.

CLS — Cumulative Layout Shift

CLS измеряет визуальную нестабильность страницы — насколько элементы смещаются в процессе загрузки без действия пользователя. Рассчитывается как сумма всех неожиданных смещений за время жизни страницы.

Пороговые значения CLS:

Оценка	Значение CLS
Хорошо (Good)	До 0,1
Требует улучшения (Needs Improvement)	0,1 — 0,25
Плохо (Poor)	Более 0,25

Типичные примеры CLS:

• баннер или объявление загружается после текста и сдвигает его вниз,
• изображение без заданных размеров появляется и смещает контент,
• шрифт загружается и меняет размер текста,
• кнопка появляется поверх текста на котором пользователь уже нажимал.

CLS — единственная метрика из трёх которая не измеряется в единицах времени. Значение 0,1 означает что 10% видимой площади viewport было затронуто смещением.

Как проверить Core Web Vitals сайта

Для проверки Core Web Vitals доступно несколько инструментов с разными возможностями и типами данных.

Google Search Console

Основной инструмент для мониторинга Core Web Vitals на production-сайте. Раздел «Основные интернет-показатели» (Core Web Vitals) в Google Search Console показывает полевые данные — реальные измерения от пользователей Chrome.

• Преимущество Search Console: данные агрегированы по группам похожих страниц (шаблонам), а не только по отдельным URL. Это позволяет выявить системные проблемы — например «все страницы категорий имеют плохой LCP» без необходимости проверять каждую страницу отдельно.
• Ограничение: Search Console показывает данные только для страниц с достаточным объёмом трафика из Chrome. Новые страницы и страницы с низким трафиком могут не иметь данных.
• Алгоритм работы с Search Console: откройте раздел «Основные интернет-показатели» → посмотрите количество URL со статусом «Плохо» и «Требует улучшения» → кликните на проблему → изучите список затронутых URL → для каждой группы проблем перейдите к проверке в PageSpeed Insights.

PageSpeed Insights

PageSpeed Insights (pagespeed.web.dev) — инструмент Google для анализа производительности отдельных страниц. Показывает и полевые данные из CrUX (если доступны), и лабораторные данные из Lighthouse.

Как использовать: введите URL страницы → дождитесь анализа → изучите раздел «Данные о реальных пользователях» (полевые данные) и раздел «Диагностика» (лабораторные данные с рекомендациями).

PageSpeed Insights показывает конкретные рекомендации по улучшению каждой метрики с оценкой потенциальной экономии в миллисекундах. Это прямое руководство к действию для разработчика.

Важно проверять как мобильную так и десктопную версию — Google использует для ранжирования мобильные данные (mobile-first indexing), и показатели мобильной версии обычно хуже десктопной.

Screaming Frog + PageSpeed Insights API

Для аудита Core Web Vitals на уровне всего сайта — не отдельных страниц — используют связку Screaming Frog SEO Spider с подключённым API PageSpeed Insights.

Настройка: в Screaming Frog перейдите в Конфигурация → Доступ к API → PageSpeed Insights → вставьте ключ API (получается в Google Cloud Console бесплатно) → выберите нужные группы метрик → запустите сканирование сайта.

После сканирования перейдите на вкладку PageSpeed → экспортируйте данные в CSV. В таблице отфильтруйте страницы по пороговым значениям: LCP более 4000 мс (плохо), INP более 500 мс (плохо), CLS более 0,25 (плохо).

Результат: полный список страниц не соответствующих пороговым значениям с конкретными рекомендациями по каждой странице. Screaming Frog также показывает потенциальную экономию в миллисекундах для каждой рекомендации — это позволяет приоритизировать задачи по ожидаемому эффекту.

Lighthouse

Lighthouse — инструмент аудита производительности встроенный в Chrome DevTools. Запуск: открыть DevTools (F12) → вкладка Lighthouse → выбрать категории → нажать «Analyze page load».

Lighthouse предоставляет только лабораторные данные — измерения в контролируемых условиях. Реальный пользовательский опыт может отличаться. Полезен для отладки во время разработки, но не для оценки фактического состояния production-сайта.

Chrome User Experience Report (CrUX)

CrUX — публичный датасет Google с реальными данными о производительности миллионов веб-сайтов. Обновляется ежемесячно. Доступен через BigQuery, Data Studio и API.

CrUX Dashboard — бесплатный инструмент на основе Looker Studio: достаточно ввести домен и получить исторический тренд Core Web Vitals за последние месяцы. Позволяет отслеживать динамику изменений после внедрения оптимизаций.

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

LCP — метрика наиболее чувствительная к оптимизации изображений и серверной производительности.

Оптимизация изображений. LCP-элемент в большинстве случаев — изображение. Современные форматы WebP и AVIF обеспечивают значительно меньший размер файла при сопоставимом визуальном качестве. WebP в среднем на 25–34% меньше JPEG, AVIF — на 50% меньше JPEG. Для WordPress автоматическую конвертацию обеспечивают плагины Imagify и ShortPixel.

Предзагрузка LCP-изображения. Добавьте тег preload для LCP-изображения в секцию head — это сообщает браузеру о необходимости приоритетной загрузки ресурса до начала полного парсинга страницы:

<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">

Атрибут fetchpriority=»high» (поддерживается современными браузерами) дополнительно повышает приоритет загрузки ресурса.

• Устранение блокирующих рендеринг ресурсов. CSS и JavaScript загружаемые в head страницы блокируют рендеринг до завершения их загрузки и выполнения. Решения: атрибут defer для JavaScript (откладывает выполнение до завершения парсинга HTML), атрибут async для некритичных скриптов, вынос критического CSS inline в head, асинхронная загрузка некритичного CSS.
• Быстрый ответ сервера (TTFB). TTFB (Time to First Byte) — время до получения первого байта от сервера — напрямую влияет на LCP. Оптимизация: серверное кэширование (LiteSpeed Cache, Redis), CDN для статических ресурсов, хостинг с серверами ближе к целевой аудитории. Хороший TTFB — менее 800 мс.
• Lazy loading только для некритичных изображений. Атрибут loading=»lazy» откладывает загрузку изображений за пределами viewport. Критическая ошибка — применять lazy loading к LCP-изображению. Это прямо задерживает загрузку главного контента и ухудшает LCP. LCP-изображение должно загружаться с высоким приоритетом, а не откладываться.
• Размеры изображений адаптированные к устройству. Атрибуты srcset и sizes позволяют браузеру загружать изображение оптимального размера для конкретного устройства — мобильный телефон не загружает десктопное изображение 2000px шириной:

<img src="hero-800.webp"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
     alt="Hero image" fetchpriority="high">

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

INP определяется состоянием главного потока браузера (main thread). Долгие JavaScript-задачи блокируют main thread и не позволяют браузеру быстро обработать пользовательское взаимодействие и перерисовать страницу.

• Разбиение долгих задач (Long Tasks). Задача JavaScript выполняющаяся более 50 мс считается долгой и блокирует main thread. Chrome DevTools → вкладка Performance → записать сессию взаимодействия с страницей → найти Long Tasks (красные маркеры) → определить какой код их вызывает.

Долгие задачи разбиваются через scheduler API или setTimeout с нулевой задержкой — это создаёт точки уступки где браузер может обработать пользовательский ввод:

function processInChunks(items) {
    const chunk = items.splice(0, 100);
    processChunk(chunk);
    if (items.length > 0) {
        setTimeout(() => processInChunks(items), 0);
    }
}

• Уменьшение объёма JavaScript. Каждый килобайт JavaScript — это парсинг, компиляция и выполнение на main thread. Аудит JavaScript-бандла: Chrome DevTools → Coverage — показывает процент неиспользуемого кода на странице. Tree-shaking, code splitting, удаление неиспользуемых зависимостей.
• Оптимизация сторонних скриптов. Сторонние скрипты — аналитика, чаты, виджеты, рекламные системы — частая причина высокого INP. Каждый сторонний скрипт выполняется на main thread и конкурирует с кодом самой страницы. Решения: загрузка через Partytown (выносит сторонние скрипты в Web Worker), отложенная загрузка (загружать после взаимодействия пользователя), аудит необходимости каждого скрипта.
• Виртуализация длинных списков. Рендеринг сотен DOM-элементов одновременно увеличивает время отрисовки. Виртуализация (react-window, react-virtual) рендерит только элементы видимые в viewport, создавая иллюзию полного списка при многократно меньшей нагрузке на браузер.
• CSS-анимации вместо JavaScript-анимаций. CSS-анимации свойств transform и opacity выполняются на GPU в отдельном потоке без блокировки main thread. JavaScript-анимации через setInterval или requestAnimationFrame конкурируют с основным кодом за main thread.

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

CLS вызывается неожиданными смещениями элементов страницы во время загрузки. Устранение CLS — в большинстве случаев задача CSS и разметки, а не производительности JavaScript.

• Явные размеры для изображений и видео. Основная причина CLS — изображения без указанных атрибутов width и height. Браузер не знает размер изображения до его загрузки и не резервирует под него место. Когда изображение загружается — оно раздвигает контент. Решение:

<img src="photo.webp" width="800" height="600" alt="Фото">

Или через CSS aspect-ratio:

.hero-image {
    aspect-ratio: 4 / 3;
    width: 100%;
}

• Резервирование места для рекламы и виджетов. Рекламные блоки загружаемые после контента смещают страницу. Решение — резервировать место под блок через CSS min-height до загрузки рекламы:

.ad-slot {
    min-height: 250px;
    width: 100%;
}

• Предзагрузка веб-шрифтов. Смена системного шрифта на веб-шрифт после его загрузки вызывает FOUT (Flash of Unstyled Text) и смещение контента из-за разницы в метриках шрифтов. Решения: preload для критичных шрифтов, font-display: optional (показывает только загруженный шрифт без замены), font-display: swap с настроенными size-adjust для минимизации смещения.
• Анимации через transform, а не через изменение позиции. Анимации меняющие top, left, margin, padding вызывают reflow и могут провоцировать смещение соседних элементов. Анимации через CSS transform: translate() перемещают элемент визуально не влияя на поток документа и не вызывая CLS.
• Динамический контент над fold. Если JavaScript добавляет элементы в начало или середину страницы после загрузки — это вызывает CLS. Новый контент должен добавляться ниже fold или в заранее зарезервированные контейнеры.

Core Web Vitals и ранжирование Google

Core Web Vitals входят в алгоритм Page Experience Update который Google запустил в мае 2021 года для десктопа и мобильных устройств. Page Experience — агрегированный сигнал включающий Core Web Vitals, HTTPS, отсутствие агрессивных межстраничных объявлений.

Google неоднократно подчёркивал: Page Experience — сигнал ранжирования, но не единственный и не самый мощный. Страница с отличным контентом но плохими Core Web Vitals будет ранжироваться выше страницы с посредственным контентом и хорошими метриками. Улучшение Core Web Vitals не заменяет работу над качеством контента, ссылочным профилем и другими факторами ранжирования.

Прямой эффект Core Web Vitals на позиции сложно изолировать — алгоритм учитывает сотни сигналов одновременно. Исследования SEO-сообщества показывают умеренную корреляцию между хорошими Core Web Vitals и позициями в топе, но причинно-следственная связь неоднозначна: сайты с хорошими Core Web Vitals как правило лучше оптимизированы в целом.

Практическая ценность Core Web Vitals выходит за рамки SEO. Быстрый сайт с хорошей отзывчивостью и стабильной версткой напрямую улучшает конверсию. Исследования Google показывают: снижение времени загрузки с 3 до 1 секунды повышает конверсию мобильных пользователей на 27%. Bounce rate снижается на 32% при переходе от 1 к 3 секундам загрузки.

Мониторинг Core Web Vitals — постоянная задача а не разовая оптимизация. Обновления сайта, новые плагины, изменения в теме, новый контент — всё это может ухудшить метрики. Еженедельный мониторинг через Google Search Console и месячный аудит через PageSpeed Insights позволяют отслеживать деградацию показателей до того как она повлияет на позиции.