Vissza a bloghoz

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

· 6 perc olvasás

Röviden: A szerver HTTP 200-at ad vissza, a monitorozás "UP"-ot mond - és mégis veszítesz traffic-ot a Google-tól. A Core Web Vitals (LCP, INP, CLS) a valós felhasználói élményt méri. A lassú web a Google szemszögéből "down", ugyanúgy mint az elérhetetlen.

Röviden: A szerver HTTP 200-at ad vissza, a monitorozás "UP"-ot mond - és mégis veszítesz traffic-ot a Google-tól. A Core Web Vitals (LCP, INP, CLS) a valós felhasználói élményt méri. A lassú web a Google szemszögéből "down", ugyanúgy mint az elérhetetlen.

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 mér:

  • Státuszkód (200 = OK)
  • Time to first byte (TTFB)
  • Opcionálisan keyword match 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ásodperc
  • A hero kép szinkron töltődik és blokkolja a paintet
  • Harmadik fél (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 web lassú és használhatatlan - a monitorozás szemszögéből 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

  1. Synthetic uptime check - klasszikus HTTP monitor 1-5 percenként. Észleli a hard downtime-ot, 5xx-et, lejárt tanúsítványokat.
  2. CWV mérés (ePulz-en kívül) - Lighthouse CI deployment pipeline-ban vagy éjszakai cron vagy headless Chrome napi egyszer. Észleli a regressziót deploy után (LCP emelkedett 1,8 s-ról 4,2 s-ra új JS bundle deploy után).
  3. Visual regression check - screenshot diff. Észleli, ha az oldal teljesen másképp renderelődik mint korábban (CSS broken, font fail, JS error).
  4. 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 CWV-t tie-breakerként használja. Azonosan releváns tartalom esetén a gyorsabb oldalt preferálja. Versenyző réseken döntő.

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 response time monitorozás elkapja a lassú végpontokat.

ePulz.io kipróbálása →

Próbálja ki az ePulz.io-t ingyen - 7 nap bankkártya nélkül.

Fiók létrehozása