Ein Entwicklerleitfaden zu den Core Web Vitals

Die Core Web Vitals sind Googles Versuch, das Gefühl von „schnell" messbar zu machen – und sie fließen direkt in das Suchranking ein. Es gibt drei: LCP misst das Laden, INP misst die Reaktionsfähigkeit und CLS misst die visuelle Stabilität. Gute Werte zu erzielen ist keine Frage eines einzigen Tricks, sondern des Verständnisses, was jede Metrik misst – und der gezielten Behebung der Dinge, die sie zum Scheitern bringen.

LCP, Largest Contentful Paint

LCP ist die Zeit, bis das größte Element im Viewport – in der Regel ein Hero-Image oder ein Überschriften-Block – vollständig gerendert ist. Das Ziel: unter 2,5 Sekunden. Häufige Ursachen für einen schlechten LCP:

• Ein großes, nicht optimiertes Hero-Image
• Render-blockierendes CSS oder JavaScript im <head>
• Langsame Serverantwort (hoher TTFB)
• Web-Fonts, die das Text-Rendering verzögern

Maßnahmen: Moderne Bildformate (WebP/AVIF) in der richtigen Größe ausliefern, das LCP-Image vorladen, kritisches CSS inline einbinden und HTML serverseitig rendern, damit der Browser sofort etwas zum Zeichnen hat. Ist der TTFB hoch, liegt das Problem im Upstream – Caching oder Hosting –, nicht im Frontend.

INP, Interaction to Next Paint

INP hat First Input Delay abgelöst und ist strenger. Es misst die Latenz von Interaktionen über den gesamten Seitenbesuch hinweg: Schaltfläche klicken – wie lange dauert es, bis der Bildschirm sichtbar reagiert? Das Ziel: unter 200 Millisekunden. Ein schlechter INP-Wert bedeutet fast immer, dass der Main Thread durch JavaScript blockiert wird.

Maßnahmen:

• Lange Tasks aufteilen, damit der Browser zwischendurch reagieren kann
• Weniger JavaScript ausliefern: Code-Splitting und Lazy-Loading für alles, was beim ersten Laden nicht benötigt wird
• Nicht kritische Arbeit mit requestIdleCallback oder durch gezieltes Yielding an den Main Thread verschieben
• Schwere synchrone Operationen in Event-Handlern vermeiden

INP ist die Metrik, an der die meisten Seiten nach der jüngsten Umstellung scheitern – und sie ist meist ein Symptom von zu viel clientseitigem JavaScript.

CLS, Cumulative Layout Shift

CLS misst unerwartete Verschiebungen – Inhalte, die während des Ladens springen. Das Ziel: unter 0,1. Die üblichen Verursacher:

• Bilder und Einbettungen ohne width- und height-Attribute
• Werbung oder Banner, die über bestehendem Inhalt eingefügt werden
• Web-Fonts, die beim Wechsel einen Reflow auslösen
• Dynamisch eingefügter Inhalt ohne reservierten Platz

Maßnahmen: Medien immer mit expliziten Abmessungen oder einem aspect-ratio versehen, Platz für alles reservieren, was verzögert lädt, und Fonts mit bewusst gewähltem font-display: optional oder swap vorladen.

Mit den richtigen Tools messen

Es gibt einen entscheidenden Unterschied: Field Data (echte Nutzer, im CrUX-Bericht von Google) beeinflusst tatsächlich das Ranking, während Lab Data (Lighthouse, ein einzelner synthetischer Lauf) nur der Diagnose dient. Ein grüner Lighthouse-Score bedeutet nichts, wenn echte Nutzer auf langsamen Mobilgeräten schlechte Werte erleben.

1. PageSpeed Insights nutzen, um sowohl Field- als auch Lab-Daten für eine URL einzusehen.
2. Die JavaScript-Bibliothek web-vitals einsetzen, um reale INP- und LCP-Werte der eigenen Nutzer zu erfassen.
3. Den Core Web Vitals-Bericht in der Search Console im Blick behalten, um Trends über die gesamte Website zu verfolgen.

Die richtige Reihenfolge

Zuerst LCP beheben (in der Regel der größte Gewinn, da SSR und Bilder betroffen sind), dann INP (JavaScript reduzieren), dann CLS (Layout-Platz reservieren). Das sollte als laufende Hygiene verstanden werden, nicht als einmaliges Audit – ein einziges schweres Drittanbieter-Skript kann monatelange Arbeit zunichtemachen.

Wenn die Search Console schlechte Vitals meldet und Sie diese ohne Rewrite ins Grüne bringen möchten, sprechen Sie uns an.