Core Web Vitals verbessern: Praxistipps für schnelle Sites

Google bewertet Websites seit 2021 offiziell anhand der Core Web Vitals. Wer die drei Metriken LCP, INP und CLS ignoriert, riskiert schlechtere Rankings und verliert Nutzer schon in den ersten Sekunden. Dabei sind viele der häufigsten Probleme mit überschaubarem Aufwand lösbar, wenn man weiß, wo man anfangen soll.

Was die drei Metriken tatsächlich messen

Bevor man optimiert, lohnt ein kurzer Blick auf die Definitionen. Der Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element einer Seite vollständig geladen ist. Google empfiehlt einen Wert unter 2,5 Sekunden. Werte über 4 Sekunden gelten als schlecht. In der Praxis ist das LCP-Element meistens ein Hero-Bild oder eine große Überschrift.

Der Interaction to Next Paint (INP) löste 2024 den alten FID ab und misst die Reaktionsfähigkeit auf Nutzereingaben. Ein guter Wert liegt unter 200 Millisekunden. Der Cumulative Layout Shift (CLS) erfasst, wie stark sich Seitenelemente während des Ladens verschieben. Ein CLS-Score unter 0,1 gilt als gut. Wer schon erlebt hat, dass ein Werbe-Banner nachlädt und dabei den kompletten Textinhalt nach unten schiebt, kennt das Problem aus der Nutzerperspektive.

LCP beschleunigen: Das Hero-Bild ist meist der Flaschenhals

In den meisten Fällen verursacht das Hero-Bild den schlechten LCP-Wert. Zwei Maßnahmen helfen sofort:

• Preload-Hint setzen: Ein rel="preload"-Tag im HTML-Head weist den Browser an, das LCP-Bild sofort zu laden, ohne auf den Parser warten zu müssen. Das kann den LCP-Wert allein um 0,5 bis 1 Sekunde verbessern.
• Modernes Bildformat verwenden: WebP ist gegenüber JPEG bei vergleichbarer Qualität rund 25 bis 35 Prozent kleiner. AVIF spart nochmals bis zu 50 Prozent gegenüber JPEG, wird aber von älteren Browsern nicht unterstützt. Eine Kombination aus AVIF mit JPEG-Fallback über das <picture>-Element ist die sicherste Lösung.

Wichtig: Das LCP-Bild sollte niemals lazy-loaded werden. Viele Themes und Plugins setzen pauschal loading="lazy" auf alle Bilder, was beim Hero-Bild kontraproduktiv ist. Der Attribut-Wert für das erste sichtbare Bild muss explizit auf eager gesetzt werden oder ganz wegfallen.

INP verbessern: JavaScript ist fast immer der Schuldige

Ein hoher INP-Wert entsteht fast immer durch zu viel JavaScript, das den Main Thread blockiert. Das Werkzeug der Wahl zur Diagnose ist das Performance-Panel in den Chrome DevTools. Dort lässt sich exakt sehen, welche Skripte während einer Nutzerinteraktion wie lange laufen.

Drei Stellschrauben haben in der Praxis den größten Effekt:

• Drittanbieter-Skripte verzögern: Tag-Manager, Chat-Widgets und Marketing-Pixel laufen oft direkt beim Seitenaufruf und blockieren den Main Thread für mehrere hundert Millisekunden. Ein Laden dieser Skripte erst nach dem ersten Nutzerinteraktion (defer oder Event-basiertes Laden) entlastet den INP deutlich.
• Long Tasks aufbrechen: Jede JavaScript-Aufgabe, die länger als 50 Millisekunden läuft, gilt als Long Task. Mit setTimeout(fn, 0) oder der neueren scheduler.yield()-API lassen sich lange Aufgaben in kürzere Abschnitte teilen, sodass der Browser zwischendurch auf Eingaben reagieren kann.
• Unnötige Event-Listener entfernen: Viele WordPress-Plugins hängen Event-Listener global an das Dokument, auch wenn sie auf einer bestimmten Seite gar nicht gebraucht werden. Ein Audit mit dem Coverage-Tool in Chrome zeigt, wie viel JavaScript überhaupt genutzt wird.

