Core Web Vitals verbessern: LCP, INP und CLS in der richtigen Reihenfolge

Die meisten Ratgeber listen dreißig Optimierungen auf. Für ein Unternehmen ohne eigenes Performance-Team ist die wichtigere Frage: Was zuerst? Dieser Artikel gibt eine Reihenfolge, die von den Daten ausgeht, die Google selbst verwendet.

Welche Werte gelten als gut?

Largest Contentful Paint (LCP)

≤ 2,5 s

bis der größte Inhalt sichtbar ist

Interaction to Next Paint (INP)

≤ 200 ms

bis die Seite auf eine Eingabe reagiert

Cumulative Layout Shift (CLS)

≤ 0,1

wie stark das Layout springt

Google misst jeden Wert am 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgerät und Desktop. Eine Seite ist also erst dann „gut“, wenn drei von vier echten Besuchen die Grenze einhalten. Ein schneller Test auf deinem eigenen Rechner sagt darüber wenig.

INP hat 2024 den älteren Wert First Input Delay (FID) abgelöst. Ältere Anleitungen, die noch FID optimieren, helfen dir deshalb nur bedingt.

Wie viel bringen Core Web Vitals für das Ranking?

Google sagt klar: „Core Web Vitals are used by our ranking systems.“ Auf derselben Seite steht aber auch, dass Relevanz vorgeht. Google zeigt den passendsten Inhalt, selbst wenn dessen Seite langsam ist. Gute Werte entscheiden vor allem dann, wenn mehrere Seiten eine Suchanfrage gleich gut beantworten.

Gute Werte garantieren also keinen Platz eins, und Google schreibt selbst, dass ein perfekter Wert allein für SEO kaum die beste Verwendung deiner Zeit ist. Mein Ziel für Kundenseiten ist deshalb „gut“ bei allen drei Werten, nicht 100 Punkte in PageSpeed Insights.

Felddaten oder PageSpeed-Wert: Was zählt?

Es gibt zwei Arten von Messungen, und sie widersprechen sich oft:

Der Core-Web-Vitals-Bericht in der Search Console beruht auf den Felddaten der letzten 28 Tage. Er fasst ähnliche Seiten zu URL-Gruppen zusammen, und jede Gruppe bekommt den Status ihrer schlechtesten Metrik. Eine Gruppe mit gutem LCP und INP, aber schlechtem CLS steht also auf „Schlecht“.

In welcher Reihenfolge du vorgehst

1. Die schlechteste URL-Gruppe finden

   Öffne in der Search Console den Bericht „Core Web Vitals“ und zuerst die Ansicht für Mobilgeräte. Notiere, welche Gruppe auf „Schlecht“ steht und welche Metrik das verursacht.

2. Eine Beispielseite im Labor prüfen

   Lade eine Seite aus dieser Gruppe in PageSpeed Insights oder in den Chrome DevTools (Lighthouse und Performance-Panel). Dort siehst du, welches Element LCP auslöst, was springt oder welches Skript eine Eingabe blockiert.

3. Die eine Metrik reparieren

   Arbeite nur an der Metrik, die die Gruppe nach unten zieht, mit den Lösungen aus den Abschnitten unten. Eine Gruppe wird erst „gut“, wenn alle drei Werte gut sind.

4. Im Labor bestätigen, dann veröffentlichen

   Miss dieselbe Seite nach der Änderung erneut. Erst wenn der Laborwert sich deutlich verbessert, lohnt sich das Warten auf die Felddaten.

5. Die Korrektur in der Search Console bestätigen

   Starte beim Problem das Tracking (in der englischen Oberfläche „Start tracking“). Google beobachtet dann 28 Tage lang, ob das Problem noch auf einer URL auftritt. Neu indexiert wird dadurch nichts.

LCP verbessern: das Hauptbild früher laden

Der LCP-Leitfaden von web.dev zerlegt die Zeit in vier Teile: die Antwortzeit des Servers (TTFB), die Verzögerung, bis das LCP-Bild überhaupt angefordert wird, dessen Ladezeit und die Zeit bis zur Darstellung. Die häufigsten Ursachen und ihre Lösungen:

• Das LCP-Bild wird zu spät entdeckt: Es steckt in CSS, wird per JavaScript eingefügt oder ist mit loading="lazy" markiert. Binde es direkt im HTML ein und gib ihm fetchpriority="high". Das LCP-Bild nie lazy laden.
• Das Bild ist zu groß: passende Größen über srcset, moderne Formate wie AVIF oder WebP, Auslieferung über ein CDN.
• Der Server antwortet langsam: Weiterleitungen vermeiden, Seiten im CDN zwischenspeichern und prüfen, ob Tracking-Parameter den Cache umgehen.
• CSS und Skripte blockieren die Darstellung: ungenutztes CSS entfernen, nicht kritisches CSS und JavaScript später laden, Seiten auf dem Server rendern.

