Core Web Vitals: warum Uptime-Monitoring nicht reicht

Kurz gesagt: Der Server gibt HTTP 200 zurück, Monitoring sagt „UP" - und Sie verlieren trotzdem Traffic von Google. Core Web Vitals (LCP, INP, CLS) messen die echte Benutzererfahrung. Eine langsame Website ist aus Sicht von Google „down" genauso wie eine nicht erreichbare.

Kurz gesagt: Der Server gibt HTTP 200 zurück, Monitoring sagt „UP" - und Sie verlieren trotzdem Traffic von Google. Core Web Vitals (LCP, INP, CLS) messen die echte Benutzererfahrung. Eine langsame Website ist aus Sicht von Google „down" genauso wie eine nicht erreichbare.

Drei CWV-Metriken

Google führte 2020 Core Web Vitals als Ranking-Faktor ein. Ab März 2024 bestehen sie aus:

LCP (Largest Contentful Paint) - wann das größte Element der Seite erscheint. Gut: ≤ 2,5 s. Verbesserungswürdig: 2,5-4 s. Schlecht: > 4 s.
INP (Interaction to Next Paint) - wie schnell die Seite auf User-Interaktionen (Klick, Tap) reagiert. Ersetzte FID im März 2024. Gut: ≤ 200 ms. Verbesserungswürdig: 200-500 ms. Schlecht: > 500 ms.
CLS (Cumulative Layout Shift) - wie sehr sich Seitenelemente während des Ladens visuell bewegen. Gut: ≤ 0,1. Verbesserungswürdig: 0,1-0,25. Schlecht: > 0,25.

Warum Monitoring es nicht erfasst

Klassisches Uptime-Monitor sendet HTTP-GET-Request und misst:

Statuscode (200 = OK)
Time to first byte (TTFB)
Optional Keyword Match im HTML

Aber es rendert die Seite nicht im Browser. Es sieht nicht, dass:

JavaScript-Bundle 3 MB hat und Parsing 4 Sekunden dauert
Hero-Bild synchron lädt und Paint blockiert
Drittpartei (Analytics, Advertising) Main Thread blockiert
Layout springt, während Elemente laden

Aus Sicht des Besuchers ist die Website langsam und unbenutzbar - aus Sicht des Monitorings ist alles „UP".

Lab vs Field Data

CWV werden auf zwei Arten gemessen:

Lab Data (Lighthouse, PageSpeed Insights, WebPageTest) - kontrollierter Browser, definiertes Netzwerk (typisch 4G), bestimmtes Gerät. Reproduzierbar, geeignet für Regressionstests nach Deploys.

Field Data / RUM (Chrome User Experience Report, eigenes JS) - Datensammlung von echten Besuchern in ihren echten Bedingungen. Was Google für Ranking benutzt. Spiegelt tatsächliche Variabilität wider (3G-Mobile-Client aus dem Zug, Desktop-Fiber etc.).

Lab Data sind eine gute Referenz, Field Data sind die Wahrheit.

Hinweis: ePulz.io erfasst derzeit keine CWV-Metriken. Um sie zu messen, nutzen Sie spezialisierte Tools (PageSpeed Insights, WebPageTest, Lighthouse CI oder ein eigenes RUM-JS-Snippet). Für visuelle Regressionen bietet ePulz.io einen Monitor vom Typ visual, der Screenshots vergleicht - dies deckt teilweise "Seite rendert völlig anders"-Szenarien ab, misst aber nicht LCP/INP/CLS.

Praktische Monitoring-Strategie

Synthetic Uptime Check - klassisches HTTP-Monitor alle 1-5 Min. Erkennt Hard Downtime, 5xx, abgelaufene Zertifikate.
Synthetic CWV Check - Lighthouse oder Headless Chrome einmal am Tag. Erkennt Regression nach Deployment (LCP stieg von 1,8 s auf 4,2 s nach Deployment eines neuen JS-Bundles).
Visual Regression Check - Screenshot Diff. Erkennt, wenn die Seite komplett anders als zuvor rendert (CSS broken, Font Fail, JS Error).
Real User Monitoring - JS-Snippet auf der Seite sammelt CWV von echten Besuchern. Sie verfolgen das 75. Perzentil der Metriken.

Top-Ursachen für schlechte CWV

LCP zu hoch:

Große Hero-Bilder ohne Priority Hint (fetchpriority="high")
Langsamer Server / TTFB (CDN Cache Miss, langsame DB Query)
Blocking Resources in <head> (Analytics, Fonts ohne display=swap)
Web Fonts von Third-Party CDN ohne Preconnect geladen

INP zu hoch:

Großes JS-Bundle blockiert Main Thread
Synchrone Event Listener, die schwere Arbeit machen
Langsame Third-Party-Skripte (Chat Widgets, A/B Testing)

CLS zu hoch:

Bilder ohne explizite width- und height-Attribute
Anzeigen ohne reservierten Platz
Dynamisch injizierter Inhalt über dem Fold
Web Fonts mit FOUT (Flash of Unstyled Text) ohne richtigen Fallback

SEO-Impact

Google nutzt CWV als Tie-Breaker. Bei gleich relevantem Inhalt bevorzugt es die schnellere Seite. In kompetitiven Nischen ist das entscheidend.

Praktischer Impact:

Eine Seite mit CWV im „Good"-Bereich hat im Schnitt ~20% niedrigere Bounce Rate
Conversion Rate steigt mit jedem -100 ms LCP
Mobile-First-Indexing bedeutet, Google bewertet die Mobile-Version - dort testen

Fazit

Uptime-Monitoring beantwortet „Ist der Server erreichbar?". Core Web Vitals beantworten „Ist die Website benutzbar?". Beide Metriken sind unabhängig und beide müssen Sie überwachen. Der Server kann 100% Uptime haben und die Website trotzdem Traffic wegen LCP über 4 Sekunden verlieren.

Monitoring über Uptime hinaus

Visual Regression erkennt visuelle Änderungen, auch wenn der Server 200 zurückgibt. Response-Time-Monitoring fängt langsame Endpoints ab.

ePulz.io testen →