Performance16 April 20266 min readDeutsch

Core Web Vitals: Was überwachen und wie Regressionen beheben

Performance-Regressionen werden fast nie absichtlich ausgeliefert. Sie kommen mit einer scheinbar harmlosen Änderung: ein neues Karussell, ein Drittanbieter-Tag, ein Font-Wechsel. Wenn jemand den Conversion-Drop bemerkt, ist die Regression zwei Wochen alt. Kontinuierliche CWV-Überwachung dreht die Schleife um — Sie sehen die Regression am gleichen Tag.

PerformanceUptime MonitoringWebsite MonitoringApi MonitoringCron Job Monitoring
Performance

Google bewertet Seiten nach echter Nutzerperformance. LCP, FCP, CLS, TTFB — das sind keine abstrakten Zahlen, das sind Conversion-Killer wenn sie driften. So überwachen Sie sie kontinuierlich und fangen Regressionen ab, bevor sie den Nutzer erreichen.

Was Core Web Vitals tatsächlich messen

Die sechs Metriken, die zählen, einfach erklärt:

LCP (Largest Contentful Paint) — wie lange bis das größte sichtbare Element gerendert ist. Gut < 2,5s. • FCP (First Contentful Paint) — wie lange bis irgendein Pixel rendert. Gut < 1,8s. • CLS (Cumulative Layout Shift) — wie stark die Seite beim Laden springt. Gut < 0,1. • TTFB (Time to First Byte) — reine Server/CDN-Latenz. Gut < 0,8s. • TBT (Total Blocking Time) — wie lange der Main-Thread blockiert war. Gut < 200ms. • Speed Index — synthetisierter 'wie schnell fühlte es sich an'-Score. Gut < 3,4s.

Warum synthetische Labor-Scores lügen

Lighthouse-CI führt Ihre Seite auf einem simulierten Mittelklasse-Gerät mit simuliertem 3G aus. Es ist gut für relative Vergleiche, aber es verpasst viele echte Fehlermodi. Drittanbieter-Skripte, die Cookie-basiert lazy-laden, A/B-Branches, die nur die Hälfte der Nutzer sehen — Lighthouse sieht sie nie.

Ein Full-Browser-Playwright-Check fängt die Fehler ab, die Lighthouse verpasst. SpeedTest führt beides aus, sodass Sie sowohl die CI-Baseline als auch die echte Browser-Wahrheit bekommen.

Die Graphen lesen: graduelle vs. Sprung-Regressionen

Zwei Regressionsformen erzählen unterschiedliche Geschichten.

Ein gradueller Anstieg von LCP über zwei Wochen bedeutet meist, dass eine einzelne Ressource wächst — ein Produktbild-Feed ohne Pagination, ein Analytics-Bundle, das immer mehr Features bekommt.

Eine Sprungänderung bei einem einzelnen Deploy — TTFB springt über Nacht von 400ms auf 1200ms — ist eine direkte Code-Ursache. Korrelieren Sie den Zeitstempel mit DeployLog, finden Sie den Commit, rollen Sie zurück oder fixen Sie.

Pro-Metric-Alarmschwellen, die Sie wirklich wollen

Eine Schwelle pro Metric, Alarm beim Überschreiten der 'poor'-Grenze statt einem grellen 'regressed by 10%':

• LCP > 4,0s — Alarm • FCP > 3,0s — Alarm • CLS > 0,25 — Alarm • TTFB > 1,8s — Alarm • TBT > 600ms — Alarm

Kombinieren Sie mit einer 'warn'-Schwelle an Googles 'needs improvement'-Linie.

Was tun wenn CWV nach einem Deploy regressiert

Das Playbook wenn eine rote Metric direkt nach einem Release alarmiert:

1. Öffnen Sie den Playwright-Trace für den fehlgeschlagenen Lauf. 2. Finden Sie die neue oder geänderte Ressource. 3. Wenn es ein Drittanbieter ist, prüfen Sie dessen Statusseite und erwägen Sie `async` oder `defer`. 4. Wenn es Ihr Code ist, korrelieren Sie mit DeployLog und rollen Sie zurück oder hotfixen Sie. 5. Fügen Sie das Fehlermuster zu Ihrer Pre-Deploy-Checkliste hinzu.

This article is available across the supported locale routes — use the language switcher above to change.

Feature-Leitfaden

Uptime Monitoring

AlertsDock gives teams uptime monitoring for websites, APIs, TCP checks, DNS checks, SSL expiry, and fast alert routing without enterprise overhead.

Leitfaden lesen

Alternativseite

Better Stack Alternative

Compare AlertsDock with Better Stack for teams that want a more focused monitoring product covering uptime, cron jobs, status pages, and webhooks.

Vergleich ansehen
AD
AlertsDock Team
16 April 2026
Try AlertsDock free