Животные меняются при загрузке страницы
Core Web Vitals: Как собрать данные и интерпретировать их для улучшения ранжирования
Карточки, чек-листы, таблицы и примеры помогают быстро найти нужный ответ.
Core Web Vitals (CWV) – набор пользовательских метрик, которые Google использует как фактор ранжирования. Понимание того, как собрать, проанализировать и улучшить эти показатели, позволяет владельцам сайтов, разработчикам и SEO‑специалистам более точно управлять качеством пользовательского опыта.
Собрать CWV можно через Lighthouse, PageSpeed Insights, Web Vitals API и Яндекс Метрику. Далее следует проанализировать LCP, FID, CLS, определить узкие места, исправить их, а затем настроить постоянный мониторинг.
Что такое Core Web Vitals и почему они важны
Core Web Vitals – это набор измерений, которые показывают, насколько быстро и надёжно пользователи видят и взаимодействуют с контентом страницы. Включает три ключевых показателя: Largest Contentful Paint (LCP) – время, когда самый крупный элемент становится видимым; First Input Delay (FID) – задержка первого пользовательского взаимодействия; Cumulative Layout Shift (CLS) – суммарная нестабильность макета. Google использует эти метрики как часть сигнала «Page Experience» и напрямую учитывает их при ранжировании. Чем выше показатели LCP, FID и CLS, тем более плавным считается пользовательский опыт, что снижает показатель отказов, увеличивает время на странице и повышает вероятность того, что поисковая система отдаст странице более высокий рейтинг в результатах поиска.
| Показатель | Что измеряет | Оптимальный порог |
|---|---|---|
| LCP | Время загрузки крупнейшего видимого элемента | ≤ 2.5 с |
| FID | Задержка первого взаимодействия пользователя | ≤ 100 мс |
| CLS | Нестабильность макета во время загрузки | ≤ 0.1 |
Подготовка к сбору данных
- Доступ к Google Search Console и API Core Web Vitals.
- Google Analytics 4 с настройкой событий.
- Chrome DevTools и Lighthouse в локальной среде.
- Сервер с HTTPS и поддержкой Service Worker.
- Репозиторий кода с веткой staging.
- Инструмент для анализа производительности (WebPageTest, SpeedCurve).
- Права на редактирование manifest.json и сервис‑воркера.
- Настроенный CI/CD для автоматической сборки и деплоя.
- Конфигурация Cloudflare / CDN для кеширования.
- Проверка индексации через robots.txt и sitemap.xml.
- Выбрать инструменты: Lighthouse, WebPageTest, SpeedCurve, Google Search Console API.
- Создать сервисный аккаунт в Google Cloud и добавить ключ в переменные окружения.
- Настроить Lighthouse CI в репозитории: добавить .lighthouserc.json и скрипт в package.json.
- Подключить Google Analytics 4 к сайту и убедиться, что события FCP, LCP, CLS фиксируются.
- Включить HTTPS, добавить manifest.json и Service Worker в корень.
- Настроить CDN с правилами кеширования для статических ресурсов.
- Включить тесты производительности в CI: запуск Lighthouse CI и отправка результатов в GitHub Actions.
- Проверить, что сайт доступен для поисковых ботов: robots.txt разрешает index, sitemap.xml актуален.
- Запустить локальный сервер и проверить Core Web Vitals через DevTools Performance panel.
- Сохранить результаты в репозиторий как отчёты.
Как читать метрики LCP, FID, CLS
- Запустите Chrome DevTools → вкладка Performance → нажмите Record. Перейдите по URL страницы, которую хотите проверить. После остановки записи найдите событие «Largest Contentful Paint». Это LCP. Если его время > 2.5 с, страница считается медленной.
- В той же вкладке Performance найдите «First Input Delay» – это FID. Значение > 100 мс указывает на задержку первой реакции пользователя.
- В Performance откройте раздел Layout Shifts. Суммарный CLS определяется как сумма всех значений shift. Если CLS > 0.1, пользователь может ощущать «скачки» контента.
- Перейдите в Google Search Console → Core Web Vitals → Top pages. Здесь отображаются средние значения LCP, FID, CLS за последние 28 дней. Сравните их с порогами: LCP ≤ 2.5 с, FID ≤ 100 мс, CLS ≤ 0.1.
- Для проверки в реальных условиях откройте PageSpeed Insights → вкладка Core Web Vitals. Метрика «Largest Contentful Paint» будет в секции LCP, «First Input Delay» – в FID, «Cumulative Layout Shift» – в CLS. Пороги аналогичные, но отображаются в виде «Good», «Needs improvement».
- Если любая из метрик превышает порог, запишите конкретный элемент, вызывающий проблему: в DevTools найдите элемент, отмеченный как LCP, проверьте его размер и время загрузки; для CLS посмотрите, какие изображения/шрифты перемещаются.
- После оптимизации повторите шаги 1–5, чтобы убедиться, что значения перешли в «Good» диапазон. Храните результаты в таблице для отслеживания прогресса.
Скрипт для сбора CWV через Web Vitals API
Для сбора Core Web Vitals в продакшене удобно использовать Web Vitals API. Он возвращает точные значения LCP, FCP, CLS, FID и позволяет сразу отправлять их в аналитику. В примере ниже показано, как подключить библиотеку, обрабатывать метрики и отправлять данные в Google Analytics (gtag) и в собственный эндпоинт. Вставьте скрипт в основной JS‑bundle или в отдельный файл с атрибутом async defer, чтобы он не блокировал рендеринг. Убедитесь, что сайт обслуживается по HTTPS и, если это PWA, что Service Worker не кеширует этот скрипт, иначе метрики будут собраны только при первом посещении.
import { getCLS, getFID, getLCP, getFCP } from 'web-vitals';
function sendToAnalytics(metric) {
const { name, value, id, delta } = metric;
const page = window.location.pathname;
// Google Analytics (gtag)
gtag('event', 'web_vital', {
event_category: name,
event_label: page,
value: Math.round(name === 'CLS' ? value * 1000 : value),
non_interaction: true
});
// Custom endpoint
fetch('https://example.com/api/web-vitals', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ name, value, delta, id, page })
});
}
getCLS(sendToAnalytics);
getFID(sendToAnalytics);
getLCP(sendToAnalytics);
getFCP(sendToAnalytics);
Чеклист оценки текущего состояния сайта
- Собрать данные Core Web Vitals за последние 28 дней через API Search Console.
- Проверить LCP, FID, CLS в Google Search Console → раздел “Core Web Vitals”.
- Запустить Lighthouse в Chrome DevTools и сохранить отчёт.
- Запустить PageSpeed Insights для ключевых страниц и сравнить результаты.
- Проверить Mobile‑First Indexing в Search Console, чтобы убедиться, что данные относятся к мобильной версии.
- Сравнить средние значения LCP, FID, CLS с целевыми: LCP ≤ 2500 мс, FID ≤ 100 мс, CLS ≤ 0.1.
- Определить пороги для каждой метрики в зависимости от сегмента аудитории (e‑commerce, блог, корпоративный сайт).
- Сравнить показатели с отраслевыми benchmarks (например, 50‑й процентиль по Google Trends).
- Проверить, что LCP не превышает 2500 мс на 90 % страниц.
- Проверить, что FID не превышает 100 мс на 90 % страниц.
- Проверить, что CLS не превышает 0.1 на 90 % страниц.
- Собрать данные по CLS, разбив их по типу контента (изображения, шрифты, анимации).
- Проверить, что динамические элементы не вызывают переотображения (CLS > 0.1).
- Сравнить значения LCP между десктопом и мобильным, выявить отклонения.
- Проверить, что LCP достигается до 2 секунд на мобильных устройствах с медленным интернетом.
- Проверить, что FID находится в пределах 100 мс даже при высокой нагрузке.
- Сравнить показатели с предыдущим периодом, чтобы оценить эффект от изменений.
- Проверить, что все критические ресурсы загружаются асинхронно или отложенно.
- Собрать данные о времени отклика сервера (TTFB) и сравнить с целевым ≤ 200 мс.
- Проверить, что все изображения оптимизированы и имеют атрибуты srcset/ sizes.
Частые ошибки при интерпретации данных
- Неправильный вывод LCP как «только» размер изображения
- Последствия: неэффективные изменения, игнорирование критического пути рендеринга.
- Как избежать: проверять LCP‑элемент в DevTools, анализировать его загрузку и порядок ресурсов.
- Игнорирование контекста сравнения метрик
- Последствия: неправильные приоритеты оптимизации, отклонение от реальных пользовательских сценариев.
- Как избежать: сегментировать данные по устройствам, региону и типу страницы, использовать собственные базовые показатели.
- Полагаться только на Lighthouse
- Последствия: метрика может не отражать реальное поведение пользователей.
- Как избежать: сочетать Lighthouse с RUM‑данными (Google Analytics 4, Web Vitals API).
- Пренебрежение влиянием Service Worker
- Последствия: кэшированные ресурсы могут замедлять LCP, особенно при обновлениях.
- Как избежать: тестировать с отключенным кэшем, контролировать стратегию обновления.
Сравнение инструментов для сбора CWV
| Инструмент | Измеряемые метрики | Метод сбора | Доступность | Стоимость | Плюсы | Минусы |
|---|---|---|---|---|---|---|
| Lighthouse | TTI, LCP, FID, CLS, Speed Index, First Contentful Paint | Запускается локально, в CI или через Chrome DevTools | Доступен бесплатно, требует Node.js или Chrome | 0 ₽ | Полный набор метрик, детальные отчёты, возможность интеграции в CI | Снимок, не отражает реальное поведение пользователей; требует ручного запуска |
| PageSpeed Insights | TTI, LCP, FID, CLS, First Contentful Paint, Speed Index, Web Vitals | Сбор в режиме «lab» и «real‑user» через API Google | Доступен через веб‑интерфейс и API, требует Google‑аккаунт | 0 ₽ (с ограничением 200 запросов/сутки в API) | Кросс‑платформенные данные, рекомендации по улучшению, исторические отчёты | Ограничение на частоту запросов; данные могут отличаться от локального Lighthouse |
| Web Vitals API | LCP, FID, CLS, First Input Delay, Largest Contentful Paint | Встроенный JavaScript‑API, работающий в браузере пользователя | Доступен на всех современных браузерах, интеграция через скрипт | 0 ₽ | Актуальные данные в реальном времени, возможность потоковой передачи в собственный бекенд | Только первая загрузка страницы; требует ручной настройки сбора и хранения |
| Яндекс Метрика | Пользовательские тайминги (Web Vitals), LCP, FID, CLS, First Contentful Paint | Сбор через User Timings API, отправка в Метрику | Доступна бесплатно, требует аккаунт Яндекс | 0 ₽ | Поддержка русскоязычного рынка, гибкая настройка метрик, интеграция с аналитикой | Не предоставляет стандартных рекомендаций, требует ручной конфигурации и обработки |
План внедрения улучшений
Этапы внедрения Core Web Vitals разбиты по времени и приоритету. Сначала собираем данные, затем анализируем, планируем, реализуем, тестируем, запускаем и продолжаем мониторинг.
| Этап | Срок | Ключевые действия | Приоритет |
|---|---|---|---|
| Сбор данных | 1 неделя | Запустить Lighthouse, PageSpeed Insights, RUM; собрать LCP, FID, CLS по ключевым страницам | Высокий |
| Анализ | 1 неделя | Выявить узкие места, оценить влияние на метрики; составить список проблем | Высокий |
| Планирование | 1 неделя | Разработать дорожную карту изменений, оценить трудозатраты и сроки реализации | Средний |
| Реализация | 2–4 недели | Оптимизировать изображения, минифицировать код, внедрить Service Worker, настроить кеширование | Высокий |
| Тестирование | 1 неделя | Проверить результаты в staging, сравнить метрики до/после; убедиться в отсутствии regressions | Средний |
| Запуск | 1 неделя | Перенести изменения в прод, выполнить финальный чек; включить мониторинг | Высокий |
| Мониторинг | Постоянно | Отслеживать метрики в реальном времени, корректировать стратегию при необходимости | Средний |
Мониторинг после релиза
После релиза Core Web Vitals становятся живыми данными, которые влияют на ранжирование. Чтобы не упустить критические падения, настройте оповещения в Google Search Console и в инструменте, который собирает метрики из Chrome User Experience Report. Установите пороги: LCP ≤ 2.5 с, FID ≤ 100 мс, CLS ≤ 0.1. Если показатель превышает порог, система отправит email или Slack‑сообщение. Рекомендуем проверять динамику ежедневно, а полную статистику – еженедельно. Для постоянного контроля создайте дашборд в Google Data Studio, подключив API PageSpeed Insights и CUX. В дашборде отображайте средние значения за последние 30 дней и сравнивайте с историей.
| Показатель | Целевой порог | Где смотреть |
|---|---|---|
| LCP | ≤ 2.5 с | Search Console → Performance → Core Web Vitals, PageSpeed Insights API, CUX |
| FID | ≤ 100 мс | Search Console → Core Web Vitals, PageSpeed Insights API |
| CLS | ≤ 0.1 | Search Console → Core Web Vitals, PageSpeed Insights API |
| Page Load Time | ≤ 3 с | Google PageSpeed Insights, New Relic |
| Server Response | ≤ 200 мс | New Relic, CloudWatch |
| Cache Hit Rate | ≥ 80 % | CDN logs, CloudFront |
Риски и ограничения
Метрики Core Web Vitals могут быть подвержены искусственному влиянию. Если данные собираются только из инструментов, которые используют симуляцию сети, они не отражают реальное поведение пользователей. Такие «обманные» метрики могут привести к неверным решениям: оптимизация, которая выглядит хорошей в отчётах, но ухудшает опыт реальных посетителей. Внешние факторы – скорость соединения, тип устройства, география, версия браузера – сильно влияют на LCP, FID и CLS. Плохая сеть в одном регионе может поднять среднее значение, а незначительные изменения в коде могут изменить поведение только на мобильных устройствах. Поэтому важно сочетать RUM (Real User Monitoring) с Synthetic Testing, проверять разброс значений и учитывать контекст. Даже корректные данные могут быть обмануты, если тестовые сценарии запускаются с ускоренной сетью. CDN‑кэш старых скриптов, влияющих на CLS, требует регулярного обновления. Динамическая подстановка изображений может резко изменить LCP в конкретных сегментах аудитории. Любые изменения в коде должны сопровождаться мониторингом и анализом метрик в реальном времени.
- Собирайте данные из RUM, а не только из Lighthouse.
- Проверяйте разброс метрик по регионам и устройствам.
- Сравнивайте средние значения с медианой – аномалии могут указывать на обман.
- Отслеживайте влияние обновлений браузера и ОС на FID и CLS.
- Не полагайтесь на единичные отчёты – анализируйте тренды за минимум 30 дней.
- Проверяйте, что сервисные воркеры не кэшируют старые ресурсы, влияющие на LCP.
- Документируйте изменения в коде и связывайте их с изменениями метрик.
Вопросы и ответы
Как часто нужно проверять CWV после внесения изменений?
После каждого крупного обновления стоит проверять CWV в течение 1–2 недель, чтобы увидеть, как изменения повлияли на LCP, FID и CLS. Регулярный мониторинг каждые 10–15 дней помогает быстро реагировать на отклонения.
Можно ли использовать только Lighthouse для оценки ранжирования?
Lighthouse предоставляет синтетические данные, но для реального ранжирования нужны RUM‑метрики из Search Console или Chrome User Experience Report. Используйте Lighthouse как контрольный инструмент, а не единственный источник.
Что делать, если CLS слишком высок из-за динамического контента?
Выделите фиксированную высоту для элементов, используйте CSS‑placeholders, lazy‑load изображения с заданными размерами и применяйте анимации только после полной загрузки контента.
Как отличить проблемы с LCP от медленного сервера?
Сравните время ответа сервера (TTFB) с временем загрузки самого медленного ресурса. Если TTFB высок, проблема в сервере; если медленный ресурс – оптимизируйте его, например, сжатие или CDN.
Можно ли игнорировать FID, если LCP и CLS в норме?
FID влияет на интерактивность и пользовательский опыт. Даже при хороших LCP и CLS, высокий FID может ухудшить ранжирование. Лучше держать FID ниже 100 мс, если это возможно.
Как использовать Core Web Vitals в Google Search Console?
В разделе Performance откройте вкладку Core Web Vitals, выберите нужный период и страницу, экспортируйте данные в CSV. Это позволит отслеживать тренды и сравнивать результаты до и после оптимизации.
Нужно ли оптимизировать изображения для улучшения CWV?
Да. Используйте современные форматы (WebP, AVIF), задавайте атрибуты width/height, применяйте lazy‑load и CDN. Это снижает LCP и CLS, особенно на мобильных устройствах.
Как измерить влияние изменений на ранжирование?
Сравните позиции ключевых слов до и после оптимизации, но помните, что алгоритмы учитывают множество факторов. Регулярный мониторинг позиций в течение 3–6 месяцев даст более точную картину.
Можно ли использовать сторонние инструменты вместо Lighthouse?
Можно, но они должны выдавать те же метрики LCP, FID и CLS. Убедитесь, что инструмент собирает данные с реальных пользователей, иначе результаты будут отличаться от поисковых показателей.
Как закрыть низкочастотные запросы с плохими CWV?
Найдите страницы, обслуживающие эти запросы, улучшите их CWV, затем проверьте позиции в Search Console. Если метрики улучшились, позиции обычно растут, но это зависит от конкуренции и актуальности контента.
Важно
Материал носит информационный характер. Перед внедрением рекомендаций учитывайте нишу, регион, конкурентов, текущее состояние сайта и бизнес-цели проекта.
Материал подготовлен и проверен редакцией AX.SEO
Редакция AX.SEO готовит материалы о SEO, разработке, AI, аналитике, маркетинге и росте digital-проектов.
Проверяет практическую применимость рекомендаций, корректность терминов и соответствие материала digital-тематике.