Core Web Vitals verbessern: LCP, INP und CLS erklärt

Mit den Core Web Vitals bewertet Google, wie sich eine Seite für echte Besucher anfühlt: Largest Contentful Paint (LCP) steht für das Laden, Interaction to Next Paint (INP) für die Reaktionsgeschwindigkeit und Cumulative Layout Shift (CLS) für die visuelle Stabilität. Bestanden hast du, wenn mindestens 75 % der Seitenaufrufe einen LCP von höchstens 2,5 Sekunden, einen INP von höchstens 200 Millisekunden und einen CLS von höchstens 0,1 erreichen. Hier erfährst du, was hinter jeder Kennzahl steckt und mit welchen Maßnahmen du sie in der Praxis verbesserst.

Die drei Kennzahlen im Überblick

Google legt für jede Kennzahl feste Grenzwerte fest und sortiert die Ergebnisse in drei Stufen ein. Die Werte stammen aus der Übersicht zu den Core Web Vitals auf web.dev.

Zwei Details werden dabei oft übersehen:

• Entscheidend ist das 75. Perzentil. Google schaut weder auf deinen schnellsten noch auf einen durchschnittlichen Aufruf. Maßgeblich ist der Wert, den 75 % der Seitenaufrufe erreichen oder unterbieten, und zwar getrennt für Mobilgeräte und Desktop. Schon ein Teil langsamer Smartphones mit schwachem Netz kann eine Seite deshalb in den gelben Bereich ziehen.
• INP hat im März 2024 den FID abgelöst. First Input Delay hat nur gemessen, wie lange die erste Interaktion warten musste. INP betrachtet dagegen die Reaktionszeit aller Interaktionen während des gesamten Besuchs. Für Seiten mit viel JavaScript ist das eine deutlich strengere Prüfung.

Felddaten und Labordaten

Wenn du eine Seite auf corewebvitals.page prüfst, bekommst du zwei Arten von Ergebnissen. Und die widersprechen sich häufig.

• Felddaten stammen aus dem Chrome User Experience Report und bilden echte Chrome-Nutzer über ein rollierendes Fenster von 28 Tagen ab. Genau diese Daten zählen für die Bewertung in der Search Console.
• Labordaten, also der Lighthouse-Score, beruhen auf einem einzigen simulierten Ladevorgang mit gedrosseltem Gerät. Zur Fehlersuche sind sie ideal, weil du sie beliebig wiederholen kannst. INP können sie aber gar nicht messen, denn während des Tests klickt niemand. Lighthouse zeigt ersatzweise die Total Blocking Time an.

Weil die Felddaten bis zu 28 Tage zurückreichen, wird eine Verbesserung erst nach und nach sichtbar. Prüfe eine Änderung deshalb zuerst im Labortest und beobachte dann, wie sich die Felddaten einpendeln. Wie ein belastbarer Vorher-nachher-Vergleich aussieht, zeigt unser Ratgeber Ladezeit einer Website richtig messen.

LCP verbessern

Am LCP scheitern viele Websites. Zum Glück lässt sich gerade diese Kennzahl gut eingrenzen, denn Google zerlegt sie laut dem LCP-Artikel auf web.dev in vier Abschnitte:

1. Time to First Byte: Wie lange der Server braucht, bis er das HTML zu senden beginnt.
2. Ladeverzögerung: Die Zeit zwischen dem ersten Byte und dem Moment, in dem der Browser das LCP-Bild anfordert.
3. Ladedauer: Wie lange der Download des LCP-Bilds selbst dauert.
4. Renderverzögerung: Die Zeit zwischen dem fertig geladenen Bild und seiner Darstellung.

Schau dir an, welcher Abschnitt den größten Anteil hat, bevor du etwas änderst. Das Panel „Performance“ in den Chrome DevTools zeigt dir das LCP-Element und wie sich seine Zeit aufteilt.

Der Server antwortet zu langsam

Wenn allein die TTFB eine Sekunde oder mehr verschlingt, kommst du auch mit perfekt optimierten Bildern nicht unter 2,5 Sekunden. Typische Ursachen sind Seiten, die PHP und Datenbank bei jedem Aufruf neu erzeugen, ein Server weit weg von deinen Besuchern oder langsame Plugins. Abhilfe schafft meist ein Seitencache, entweder auf dem Server oder am Edge. Alle Stellschrauben findest du im Ratgeber TTFB verbessern.

