Was sind die häufigsten Ursachen für schlechte Core Web Vitals?

Was Core Web Vitals messen und warum sie zählen

Google hat mit den Core Web Vitals drei messbare Kennzahlen definiert, die beschreiben, wie sich eine Website für echte Nutzer anfühlt. Seit dem Page Experience Update 2021 sind sie kein weicher Qualitätshinweis mehr, sondern harter Rankingfaktor.

LCP (Largest Contentful Paint) misst, wie lange es dauert, bis das größte sichtbare Element einer Seite — meistens ein Bild oder eine Überschrift — vollständig geladen ist. Ein guter Wert liegt unter 2,5 Sekunden, alles über 4 Sekunden gilt als schlecht. LCP ist der wichtigste der drei Werte, weil er die wahrgenommene Ladegeschwindigkeit direkt abbildet.

INP (Interaction to Next Paint) hat seit März 2024 den alten FID-Wert ersetzt und misst, wie schnell eine Seite auf Klicks, Tastatureingaben und Tippen reagiert. Unter 200 Millisekunden ist gut, über 500 Millisekunden schlecht. Hohe INP-Werte entstehen häufig durch schweres JavaScript, das den Browser-Hauptthread blockiert.

CLS (Cumulative Layout Shift) misst, wie stark sich Seitenelemente während des Ladens unerwartet verschieben — etwa wenn ein Klick danebengeht, weil sich ein Element im letzten Moment noch bewegt hat. Ein Wert unter 0,1 gilt als gut. Häufige Ursachen sind Bilder ohne definierte Dimensionen, nachladende Werbebanner und Web Fonts, die spät eingeblendet werden.

Die häufigsten Ursachen für schlechte Werte

Die häufigsten Performance-Killer lassen sich klar benennen:

• Unkomprimierte und falsch formatierte Bilder: Bilder verursachen bei den meisten Websites 60–80 % des übertragenen Datenvolumens. Moderne Formate wie WebP (ca. 30 % kleiner als JPEG) und AVIF (ca. 50 % kleiner) reduzieren die Dateigröße erheblich.
• Blockierendes JavaScript und CSS: Skripte im Kopfbereich ohne defer oder async blockieren das gesamte HTML-Parsing und verzögern damit den LCP direkt.
• Fehlende Caching-Header: Ohne Cache-Direktiven laden Browser bei jedem Seitenaufruf alle Ressourcen neu — das verlangsamt wiederkehrende Besuche unnötig.
• Schlechtes Hosting und fehlende Server-Optimierungen: Shared Hosting mit hohen TTFB-Werten (Time to First Byte über 600 ms) ist ein unterschätzter Bremsklotz. GZIP- oder Brotli-Komprimierung, HTTP/2 oder HTTP/3 sowie ein CDN wirken dagegen.
• Web Fonts ohne font-display: swap: Extern eingebundene Schriften verursachen zusätzliche DNS-Lookups und blockieren oft das Text-Rendering — zusätzlich ein DSGVO-Thema, wenn Google Fonts extern eingebunden werden statt lokal gehostet.
• Falsches oder fehlendes Lazy-Loading: Wird das Hero-Bild oberhalb der sichtbaren Fläche zu spät oder verzögert geladen, statt priorisiert (fetchpriority="high"), verschlechtert das den LCP direkt.
• Elemente ohne feste Breite und Höhe: Bilder ohne width/height, nachgeladene Werbebanner ohne Platzhalter-Container und Fonts mit Flash of Unstyled Text (FOUT) sind die klassischen CLS-Verursacher.
• Zu viele Third-Party-Scripts: Chat-Widgets, Marketing-Tools und Analytics-Skripte belasten den Main Thread und verschlechtern den INP, wenn sie nicht verzögert geladen werden.
• Page-Builder-Bloat: Elementor, Divi oder WPBakery laden CSS und JavaScript auch auf Seiten, die sie nicht benötigen. Ein realer Vergleich: Eine handgecodete WordPress-Seite mit identischem Design lädt in 0,8 Sekunden, dieselbe Seite mit Elementor ohne weitere Optimierung in 3,2 Sekunden.

