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 відповідають на «Чи використовуваний web?». Обидві метрики незалежні і обидві потрібно відслідковувати. Сервер може мати 100% uptime, а web усе одно втрачати трафік через LCP більше 4 секунд.

Моніторинг поза uptime

Visual regression детектить візуальні зміни, навіть коли сервер повертає 200. Моніторинг response time ловить повільні endpoint-и.

Спробувати ePulz.io →