Der Browser entdeckt das LCP-Bild zu spät

Bilder findet der Browser, während er das HTML liest. Steckt dein Titelbild in einem CSS-Hintergrund, wird es per JavaScript eingefügt oder per Lazy Loading nachgeladen, erfährt der Browser erst spät davon. So löst du das:

• Binde das Titelbild als normales <img>-Element ein.
• Setze beim LCP-Bild niemals loading="lazy".
• Gib dem Browser mit fetchpriority="high" oder einem Preload-Hinweis zu verstehen, dass er das Bild früh laden soll:

<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">

Das LCP-Bild ist zu schwer

Ein 3000 Pixel breites JPEG, das mit 1200 Pixeln angezeigt wird, verschwendet bei jedem Aufruf Bandbreite. Setze auf moderne Formate wie WebP oder AVIF, liefere das Bild in der passenden Größe aus und nutze srcset für unterschiedliche Bildschirme. Mehr dazu liest du in unserem Ratgeber Bilder für die Website optimieren.

CSS und Schriften blockieren das Rendern

Große Stylesheets und synchrone Skripte im <head> halten die Darstellung auf, auch wenn das Bild längst da ist. Bette kritisches CSS direkt ins HTML ein, lade unwichtige Skripte mit defer und halte deine Webfonts schlank.

INP verbessern

INP misst die Zeit von einer Interaktion bis zum nächsten Frame, den der Browser zeichnet. Das ist fast immer ein JavaScript-Problem und kein Netzwerkproblem. Der INP-Artikel auf web.dev teilt die Zeit in Eingabeverzögerung, Verarbeitungszeit und Darstellungsverzögerung auf.

Die häufigsten Ursachen und was du dagegen tun kannst:

• Lange Tasks im Main Thread. Jedes Skript, das länger als 50 ms läuft, hindert die Seite am Reagieren. Teile lange Aufgaben in kleinere Stücke auf und gib dem Browser dazwischen Zeit.
• Zu viel Drittanbieter-JavaScript. Chat-Widgets, Tag-Manager, A/B-Test-Tools und Werbeskripte konkurrieren alle um den Main Thread. Prüfe, was geladen wird, und wirf raus, was niemand nutzt.
• Aufwendige Event-Handler. Wenn ein Klick eine komplette Produktliste neu rendert oder viele Layout-Werte synchron ausliest, fühlt sich die Seite träge an. Aktualisiere nur, was sich wirklich ändert, und zeige sofort ein sichtbares Feedback, bevor die teure Arbeit startet.
• Ein riesiger DOM. Bei Seiten mit Tausenden Elementen dauert jede Neuberechnung von Styles und Layout länger. Page Builder sind hier ein häufiger Grund.

Ein CDN oder Cache hilft beim INP nur indirekt: Skripte sind zwar schneller geladen, laufen müssen sie aber trotzdem auf dem Gerät deiner Besucher.

CLS verbessern

CLS bewertet die größte Häufung unerwarteter Layoutverschiebungen, solange die Seite offen ist. Verschiebungen innerhalb von 500 ms nach einer Nutzeraktion zählen nicht mit, ein Akkordeon, das sich nach einem Klick öffnet, ist also kein Problem. Wie die Bewertung genau funktioniert, erklärt der CLS-Artikel auf web.dev.

Die üblichen Verdächtigen:

• Bilder und Videos ohne Maße. Fehlen die Attribute width und height oder ein CSS-aspect-ratio, reserviert der Browser keinen Platz und schiebt den Inhalt nach unten, sobald die Datei ankommt.
• Werbung, Embeds und Banner über dem Inhalt. Reserviere ihnen einen festen Platz oder setze sie unter den sichtbaren Bereich.
• Cookie-Banner, die die Seite verschieben. Blende sie als Overlay ein, statt sie oben ins Dokument einzufügen.
• Webfonts, die nachladen. Wird die Fallback-Schrift durch den Webfont ersetzt, kann der Text neu umbrechen. font-display: swap sorgt dafür, dass Text früh sichtbar ist. Passt du zusätzlich die Metriken der Fallback-Schrift an, etwa mit size-adjust, verrutscht beim Wechsel nichts mehr.

Beeinflussen die Core Web Vitals das Ranking?

