Core Web Vitals: почему мониторинга uptime недостаточно

Кратко: Сервер возвращает HTTP 200, мониторинг говорит «UP» - и вы всё равно теряете трафик из Google. Core Web Vitals (LCP, INP, CLS) измеряют реальный пользовательский опыт. Медленный сайт с точки зрения Google «down» так же, как и недоступный.

Кратко: Сервер возвращает HTTP 200, мониторинг говорит «UP» - и вы всё равно теряете трафик из Google. Core Web Vitals (LCP, INP, CLS) измеряют реальный пользовательский опыт. Медленный сайт с точки зрения Google «down» так же, как и недоступный.

Три метрики CWV

Google в 2020 ввёл Core Web Vitals как фактор ranking. С марта 2024 их составляют:

LCP (Largest Contentful Paint) - когда отображается самый большой элемент страницы. Хорошо: ≤ 2,5 с. Нужно улучшить: 2,5-4 с. Плохо: > 4 с.
INP (Interaction to Next Paint) - как быстро страница реагирует на user-взаимодействия (клик, tap). Заменил FID в марте 2024. Хорошо: ≤ 200 мс. Нужно улучшить: 200-500 мс. Плохо: > 500 мс.
CLS (Cumulative Layout Shift) - насколько элементы страницы визуально движутся во время загрузки. Хорошо: ≤ 0,1. Нужно улучшить: 0,1-0,25. Плохо: > 0,25.

Почему мониторинг этого не ловит

Классический uptime-монитор посылает HTTP GET запрос и измеряет:

Status code (200 = OK)
Time to first byte (TTFB)
Опционально keyword match в HTML

Но не рендерит страницу в браузере. Не видит, что:

JavaScript bundle имеет 3 МБ и parsing занимает 4 секунды
Hero-изображение загружается синхронно и блокирует paint
Третья сторона (analytics, advertising) блокирует main thread
Layout прыгает, пока загружаются элементы

С точки зрения посетителя web медленный и непригодный к использованию - с точки зрения мониторинга всё «UP».

Lab vs field data

CWV измеряются двумя способами:

Lab data (Lighthouse, PageSpeed Insights, WebPageTest) - контролируемый браузер, определённая сеть (типично 4G), конкретное устройство. Воспроизводимо, подходит для регрессионного тестирования после деплоев.

Field data / RUM (Chrome User Experience Report, собственный JS) - сбор данных от реальных посетителей в их реальных условиях. То, что Google использует для ranking. Отражает реальную вариабельность (3G mobile клиент из поезда, desktop fiber и т.д.).

Lab data - хороший ориентир, field data - правда.

Прим.: ePulz.io в настоящее время не отслеживает метрики CWV. Для их измерения используйте специализированные инструменты (PageSpeed Insights, WebPageTest, Lighthouse CI или собственный RUM JS-сниппет). Для визуальных регрессий ePulz.io предлагает монитор типа visual, который сравнивает скриншоты - это частично покрывает сценарии "страница рендерится совершенно иначе", но не измеряет LCP/INP/CLS.

Практическая стратегия мониторинга

Synthetic uptime check - классический HTTP-монитор каждые 1-5 мин. Детектит hard downtime, 5xx, истёкшие сертификаты.
Измерение CWV (вне ePulz) - Lighthouse CI в deployment pipeline или ночной cron или headless Chrome раз в день. Детектит регрессию после deployment (LCP вырос с 1,8 с до 4,2 с после deploy нового JS bundle).
Visual regression check - screenshot diff. Детектит, когда страница рендерится совершенно иначе, чем раньше (CSS broken, font fail, JS error).
Real User Monitoring - JS-сниппет на странице собирает CWV от реальных посетителей. Следите за 75-м перцентилем метрик.

Топ причин плохих CWV

LCP слишком высокий:

Большие hero-изображения без priority hint (fetchpriority="high")
Медленный сервер / TTFB (CDN cache miss, медленный DB query)
Blocking resources в <head> (analytics, fonts без display=swap)
Web fonts загружаемые с third-party CDN без preconnect

INP слишком высокий:

Большой JS bundle блокирующий main thread
Синхронные event listener-ы, делающие тяжёлую работу
Медленные third-party скрипты (chat widgets, A/B testing)

CLS слишком высокий:

Изображения без явных width и height атрибутов
Реклама без зарезервированного места
Динамически инжектируемый контент над fold
Web fonts с FOUT (Flash of Unstyled Text) без правильного fallback

SEO-эффект

Google использует CWV как tie-breaker. При одинаково релевантном контенте предпочтёт более быструю страницу. В конкурентных нишах это решающий фактор.

Практический эффект:

Сайт с CWV в диапазоне «good» в среднем имеет ~20% более низкий bounce rate
Conversion rate растёт с каждым -100 мс LCP
Mobile-first indexing означает, что Google оценивает мобильную версию - тестируйте там

Вывод

Uptime-мониторинг отвечает на «Доступен ли сервер?». Core Web Vitals отвечают на «Используем ли веб?». Обе метрики независимы и обе нужно отслеживать. Сервер может иметь 100% uptime, а веб всё равно терять трафик из-за LCP больше 4 секунд.

Мониторинг за пределами uptime

Visual regression детектит визуальные изменения, даже когда сервер возвращает 200. Мониторинг response time ловит медленные endpoint-ы.

Попробовать ePulz.io →