Core Web Vitals: dlaczego monitoring uptime nie wystarczy

W skrócie: Serwer zwraca HTTP 200, monitoring mówi "UP" - a ty i tak tracisz traffic z Google. Core Web Vitals (LCP, INP, CLS) mierzą rzeczywiste doświadczenie użytkownika. Wolny web jest z perspektywy Google "down" tak samo jak niedostępny.

W skrócie: Serwer zwraca HTTP 200, monitoring mówi "UP" - a ty i tak tracisz traffic z Google. Core Web Vitals (LCP, INP, CLS) mierzą rzeczywiste doświadczenie użytkownika. Wolny web jest z perspektywy Google "down" tak samo jak niedostępny.

Trzy metryki CWV

Google w 2020 wprowadził Core Web Vitals jako ranking factor. Od marca 2024 tworzą je:

LCP (Largest Contentful Paint) - kiedy wyświetla się największy element strony. Dobrze: ≤ 2,5 s. Trzeba poprawić: 2,5-4 s. Źle: > 4 s.
INP (Interaction to Next Paint) - jak szybko strona reaguje na interakcje użytkownika (klik, tap). Zastąpił FID w marcu 2024. Dobrze: ≤ 200 ms. Trzeba poprawić: 200-500 ms. Źle: > 500 ms.
CLS (Cumulative Layout Shift) - o ile elementy strony wizualnie się ruszają podczas ładowania. Dobrze: ≤ 0,1. Trzeba poprawić: 0,1-0,25. Źle: > 0,25.

Dlaczego monitoring tego nie wyłapuje

Klasyczny monitor uptime wysyła żądanie HTTP GET i mierzy:

Kod statusu (200 = OK)
Time to first byte (TTFB)
Opcjonalnie keyword match w HTML

Ale nie renderuje strony w przeglądarce. Nie widzi, że:

Bundle JavaScript ma 3 MB i parsing trwa 4 sekundy
Obraz hero ładuje się synchronicznie i blokuje paint
Trzecia strona (analytics, reklamy) blokuje main thread
Layout się przeskakuje, jak ładują się elementy

Z perspektywy odwiedzającego web jest wolny i nieużyteczny - z perspektywy monitoringu wszystko jest "UP".

Lab vs field data

CWV mierzą się dwoma sposobami:

Lab data (Lighthouse, PageSpeed Insights, WebPageTest) - kontrolowana przeglądarka, zdefiniowana sieć (typowo 4G), konkretne urządzenie. Reprodukowalne, odpowiednie do testowania regresji po deployach.

Field data / RUM (Chrome User Experience Report, własny JS) - zbieranie danych od prawdziwych odwiedzających w ich realnych warunkach. To, czego Google używa do rankingu. Odzwierciedla rzeczywistą zmienność (klient mobilny 3G z pociągu, desktop fiber itd.).

Lab data to dobre odniesienie, field data to prawda.

Uwaga: ePulz.io obecnie nie śledzi metryk CWV. Do ich pomiaru użyj specjalistycznych narzędzi (PageSpeed Insights, WebPageTest, Lighthouse CI lub własnego snippetu RUM JS). Dla regresji wizualnych ePulz.io oferuje monitor typu visual, który porównuje screenshoty - to częściowo pokrywa scenariusze "strona renderuje się zupełnie inaczej", ale nie mierzy LCP/INP/CLS.

Praktyczna strategia monitoringu

Synthetic uptime check - klasyczny monitor HTTP co 1-5 min. Wykrywa hard downtime, 5xx, wygasłe certyfikaty.
Pomiar CWV (poza ePulz) - Lighthouse CI w deployment pipeline lub nocny cron lub headless Chrome raz dziennie. Wykrywa regresję po wdrożeniu (LCP wzrósł z 1,8 s do 4,2 s po wdrożeniu nowego JS bundle).
Visual regression check - screenshot diff. Wykrywa, gdy strona renderuje się zupełnie inaczej niż wcześniej (CSS broken, font fail, JS error).
Real User Monitoring - snippet JS na stronie zbiera CWV od prawdziwych odwiedzających. Śledzisz 75. percentyl metryk.

Top przyczyny złych CWV

LCP zbyt wysokie:

Duże obrazy hero bez priority hint (fetchpriority="high")
Wolny serwer / TTFB (CDN cache miss, wolne DB query)
Blocking resources w <head> (analytics, fonts bez display=swap)
Web fonts ładowane z third-party CDN bez preconnect

INP zbyt wysokie:

Duży JS bundle blokujący main thread
Synchroniczne event listenery, które wykonują ciężką pracę
Wolne third-party skrypty (chat widgets, A/B testing)

CLS zbyt wysokie:

Obrazy bez wyraźnych atrybutów width i height
Reklamy bez zarezerwowanego miejsca
Dynamicznie wstrzykiwane treści nad fold
Web fonts z FOUT (Flash of Unstyled Text) bez prawidłowego fallback

Wpływ SEO

Google używa CWV jako tie-breaker. Przy równie istotnej treści preferuje szybszą stronę. W konkurencyjnych niszach to decydujące.

Praktyczny wpływ:

Strona z CWV w "good" zakresie ma średnio ~20% niższy bounce rate
Conversion rate rośnie przy każdym -100 ms LCP
Mobile-first indexing oznacza, że Google ocenia wersję mobilną - testuj tam

Wnioski

Monitoring uptime odpowiada na "Czy serwer jest osiągalny?". Core Web Vitals odpowiadają na "Czy web jest użyteczny?". Obie metryki są niezależne i obie trzeba śledzić. Serwer może mieć 100% uptime, a web mimo to tracić traffic przez LCP powyżej 4 sekund.

Monitoring poza uptime

Visual regression wykrywa zmiany wizualne nawet gdy serwer zwraca 200. Monitoring response time wyłapuje wolne endpointy.

Wypróbować ePulz.io →