Beispiel: die Startseite von anolilab.com

Diese Seite hatte selbst ein LCP-Problem. Lighthouse (Mobilgerät, gedrosseltes Netz) fand das größte Element im Video der Startseite: Sein Vorschaubild war ein 1920 Pixel breites JPEG von Cloudinary. Als poster-Attribut lässt es sich weder priorisieren noch in kleineren Größen ausliefern, also lud jedes Smartphone die große Datei, und zwar spät. Dazu lud das Spam-Widget von Cloudflare Turnstile für das Kontaktformular am Seitenende mit höchster Priorität.

Die Änderungen:

• Das Vorschaubild ist jetzt ein echtes <img> mit srcset in fünf Größen, modernem Format und fetchpriority="high", vorgeladen nur auf der Startseite.
• Smartphones bekommen das Video in 768 statt 1920 Pixel Breite. Sein erstes Bild ist dann nicht größer als das Vorschaubild und ersetzt es nicht mehr als LCP-Element.
• Turnstile lädt erst, wenn das Formular in die Nähe des sichtbaren Bereichs kommt.

Gemessen am 9. November 2026 mit Lighthouse 12.6 und echter Drosselung (devtools), Median aus fünf abwechselnden Läufen. Vorher ist die damalige Live-Seite, nachher die Vorschau mit den Änderungen. Felddaten aus der Search Console folgen frühestens vier Wochen nach dem Start.

Ehrlich gesagt ist die Arbeit nicht fertig: LCP liegt mit 3,6 Sekunden noch über der Grenze von 2,5 Sekunden, und der erste Inhalt erscheint etwas später als vorher. Der nächste Schritt ist weniger JavaScript beim Laden, das größte Skript ist 227 KiB groß.

CLS verbessern: Platz reservieren

Laut web.dev entsteht CLS fast immer an vier Stellen:

• Bilder und Videos ohne Größe: Setze width und height als Attribute. Der Browser reserviert dann den Platz, bevor das Bild geladen ist.
• Werbung, eingebettete Inhalte und iframes: Reserviere den Platz mit min-height oder aspect-ratio, auch wenn keine Anzeige kommt.
• Nachträglich eingefügte Inhalte, etwa Banner über dem Text: Platz vorab freihalten oder sie erst nach einer Nutzeraktion einblenden.
• Webfonts: Eine Ersatzschrift, die per size-adjust so breit läuft wie die echte Schrift, und das Vorladen der wichtigsten Schriftdatei verhindern den Sprung beim Austausch.

Animationen über transform statt über top oder left zählen nicht zu CLS.

INP verbessern: den Hauptthread freihalten

Eine Interaktion besteht laut web.dev aus drei Teilen: der Wartezeit, bis dein Code startet, der Ausführung und der Zeit bis zum nächsten Bild. Schlechte INP-Werte entstehen, wenn JavaScript den Browser beschäftigt hält:

• Lange Aufgaben aufteilen: Erst das sichtbare Ergebnis zeigen, den Rest danach erledigen, zum Beispiel mit setTimeout innerhalb von requestAnimationFrame.
• Das DOM klein halten: Je mehr Elemente eine Seite hat, desto teurer wird jede Aktualisierung. content-visibility verschiebt die Darstellung von Inhalten außerhalb des Bildschirms.
• HTML nicht komplett im Browser erzeugen: Vom Server gestreamtes HTML lässt dem Browser zwischendurch Zeit für Eingaben.

Zählen Core Web Vitals für KI-Antworten?

Für AI Overviews und den KI-Modus nennt Google keine zusätzlichen Anforderungen. Eine Seite muss indexiert sein und mit einem Snippet in der Suche erscheinen können. Eine gute Seitenerfahrung führt Google dort unter den Grundlagen auf, die sich weiterhin lohnen. Für KI-Antworten brauchst du also keine eigene Optimierung, sondern dieselben guten Werte.

Selbst machen oder Hilfe holen?

• Ein großes Bild oder fehlende Bildgrößen sind die Ursache: Das schafft dein Team oder deine Agentur meist selbst, mit den Punkten oben.
• Der Server oder das Hosting ist langsam: Das ist oft eine Frage von Caching und CDN, nicht von Code. Kläre es zuerst mit deinem Hoster.
• INP ist schlecht, oder die Ursache liegt in einem Framework wie React oder Next.js: Hier braucht es jemanden, der den Code profilen und umbauen kann. Plugins und Einstellungen helfen dann selten.