Die Core Web Vitals gehören zu Googles Signalen für die Nutzerfreundlichkeit von Seiten. Google sagt dazu, dass die Ranking-Systeme eine gute Nutzererfahrung belohnen, Relevanz und Qualität der Inhalte aber an erster Stelle stehen. Bestandene Core Web Vitals heben also keine schwache Seite nach oben, und durchgefallene versenken keine Seite, die eindeutig die beste Antwort liefert.

Der bessere Grund, dich darum zu kümmern, sind deine Besucher. Lange Ladezeiten, träge Buttons und springende Layouts kosten dich Anfragen und Umsatz, ganz egal, was ein Algorithmus daraus macht. Sieh die Grenzwerte deshalb als Qualitätsmaßstab für Menschen und nicht als SEO-Trick.

So hilft dir fast.site

fast.site arbeitet vor deinem bestehenden Hosting. Du behältst also deinen Hoster und dein CMS. Du stellst die Nameserver deiner Domain auf fast.site um, danach läuft der Traffic je nach Tarif über ein Edge-Netzwerk mit Regionen in Nordamerika, Europa, Asien-Pazifik und Südamerika.

Beim LCP setzt der Fast Edge Cache™ an: Er liefert gecachte Seiten und Dateien vom nächstgelegenen Edge aus. Bei einem Cache-HIT muss niemand auf deinen Ursprungsserver warten, das verkürzt TTFB und Ladedauer. Die Bildoptimierung wandelt JPEG und PNG für unterstützende Browser direkt in WebP um, AVIF ist je nach Tarif verfügbar.

Die optionale HTML-Optimierung nimmt sich typische LCP- und CLS-Probleme direkt vor. Dabei lädt sie das erkannte Titelbild per Preload vor, ergänzt fehlende Breiten- und Höhenangaben bei Bildern und fügt Webfonts font-display: swap hinzu. Einzelheiten stehen in der Dokumentation zur HTML-Optimierung.

Langsames JavaScript kann fast.site nicht reparieren, am INP arbeitest du also weiter im Code. Miss das Ergebnis vorher und nachher auf deiner eigenen Website: Der Header fs-cache zeigt HIT, MISS oder BYPASS, und die Analytics weisen TTFB und Cache-Trefferquote aus. Ausprobieren kannst du das mit einer kostenlosen 7-Tage-Testphase ohne Kreditkarte. Die Tarife findest du unter Preise.

Häufige Fragen

Welche Werte gelten bei den Core Web Vitals als gut?

Eine Seite besteht, wenn beim 75. Perzentil der Aufrufe der LCP höchstens 2,5 Sekunden, der INP höchstens 200 Millisekunden und der CLS höchstens 0,1 beträgt. Alle drei Werte müssen im grünen Bereich liegen. Mobilgeräte und Desktop werden getrennt bewertet.

Warum ist mein PageSpeed-Score gut, die Search Console meldet aber Probleme?

Der Lighthouse-Score beruht auf einem einzelnen Labortest mit simuliertem Gerät, die Search Console dagegen auf 28 Tagen echter Chrome-Nutzerdaten. Echte Besucher haben oft langsamere Smartphones und schlechtere Verbindungen als der Test, und INP misst der Labortest überhaupt nicht. Für die Bewertung zählen die Felddaten, der Labortest hilft dir bei der Fehlersuche.

Wie lange dauert es, bis sich Verbesserungen zeigen?

Die Felddaten beruhen auf einem rollierenden Zeitraum von 28 Tagen. Verbesserungen werden deshalb über rund vier Wochen nach und nach sichtbar, und die Berichte in der Search Console brauchen manchmal etwas länger. Im Labortest siehst du die Änderung sofort.

Verbessert ein CDN die Core Web Vitals?

Ein CDN hilft vor allem beim LCP, weil Serverantwort und Download für weit entfernte Besucher schneller werden. Beim CLS kann es indirekt helfen, wenn es HTML-Optimierungen wie ergänzte Bildmaße anbietet. Der INP hängt überwiegend vom JavaScript im Browser ab, darauf hat ein CDN kaum direkten Einfluss.

Was ist aus dem First Input Delay (FID) geworden?

Seit März 2024 ist Interaction to Next Paint (INP) anstelle des FID eine Core-Web-Vitals-Kennzahl. INP berücksichtigt alle Interaktionen während eines Besuchs statt nur der ersten und bezieht auch die Zeit bis zur sichtbaren Reaktion ein.