Terug naar blog

Core Web Vitals: waarom uptime monitoring niet genoeg is

· 6 min lezen

Kort: De server retourneert HTTP 200, monitoring zegt "UP" - en je verliest toch traffic van Google. Core Web Vitals (LCP, INP, CLS) meten de echte gebruikerservaring. Een trage website is vanuit Google's perspectief "down" net als een onbereikbare.

Kort: De server retourneert HTTP 200, monitoring zegt "UP" - en je verliest toch traffic van Google. Core Web Vitals (LCP, INP, CLS) meten de echte gebruikerservaring. Een trage website is vanuit Google's perspectief "down" net als een onbereikbare.

Drie CWV-metrieken

Google introduceerde in 2020 Core Web Vitals als ranking factor. Sinds maart 2024 bestaan ze uit:

  • LCP (Largest Contentful Paint) - wanneer het grootste element van de pagina verschijnt. Goed: ≤ 2,5 s. Te verbeteren: 2,5-4 s. Slecht: > 4 s.
  • INP (Interaction to Next Paint) - hoe snel de pagina reageert op gebruikersinteracties (klik, tap). Verving FID in maart 2024. Goed: ≤ 200 ms. Te verbeteren: 200-500 ms. Slecht: > 500 ms.
  • CLS (Cumulative Layout Shift) - hoeveel pagina-elementen visueel bewegen tijdens het laden. Goed: ≤ 0,1. Te verbeteren: 0,1-0,25. Slecht: > 0,25.

Waarom monitoring het niet opvangt

Klassieke uptime monitor stuurt HTTP GET request en meet:

  • Statuscode (200 = OK)
  • Time to first byte (TTFB)
  • Optioneel keyword match in HTML

Maar het rendert de pagina niet in de browser. Het ziet niet dat:

  • JavaScript bundle 3 MB is en parsing 4 seconden duurt
  • Hero image synchroon laadt en paint blokkeert
  • Derde partij (analytics, advertising) main thread blokkeert
  • Layout springt terwijl elementen laden

Vanuit het perspectief van de bezoeker is het web traag en onbruikbaar - vanuit het monitoring perspectief is alles "UP".

Lab vs field data

CWV worden op twee manieren gemeten:

Lab data (Lighthouse, PageSpeed Insights, WebPageTest) - gecontroleerde browser, gedefinieerd netwerk (typisch 4G), specifiek apparaat. Reproduceerbaar, geschikt voor regressietesten na deploys.

Field data / RUM (Chrome User Experience Report, eigen JS) - dataverzameling van echte bezoekers in hun echte omstandigheden. Wat Google gebruikt voor ranking. Weerspiegelt de echte variabiliteit (3G mobiele client uit de trein, desktop fiber, enz.).

Lab data is een goede referentie, field data is de waarheid.

Opmerking: ePulz.io volgt momenteel geen CWV-metrieken. Om ze te meten, gebruik gespecialiseerde tools (PageSpeed Insights, WebPageTest, Lighthouse CI of eigen RUM JS-snippet). Voor visuele regressies biedt ePulz.io een monitor van type visual die screenshots vergelijkt - dit dekt gedeeltelijk "pagina rendert compleet anders"-scenario's, maar meet niet LCP/INP/CLS.

Praktische monitoring strategie

  1. Synthetic uptime check - klassieke HTTP monitor elke 1-5 min. Detecteert hard downtime, 5xx, verlopen certificaten.
  2. CWV-meting (buiten ePulz) - Lighthouse CI in deployment-pipeline of nachtelijke cron of headless Chrome eens per dag. Detecteert regressie na deployment (LCP steeg van 1,8 s naar 4,2 s na deployment van een nieuwe JS bundle).
  3. Visual regression check - screenshot diff. Detecteert wanneer de pagina compleet anders rendert dan voorheen (CSS broken, font fail, JS error).
  4. Real User Monitoring - JS snippet op de pagina verzamelt CWV van echte bezoekers. Je volgt het 75e percentiel van metrieken.

Topoorzaken van slechte CWV

LCP te hoog:

  • Grote hero images zonder priority hint (fetchpriority="high")
  • Trage server / TTFB (CDN cache miss, trage DB query)
  • Blocking resources in <head> (analytics, fonts zonder display=swap)
  • Web fonts geladen vanaf third-party CDN zonder preconnect

INP te hoog:

  • Grote JS bundle die main thread blokkeert
  • Synchrone event listeners die zwaar werk doen
  • Trage third-party scripts (chat widgets, A/B testing)

CLS te hoog:

  • Images zonder expliciete width en height attributen
  • Advertenties zonder gereserveerde ruimte
  • Dynamisch geïnjecteerde inhoud boven de fold
  • Web fonts met FOUT (Flash of Unstyled Text) zonder juiste fallback

SEO-impact

Google gebruikt CWV als tie-breaker. Bij even relevante content geeft het de voorkeur aan de snellere pagina. In concurrerende niches is het beslissend.

Praktische impact:

  • Een site met CWV in "good" range heeft gemiddeld ~20% lagere bounce rate
  • Conversion rate stijgt met elke -100 ms LCP
  • Mobile-first indexing betekent dat Google de mobiele versie evalueert - test daar

Conclusie

Uptime monitoring beantwoordt "Is de server bereikbaar?". Core Web Vitals beantwoorden "Is het web bruikbaar?". Beide metrieken zijn onafhankelijk en beide moet je volgen. De server kan 100% uptime hebben en het web toch traffic verliezen door LCP boven 4 seconden.

Monitoring voorbij uptime

Visual regression detecteert visuele wijzigingen ook wanneer de server 200 retourneert. Response time monitoring vangt trage endpoints op.

Probeer ePulz.io →

Probeer ePulz.io gratis - 7 dagen zonder creditcard.

Account aanmaken