Core Web Vitals: miért nem elég az uptime monitorozás

A szerver 200-at ad, a monitorozás UP-ot mond - és mégis veszítesz látogatókat a Google-tól. A Core Web Vitals a valós felhasználói élményt méri.

Három CWV metrika

A Google 2020-ban vezette be a Core Web Vitals-t ranking faktorként. 2024 márciusától ezeket alkotják:

LCP (Largest Contentful Paint) - mikor jelenik meg az oldal legnagyobb eleme. Jó: ≤ 2,5 s. Javítandó: 2,5-4 s. Rossz: > 4 s.
INP (Interaction to Next Paint) - milyen gyorsan reagál az oldal a felhasználói interakciókra (kattintás, tap). 2024 márciusában váltotta a FID-et. Jó: ≤ 200 ms. Javítandó: 200-500 ms. Rossz: > 500 ms.
CLS (Cumulative Layout Shift) - mennyit mozognak az oldal elemei vizuálisan a betöltés során. Jó: ≤ 0,1. Javítandó: 0,1-0,25. Rossz: > 0,25.

Miért nem kapja el a monitorozás

A klasszikus uptime monitor HTTP GET kérést küld, és a következőket méri:

Státuszkód (200 = OK)
Time to first byte (TTFB)
Opcionálisan kulcsszó-egyezés a HTML-ben

De nem rendereli az oldalt a böngészőben. Nem látja, hogy:

A JavaScript bundle 3 MB, és a parsing 4 másodpercig tart
A hero kép szinkron módon töltődik be, és blokkolja a paintet
Harmadik fél kódja (analytics, hirdetések) blokkolja a main thread-et
A layout ugrik, ahogy az elemek betöltődnek

A látogató szemszögéből a webhely lassú és használhatatlan, a monitorozás szemszögéből viszont minden "UP".

Lab vs field data

A CWV-t kétféleképpen mérik:

Lab data (Lighthouse, PageSpeed Insights, WebPageTest) - kontrollált böngésző, definiált hálózat (jellemzően 4G), konkrét eszköz. Reprodukálható, alkalmas regressziós tesztelésre deployok után.

Field data / RUM (Chrome User Experience Report, saját JS) - adatgyűjtés valódi látogatóktól valódi körülményeik között. Amit a Google ranking-hez használ. Tükrözi a valódi variabilitást (3G mobil kliens a vonatból, desktop fiber stb.).

A lab data jó referencia, a field data az igazság.

Megjegyzés: az ePulz.io jelenleg nem követi a CWV metrikákat. Mérésükhöz használjon specializált eszközöket (PageSpeed Insights, WebPageTest, Lighthouse CI vagy saját RUM JS snippet). Vizuális regressziókhoz az ePulz.io visual típusú monitort kínál, amely képernyőképeket hasonlít össze - ez részben fedi az "oldal teljesen másképp renderelődik" forgatókönyveket, de nem méri az LCP/INP/CLS-t.

Gyakorlati monitoring stratégia

Synthetic uptime check - klasszikus HTTP monitor 1-5 percenként. Észleli a hard downtime-ot, 5xx-et, lejárt tanúsítványokat.
CWV mérés (ePulz-en kívül) - Lighthouse CI a deployment pipeline-ban, illetve éjszakai cron vagy headless Chrome napi egyszer. Észleli a regressziót deploy után (az LCP 1,8 s-ról 4,2 s-ra emelkedett egy új JS bundle deploya után).
Visual regression check - screenshot diff. Észleli, ha az oldal teljesen másképp renderelődik, mint korábban (törött CSS, font hiba, JS error).
Real User Monitoring - JS snippet az oldalon CWV-t gyűjt valódi látogatóktól. A metrikák 75. percentilisét figyeled.

Top okok a rossz CWV-re

LCP túl magas:

Nagy hero képek priority hint nélkül (fetchpriority="high")
Lassú szerver / TTFB (CDN cache miss, lassú DB query)
Blocking resources a <head>-ben (analytics, fonts display=swap nélkül)
Web fonts third-party CDN-ből preconnect nélkül

INP túl magas:

Nagy JS bundle a main thread-et blokkolva
Szinkron event listenerek, amik nehéz munkát csinálnak
Lassú third-party scriptek (chat widgets, A/B testing)

CLS túl magas:

Képek explicit width és height attribútumok nélkül
Hirdetések fenntartott hely nélkül
Dinamikusan beinjektált tartalmak fold felett
Web fonts FOUT-tal (Flash of Unstyled Text) megfelelő fallback nélkül

SEO hatás

A Google a CWV-t tie-breakerként használja: azonosan releváns tartalom esetén a gyorsabb oldalt preferálja. Erősen versenyző szegmensekben ez döntő lehet.

Gyakorlati hatás:

A "good" tartományban CWV-vel rendelkező oldal átlagosan ~20%-kal alacsonyabb bounce rate-tel
A conversion rate minden -100 ms LCP-vel nő
A mobile-first indexing azt jelenti, hogy a Google a mobil verziót értékeli - ott tesztelj

Következtetés

Az uptime monitorozás a "Elérhető a szerver?" kérdésre válaszol. A Core Web Vitals a "Használható a web?" kérdésre válaszol. Mindkét metrika független és mindkettőt figyelni kell. A szerver lehet 100% uptime, és a web mégis veszíthet trafficot a 4 másodperc feletti LCP miatt.

Monitorozás az uptime-on túl

A visual regression vizuális változásokat észlel akkor is, ha a szerver 200-at ad vissza. A válaszidő-monitorozás elkapja a lassú végpontokat.

ePulz.io kipróbálása →