Was schlechte Werte konkret kosten: 53 Prozent der Nutzer verlassen eine mobile Seite, die länger als drei Sekunden lädt, und jede zusätzliche Sekunde Ladezeit erhöht die Absprungrate um rund 32 Prozent. Wer in Google Ads investiert und auf eine langsame Landing-Page verweist, zahlt für Besucher, die sofort wieder abspringen.

So messen Sie Core Web Vitals richtig

Für die Messung stehen mehrere Tools zur Verfügung, die unterschiedliche Perspektiven liefern. Wichtig ist, zwei Datenarten zu unterscheiden: Labordaten aus kontrollierten Tests und Felddaten aus echten Nutzer-Messungen.

• PageSpeed Insights (pagespeed.web.dev): Der wichtigste Einstieg — zeigt Felddaten aus dem Chrome User Experience Report (CrUX) und Labordaten mit konkreten Optimierungshinweisen. Immer für Mobile auswerten, nicht für Desktop.
• Chrome DevTools (Lighthouse-Tab): Detaillierte Audits mit Scores für Performance, Accessibility, Best Practices und SEO. Gut für Entwickler, liefert aber nur Labordaten.
• Google Search Console (Bericht „Core Web Vitals"): Zeigt Felddaten aus echten Nutzern, gruppiert nach URL-Gruppen — die verlässlichste Quelle, dauert aber Wochen, bis genug Daten vorliegen.
• WebPageTest (webpagetest.org): Tests von verschiedenen Standorten und Verbindungsgeschwindigkeiten, mit Waterfall-Diagramm, das exakt zeigt, welche Ressource wann lädt und was blockiert.

Schritt für Schritt: URL bei PageSpeed Insights eingeben (immer Mobile), Felddaten vor Labordaten gewichten, das größte sichtbare Element als LCP-Kandidat identifizieren, blockierende Skripte über die Diagnose-Hinweise finden, Elemente ohne feste Dimensionen für CLS prüfen, nach Impact priorisieren und nach der Umsetzung erneut messen — für belastbare Felddaten mindestens zwei Wochen warten.

Konkrete Optimierungsmaßnahmen

Die größten Gewinne liegen meist in drei Bereichen: Bildoptimierung, JavaScript-Reduzierung und CSS-Optimierung.

Bei Bildern zählt das Format (WebP als Standard, AVIF für noch bessere Komprimierung mit JPEG-Fallback über das picture-Element), Lazy Loading für Bilder unterhalb der sichtbaren Fläche (loading="lazy") bei gleichzeitiger Priorisierung des Hero-Bildes (fetchpriority="high") sowie responsive Bildgrößen über srcset und sizes.

Bei JavaScript hilft Code Splitting, das den Code in kleinere, bedarfsgesteuerte Chunks trennt, sowie Tree Shaking, das ungenutzten Code automatisch aus dem Build entfernt. Drittanbieter-Skripte sollten regelmäßig auf ihren tatsächlichen Nutzen geprüft werden — jedes davon kostet Performance.

Bei CSS lohnt sich Critical CSS: Die für den sichtbaren Bereich nötigen Styles werden inline eingebettet, damit der Browser sofort rendern kann, während der Rest asynchron nachlädt. Tools wie PurgeCSS helfen, ungenutzten CSS-Code zu identifizieren — bei großen Frameworks können das schnell hunderte Kilobyte sein.

Monitoring statt Einmalprojekt

Web Performance ist kein einmaliges Projekt. Jedes neue Plugin, jede neue Bildergalerie, jeder neue Drittanbieter-Dienst kann die Performance verschlechtern. Die Google Search Console zeigt unter „Erfahrung → Seitenleistung" die Core-Web-Vitals-Bewertung für alle indexierten Seiten auf Basis echter Nutzerdaten. Für technische Teams empfiehlt sich zusätzlich ein Monitoring-Tool wie Lighthouse CI, das bei jedem Deployment automatisch einen Performance-Test ausführt und bei Rückschritten warnt. Als Faustregel: nach jedem größeren Deployment die Werte prüfen und Budget-Grenzen festlegen, etwa LCP maximal 2,5 Sekunden oder JavaScript maximal 150 KB gzipped.