CLS vermeiden: Platz reservieren, bevor Inhalte laden

Layout-Verschiebungen entstehen, wenn der Browser Platz für ein Element nicht kennt, bevor es geladen ist. Die Lösung ist fast immer, diesen Platz im Voraus zu reservieren.

Für Bilder bedeutet das: Immer width und height-Attribute im <img>-Tag setzen. Browser nutzen diese Werte seit einigen Jahren, um das Seitenverhältnis zu berechnen und entsprechend Platz freizuhalten, noch bevor das Bild geladen ist. Bei eingebetteten Videos und iFrames hilft die CSS-Technik des Padding-Hack oder die neuere aspect-ratio-Eigenschaft.

Webfonts sind eine häufig unterschätzte Ursache für CLS. Wenn ein System-Font als Fallback angezeigt wird und beim Laden des eigentlichen Webfonts Textblöcke springen, schlägt sich das direkt im CLS nieder. font-display: optional verhindert das Springen vollständig, weil der Webfont nur genutzt wird, wenn er rechtzeitig verfügbar ist. font-display: swap ist die häufiger empfohlene Variante, erzeugt aber in manchen Fällen selbst messbare Verschiebungen.

Caching und Serverantwortzeiten nicht vergessen

Alle bisher genannten Optimierungen nützen wenig, wenn der Server schon für die erste Byte-Antwort zu lange braucht. Der Time to First Byte (TTFB) ist kein offizieller Core Web Vital, beeinflusst aber direkt den LCP. Ein TTFB unter 200 Millisekunden ist ein realistisches Ziel für die meisten Websites.

Statisches HTML-Caching ist die effektivste Maßnahme. Bei WordPress-Seiten reduziert ein Plugin wie WP Rocket oder LiteSpeed Cache den TTFB von typischen 400 bis 800 Millisekunden auf unter 100 Millisekunden, weil PHP und Datenbankabfragen nur beim ersten Aufruf einer Seite ausgeführt werden. Für Projekte, bei denen professionelle Unterstützung gefragt ist, lohnt sich ein Blick auf Agenturen wie responsive-webdesigners.de, die sich auf performantes Webdesign spezialisiert haben.

Ein CDN (Content Delivery Network) verkürzt die physische Distanz zwischen Server und Nutzer. Cloudflare bietet in der kostenlosen Variante bereits einen deutlichen Unterschied für Besucher aus entfernten Regionen. Für rein europäische Zielgruppen ist ein europäischer Serverstandort in vielen Fällen ausreichend.

Messen, priorisieren, iterieren

Der erste Schritt jeder Optimierung ist eine ehrliche Bestandsaufnahme. Google PageSpeed Insights gibt sowohl Labordaten als auch Felddaten aus dem Chrome User Experience Report (CrUX) aus. Letztere sind für das Google-Ranking maßgeblich, weil sie echtes Nutzerverhalten abbilden und nicht nur einen einzelnen Testlauf.

Die Metriken können sich dabei je nach Gerät stark unterscheiden. Eine Seite, die auf Desktop hervorragende Werte erzielt, kann auf einem Mid-Range-Android-Gerät mit langsamer Mobilverbindung erheblich schlechter abschneiden. PageSpeed Insights simuliert mit seiner mobilen Analyse ein Gerät der Mittelklasse mit gedrosselter Verbindung, was realistischer ist als viele denken.

Wer Core Web Vitals systematisch verbessern will, sollte nicht versuchen, alles gleichzeitig anzugehen. Eine pragmatische Reihenfolge: zuerst LCP, weil er den größten Einfluss auf die wahrgenommene Ladezeit hat, dann CLS, weil er oft mit wenigen CSS-Korrekturen stark verbessert werden kann, und schließlich INP, der meistens die aufwendigste JavaScript-Arbeit erfordert.