Eine Website kann technisch in zwei Sekunden geladen sein und sich trotzdem langsam anfühlen. Vielleicht erscheint zuerst nur ein leerer Bereich. Vielleicht ist der Inhalt sichtbar, aber der Menü-Button reagiert eine halbe Sekunde zu spät. Oder der Leser möchte gerade auf einen Link klicken und im selben Moment springt eine nachgeladene Werbefläche in die Seite.

Genau solche Erfahrungen versuchen die Core Web Vitals messbar zu machen.

Google verwendet derzeit drei Core Web Vitals: Largest Contentful Paint (LCP) für die wahrgenommene Ladeleistung, Interaction to Next Paint (INP) für die Reaktionsfähigkeit und Cumulative Layout Shift (CLS) für die visuelle Stabilität. Die Metriken sollen reale Nutzererfahrung abbilden und werden anhand echter Seitenaufrufe bewertet.

Core Web Vitals messen nicht einfach „die Ladezeit“

Die klassische Frage „Wie lange braucht die Website zum Laden?“ ist überraschend schwer zu beantworten.

Wann ist eine Seite geladen?

Wenn der Server antwortet?

Wenn der erste Text erscheint?

Wenn das große Titelbild sichtbar ist?

Wenn sämtliche Bilder im Footer geladen wurden?

Wenn alle JavaScript-Funktionen reagieren?

Core Web Vitals zerlegen diese sehr unterschiedlichen Aspekte deshalb in eigene Messwerte. LCP betrachtet einen wichtigen Moment des sichtbaren Seitenaufbaus, INP die Reaktionsfähigkeit während der Nutzung und CLS unerwartete Verschiebungen im Layout.

Die drei aktuellen Core Web Vitals

Für LCP gilt derzeit ein Wert von höchstens 2,5 Sekunden als gut. Beim INP liegt der gute Bereich bei höchstens 200 Millisekunden. Für CLS gilt 0,1 oder weniger als gut. Als schlecht gelten LCP-Werte über 4 Sekunden, INP-Werte über 500 Millisekunden und CLS-Werte über 0,25; dazwischen liegt jeweils der Bereich „verbesserungswürdig“.

Diese Zahlen sind nützlich. Sie sollten aber nicht dazu verleiten, Website-Performance auf drei Ampelfarben zu reduzieren.

Die wesentlich interessantere Frage lautet:

Warum erreicht eine Seite einen schlechten Wert?

Core Web Vitals sind vor allem Felddaten

Ein wichtiger Punkt wird bei Core Web Vitals häufig übersehen: Sie sind in erster Linie für die Messung realer Nutzererfahrung gedacht.

Google empfiehlt für die Bewertung das 75. Perzentil der Seitenaufrufe, getrennt nach Geräteklassen. Vereinfacht bedeutet das: Mindestens drei Viertel der betrachteten Besuche sollten den jeweiligen guten Grenzwert erreichen, damit die Metrik als gut eingestuft wird.

Ein einzelner perfekter Test auf deinem leistungsfähigen Bürorechner sagt deshalb noch wenig darüber aus, wie deine Website tatsächlich erlebt wird.

Was bedeutet das 75. Perzentil?

Angenommen, 100 Menschen besuchen eine Seite.

Viele besitzen schnelle Smartphones und gute Internetverbindungen.

Andere verwenden ältere Geräte, Mobilfunk oder ein überlastetes WLAN.

Wenn man lediglich den Durchschnitt betrachtet, können sehr schnelle Besuche langsamere Nutzer stark ausgleichen.

Das 75. Perzentil betrachtet die Verteilung anders. Der Wert wird so gewählt, dass ungefähr 75 Prozent der erfassten Seitenaufrufe mindestens genauso gut oder besser abgeschnitten haben. Google verwendet diesen Ansatz, um die Mehrheit der Nutzer zu berücksichtigen, ohne einzelne extreme Ausreißer zu stark über die Bewertung entscheiden zu lassen.

Gute Werte auf meinem Computer reichen deshalb nicht

Vielleicht öffnet sich deine Website auf deinem Rechner in einer Sekunde.

Das ist erfreulich.

Deine Besucher können aber völlig andere Bedingungen besitzen:

älteres Smartphone,

schwächere CPU,

langsamere Mobilfunkverbindung,

größere geografische Entfernung,

anderer Browserzustand,

kalter Cache.

Core Web Vitals interessieren sich deshalb nicht nur dafür, was unter optimalen Bedingungen möglich ist.

Sie interessieren sich dafür, was echte Nutzer tatsächlich erleben.

Largest Contentful Paint: Wann erscheint der Hauptinhalt?

LCP steht für Largest Contentful Paint.

Der Messwert betrachtet den Zeitpunkt, an dem das größte relevante Bild-, Text- oder Videoelement innerhalb des sichtbaren Bereichs dargestellt wurde. Die Idee dahinter: Dieses große Element entspricht häufig einem wesentlichen Teil dessen, was der Besucher als Hauptinhalt wahrnimmt.

Bei einem Artikel kann das beispielsweise sein:

das große Titelbild,

die Überschrift

oder ein größerer Textblock.

Welche Ressource tatsächlich zum LCP-Element wird, hängt von der jeweiligen Seite und Darstellung ab.

LCP ist näher an der Wahrnehmung als „Seite komplett geladen“

Ein langer Artikel kann zwanzig Bilder enthalten.

Die letzten Bilder befinden sich mehrere Bildschirmseiten weiter unten.

Für den Besucher ist es weitgehend irrelevant, ob diese Dateien bereits 1,8 oder 4 Sekunden nach dem Aufruf vollständig geladen wurden.

Interessanter ist zunächst:

Wann sehe ich den wesentlichen oberen Inhalt?

Genau deshalb konzentriert sich LCP auf ein prominentes Element im sichtbaren Bereich statt auf das Ende sämtlicher Netzwerkaktivitäten.

Ein guter LCP liegt bei höchstens 2,5 Sekunden

Google empfiehlt, am 75. Perzentil einen LCP von höchstens 2,5 Sekunden zu erreichen. Zwischen 2,5 und 4 Sekunden gilt der Wert als verbesserungswürdig; mehr als 4 Sekunden gelten als schlecht.

Das bedeutet nicht:

Bei 2,49 Sekunden ist eine Website hervorragend und bei 2,51 Sekunden plötzlich schlecht.

Die Grenzwerte sind Orientierungspunkte.

Eine Verbesserung von 3,2 auf 2,7 Sekunden kann für Nutzer deutlich spürbar sein, auch wenn die Seite damit noch nicht im grünen Bereich liegt.

Ein schlechter LCP bedeutet nicht automatisch ein zu großes Bild

Große Bilder sind ein häufiger Performancefaktor, aber LCP besteht aus mehreren Zeitabschnitten.

Google zerlegt den LCP unter anderem in die Zeit bis zum ersten Byte des HTML-Dokuments, die Verzögerung bis zum Start des LCP-Ressourcenabrufs, die eigentliche Ladezeit dieser Ressource und eine mögliche Verzögerung zwischen fertigem Download und Darstellung.

Das ist wichtig.

Ein Titelbild kann hervorragend komprimiert sein und trotzdem spät erscheinen, weil der Browser erst nach mehreren anderen Schritten erfährt, dass er es überhaupt laden soll.

Der Server kann den LCP bereits ruinieren

Wenn der Server zwei Sekunden benötigt, bevor das erste Byte des HTML-Dokuments beim Browser eintrifft, ist ein großer Teil des verfügbaren LCP-Zeitbudgets bereits verbraucht.

Mögliche Ursachen können sein:

langsames Hosting,

fehlender Page Cache,

aufwendige WordPress-Verarbeitung,

langsame Datenbankabfragen,

externe serverseitige Abhängigkeiten.

Deshalb gehören Caching und Webhosting unmittelbar zum LCP-Thema.

Das LCP-Bild sollte möglichst früh entdeckt werden

Ein typischer Fehler besteht darin, dass das wichtigste Bild erst spät im Ladeprozess gefunden wird.

Beispielsweise weil es erst über eine CSS-Datei als Hintergrundbild definiert wird oder JavaScript benötigt wird, bevor der Browser weiß, welche Ressource dargestellt werden soll.

Google weist gerade auf die Verzögerung zwischen dem Eintreffen des HTML und dem Start des LCP-Ressourcendownloads als häufig übersehenen Optimierungsbereich hin.

Ein kleines Bild, das sehr spät angefordert wird, kann deshalb schlechter sein als eine etwas größere Datei, deren Download sofort beginnt.

LCP-Optimierung ist eine Kette

Für ein großes Titelbild könnte die Kette vereinfacht so aussehen:

Browser ruft Seite auf
↓
Server antwortet
↓
HTML trifft ein
↓
Browser entdeckt Titelbild
↓
Bilddownload beginnt
↓
Bild ist vollständig
↓
Browser kann es darstellen

An jeder Stelle kann Zeit verloren gehen.

Deshalb sollte bei schlechtem LCP nicht nur gefragt werden:

Wie groß ist das Bild?

Sondern auch:

Wann erfährt der Browser überhaupt davon?

Bildoptimierung bleibt trotzdem wichtig

Wenn das LCP-Element ein fünf Megabyte großes Foto ist, bleibt die Datenmenge natürlich relevant.

Passende Abmessungen, effiziente Kompression und moderne Bildformate können helfen.

Entscheidend ist aber das Zusammenspiel.

Deshalb haben wir Bilder für Websites optimieren bewusst vor diesen Artikel gestellt: Dort geht es um die Datei selbst. Hier geht es darum, wann sie innerhalb der tatsächlichen Nutzererfahrung sichtbar wird.

Interaction to Next Paint: Wie schnell reagiert die Website?

INP steht für Interaction to Next Paint.

Der Messwert betrachtet, wie schnell eine Seite auf Benutzerinteraktionen reagiert. Dazu gehören beispielsweise Klicks, Tippen auf Touchscreens und Tastatureingaben. INP beobachtet die qualifizierenden Interaktionen über die Lebensdauer eines Seitenbesuchs und bewertet die Reaktionsfähigkeit der Seite insgesamt.

Das macht INP besonders interessant für Websites mit:

Menüs,

Filtern,

Formularen,

Tabs,

Shops,

interaktiven Anwendungen.

Sichtbar geladen bedeutet noch nicht benutzbar

Eine Website kann optisch vollständig fertig aussehen.

Der Besucher klickt auf das Menü.

Nichts passiert.

Nach einer halben Sekunde öffnet es sich plötzlich.

Die Netzwerkübertragung war möglicherweise längst abgeschlossen.

Trotzdem fühlt sich die Seite langsam an.

INP versucht genau diese Verzögerung zwischen Aktion und sichtbarer Reaktion zu erfassen.

Ein guter INP liegt bei höchstens 200 Millisekunden

Bis 200 Millisekunden gilt INP als gut. Werte über 200 bis einschließlich 500 Millisekunden liegen im verbesserungswürdigen Bereich. Über 500 Millisekunden gilt die Reaktionsfähigkeit als schlecht. Auch hier wird für die Einstufung das 75. Perzentil betrachtet.

Eine Viertelsekunde klingt zunächst nach wenig.

Bei direkter Interaktion fällt eine solche Verzögerung jedoch deutlich stärker auf als bei einem passiven Download.

Menschen erwarten bei einem Klick eine unmittelbare Reaktion.

INP betrachtet mehr als nur den Beginn der Reaktion

Eine Interaktion lässt sich vereinfacht in drei Teile aufteilen.

Zunächst kann eine Input Delay entstehen, weil der Browser noch mit anderer Arbeit beschäftigt ist.

Danach folgt die eigentliche Verarbeitung des Ereignisses.

Anschließend kann Zeit vergehen, bis der Browser das visuelle Ergebnis zeichnet.

Google beschreibt genau diese drei Phasen als Eingabeverzögerung, Verarbeitungsdauer und Darstellungsverzögerung.

Vereinfacht:

Klick
↓
Browser kann anfangen
↓
JavaScript verarbeitet Aktion
↓
Layout und Darstellung
↓
sichtbare Reaktion

INP umfasst diese ganze Erfahrung.

JavaScript ist ein häufiger INP-Faktor

Browser besitzen einen sogenannten Main Thread, auf dem viele wichtige Arbeiten stattfinden.

Wenn dort gerade eine lange JavaScript-Aufgabe läuft, kann ein Klick möglicherweise nicht sofort verarbeitet werden.

Das Menü wartet.

Der Button wartet.

Die Tastatureingabe wartet.

Besonders umfangreiche Skripte, komplexe DOM-Arbeiten und Drittanbietercode können deshalb die Reaktionsfähigkeit beeinträchtigen. Google empfiehlt bei INP-Problemen unter anderem, lange Aufgaben auf dem Main Thread zu reduzieren und die Arbeit während einer Interaktion zu begrenzen.

Mehr JavaScript ist nicht automatisch schlecht

Eine interaktive Webanwendung benötigt naturgemäß JavaScript.

Die Frage lautet nicht:

Wie entferne ich sämtliches JavaScript?

Sondern:

Welche Arbeit muss genau in diesem Moment auf dem Main Thread passieren?

Ein Konfigurator, Editor oder Shop darf selbstverständlich komplexer sein als ein statischer Artikel.

Aber auch komplexe Anwendungen können Aufgaben aufteilen, unnötige Berechnungen vermeiden und dem Benutzer möglichst schnell eine sichtbare Rückmeldung geben.

Drittanbieter können INP verschlechtern

Nicht nur eigener Code beansprucht den Browser.

Auch:

Werbeskripte,

Analytics,

Chat-Systeme,

A/B-Tests,

Consent-Lösungen

und andere eingebundene Dienste

können JavaScript ausführen.

Damit konkurrieren sie teilweise mit der eigentlichen Website um denselben Main Thread.

Das macht Drittanbieter zu einem wiederkehrenden Performance-Thema: Jeder einzelne Dienst kann einen sinnvollen Zweck besitzen. Die Summe kann trotzdem problematisch werden.

INP hat FID ersetzt

Wer ältere Performanceartikel liest, begegnet häufig First Input Delay, kurz FID.

FID war früher ein Core Web Vital und betrachtete die Eingabeverzögerung bei der ersten Interaktion.

INP bewertet die Reaktionsfähigkeit umfassender über die Nutzung einer Seite. Google hat INP am 12. März 2024 als Core Web Vital an die Stelle von FID gesetzt.

Alte Anleitungen, die weiterhin nur LCP, FID und CLS nennen, verwenden deshalb nicht mehr die aktuelle Core-Web-Vitals-Zusammenstellung.

Eine Seite kann gar keinen INP-Wert haben

INP benötigt eine tatsächliche qualifizierende Interaktion.

Wenn ein Besucher lediglich einen Artikel liest, scrollt und anschließend die Seite verlässt, kann für diesen Seitenbesuch möglicherweise kein INP-Wert entstehen. Scrollen und Hover-Bewegungen zählen nicht zu den für INP berücksichtigten Interaktionen.

Das ist logisch.

Ohne Klick, Tap oder Tastatureingabe gibt es nichts, dessen Reaktionszeit gemessen werden könnte.

Cumulative Layout Shift: Bleibt die Seite an ihrem Platz?

CLS steht für Cumulative Layout Shift.

Der Messwert beschreibt unerwartete Verschiebungen sichtbarer Seitenelemente. Dabei wird berücksichtigt, wie viel sichtbarer Inhalt sich bewegt und wie weit er verschoben wird. Anders als LCP und INP besitzt CLS keine Zeitangabe in Sekunden oder Millisekunden, sondern einen dimensionslosen Wert.

Das klassische Beispiel kennt fast jeder.

Du möchtest auf einen Link klicken.

Genau in diesem Moment erscheint oberhalb eine Werbung.

Der Text rutscht nach unten.

Du klickst versehentlich auf etwas anderes.

Das ist ein echtes Nutzungsproblem, obwohl die Website vielleicht sehr schnell geladen hat.

Ein guter CLS liegt bei höchstens 0,1

Google empfiehlt einen CLS von höchstens 0,1 am 75. Perzentil. Werte über 0,1 bis einschließlich 0,25 gelten als verbesserungswürdig; darüber als schlecht.

Der ideale Wert wäre natürlich null.

In realen Websites können kleinere Verschiebungen auftreten, ohne die Nutzung wesentlich zu beeinträchtigen.

Bilder ohne reservierten Platz sind ein typischer CLS-Auslöser

Angenommen, der Browser lädt einen Artikel.

Zunächst weiß er noch nicht, wie hoch ein Bild werden wird.

Er zeigt deshalb den nachfolgenden Text direkt darunter an.

Dann trifft das Bild ein.

Plötzlich benötigt es 500 Pixel Höhe.

Der gesamte Text springt nach unten.

Google nennt Bilder ohne definierte Dimensionen ausdrücklich als eine häufige Ursache schlechter CLS-Werte.

Die Lösung besteht nicht darin, Bilder schneller zu laden.

Besser ist, den benötigten Platz bereits vor dem Eintreffen der Datei zu kennen.

Deshalb sind width und height weiterhin wichtig

Wenn Breite und Höhe beziehungsweise das Seitenverhältnis bekannt sind, kann der Browser den erforderlichen Platz reservieren.

Das Bild kann später eintreffen, ohne den darunterliegenden Inhalt plötzlich zu verschieben.

Diese kleine technische Information macht den Seitenaufbau deutlich stabiler.

Genau deshalb gehören Bildoptimierung und CLS zusammen.

Werbung ist ein weiterer klassischer Kandidat

Werbeflächen besitzen oft dynamische Größen.

Wenn zunächst kein Platz reserviert wird und später eine 300 Pixel hohe Anzeige erscheint, muss der darunterliegende Inhalt weichen.

Dasselbe Problem können erzeugen:

Embeds,

iframes,

Social-Media-Inhalte,

Newsletterboxen,

dynamisch eingefügte Elemente.

Google nennt Anzeigen, Embeds und dynamisch injizierte Inhalte ohne vorher reservierten Platz als häufige CLS-Ursachen.

Auch Webfonts können Layout verschieben

Eine Seite beginnt möglicherweise zunächst mit einer lokal verfügbaren Ersatzschrift.

Wenig später ist die gewünschte Webfont geladen.

Die neue Schrift besitzt andere Zeichenbreiten.

Zeilen umbrechen anders.

Überschriften werden höher oder niedriger.

Dadurch können nachfolgende Inhalte verschoben werden.

Webfonts gehören deshalb ebenfalls zu den bekannten möglichen CLS-Ursachen.

Nicht jede Bewegung zählt als problematischer Layout Shift

Eine bewusst ausgelöste Animation oder eine Reaktion unmittelbar auf eine Benutzeraktion ist nicht dasselbe wie ein unerwartetes springendes Layout.

Wenn ein Besucher auf „Mehr anzeigen“ klickt und anschließend zusätzlicher Inhalt aufgeht, erwartet er eine Veränderung.

CLS soll vor allem Verschiebungen erfassen, die den Benutzer überraschen und die vorhandene Oberfläche instabil machen.

Das Ziel ist nicht, Websites vollkommen unbeweglich zu machen.

Das Ziel ist Vorhersehbarkeit.

Felddaten und Labordaten sind nicht dasselbe

Jetzt entsteht eine der häufigsten Verwirrungen rund um PageSpeed.

Du öffnest PageSpeed Insights.

Der Labortest sieht hervorragend aus.

Trotzdem meldet Google schlechte Core Web Vitals.

Oder umgekehrt.

Das kann vollkommen normal sein.

PageSpeed Insights kann reale Nutzerdaten aus dem Chrome User Experience Report – CrUX – neben Lighthouse-Diagnosedaten aus einem kontrollierten Test darstellen. Diese Daten beantworten unterschiedliche Fragen.

Felddaten fragen: Was erleben echte Besucher?

Felddaten stammen aus tatsächlichen Nutzungssituationen.

Darin steckt eine große Vielfalt:

unterschiedliche Geräte,

Netzwerke,

Standorte,

Besuchszeitpunkte,

Seitenzustände,

Interaktionen.

CrUX aggregiert solche realen Nutzungsdaten. In PageSpeed Insights basieren die angezeigten CrUX-Werte auf einem rollierenden Zeitraum der vergangenen 28 Tage.

Deshalb verändert sich ein schlechter Feldwert nicht unmittelbar am Abend nach einer Optimierung vollständig ins Grüne.

Neuere schnelle Besuche müssen erst in die aggregierte Datenbasis einfließen.

Labordaten fragen: Wie verhält sich die Seite in diesem Test?

Ein Labortest läuft unter kontrollierten Bedingungen.

Das besitzt einen großen Vorteil:

Du kannst vor einer Änderung testen.

Danach optimierst du etwas.

Anschließend testest du erneut.

Damit lassen sich Ursachen wesentlich leichter isolieren.

Labordaten sind deshalb hervorragend für Diagnose und Entwicklung.

Sie bilden aber nicht automatisch die gesamte Vielfalt der realen Nutzer ab.

Beide Datenarten werden gebraucht

Felddaten sagen:

Wir haben ein reales Problem.

Labordaten helfen bei der Frage:

Wo könnte es entstehen und lässt es sich reproduzieren?

Das ist eine sehr sinnvolle Arbeitsteilung.

Problematisch wird es, wenn man einen einmaligen Lighthouse-Test als absolute Wahrheit über sämtliche Besucher betrachtet.

Oder umgekehrt ausschließlich auf Felddaten schaut, aber keine geeignete Umgebung besitzt, um Probleme gezielt zu untersuchen.

Warum Lighthouse keinen normalen INP-Wert liefert

INP benötigt Benutzerinteraktionen.

Ein klassischer Lighthouse-Ladevorgang besitzt jedoch keinen echten Menschen, der irgendwann spontan ein Menü öffnet oder ein Formular bedient.

Deshalb kann Lighthouse INP in seinem normalen Seitenaudit nicht direkt auf dieselbe Weise messen. Google verwendet im Labor unter anderem Total Blocking Time, kurz TBT, als nützlichen Proxy für mögliche INP-Probleme; TBT ist aber ausdrücklich kein Ersatz für echte INP-Felddaten.

Das erklärt einen scheinbaren Widerspruch:

Eine Seite kann in Lighthouse einen sehr guten Performancewert besitzen und bei realen Benutzern trotzdem problematische Interaktionen haben, die im automatischen Lade-Test überhaupt nicht ausgeführt wurden.

Chrome DevTools kann Interaktionen gezielt untersuchen

Im Labor können reale Bedienabläufe bewusst reproduziert werden.

Man öffnet beispielsweise:

das mobile Menü,

einen Filter,

ein Formular,

einen Warenkorb

und beobachtet, was während dieser Aktionen passiert.

Google empfiehlt bei INP-Problemen ausdrücklich, mit Felddaten zu beginnen und anschließend problematische Interaktionen im Labor nachzustellen.

Das ist wesentlich aussagekräftiger als ausschließlich auf eine einzelne Gesamtpunktzahl zu schauen.

Was ist CrUX?

CrUX steht für Chrome User Experience Report.

Dabei handelt es sich um Googles Datensatz mit aggregierten realen Nutzererfahrungsdaten aus Chrome. Die Daten stehen über verschiedene Werkzeuge zur Verfügung, darunter PageSpeed Insights, Search Console und CrUX-spezifische Schnittstellen.

Für normale Website-Betreiber sind vor allem zwei Zugänge relevant:

PageSpeed Insights für einzelne URLs beziehungsweise Origins und Search Console für einen Überblick über Gruppen ähnlicher Seiten.

Warum gibt es manchmal keine Felddaten für eine URL?

Nicht jede Website und nicht jede einzelne Unterseite besitzt genug geeignete reale Nutzerdaten für eine aussagekräftige Veröffentlichung im CrUX-Datensatz.

Deshalb kann PageSpeed Insights für eine konkrete URL keine URL-Daten anzeigen, obwohl möglicherweise Daten für die gesamte Origin vorhanden sind. Auch beim INP kann zu wenig tatsächliche Interaktion dazu führen, dass keine aussagekräftigen Daten verfügbar sind.

Das bedeutet nicht automatisch, dass die Seite technisch fehlerhaft ist.

Sie besitzt möglicherweise einfach zu wenig messbare Nutzung.

Search Console gruppiert ähnliche URLs

Der Core-Web-Vitals-Bericht der Google Search Console zeigt nicht zwingend jeden einzelnen Seitenaufruf isoliert.

Google gruppiert URLs mit ähnlicher Nutzererfahrung. Die zugrunde liegenden Daten basieren ebenfalls auf CrUX und einem 28-Tage-Fenster.

Das ist bei großen WordPress-Websites praktisch.

Wenn beispielsweise hunderte Artikel dasselbe Template und dasselbe Performanceproblem besitzen, muss man nicht jeden Artikel einzeln behandeln.

Die gemeinsame technische Ursache liegt möglicherweise im Theme.

Der PageSpeed-Score ist nicht dasselbe wie Core Web Vitals

PageSpeed Insights beziehungsweise Lighthouse zeigt zusätzlich einen Performancewert von 0 bis 100.

Dieser Score ist nicht dasselbe wie das Bestehen der Core Web Vitals.

Lighthouse berechnet seinen Performance-Score aus mehreren gewichteten Labormetriken. Die Gewichtung und Bewertungsmodelle können sich mit Lighthouse-Versionen verändern. Ein perfekter Score von 100 ist laut Lighthouse-Dokumentation ausdrücklich weder leicht zu erreichen noch zwingend notwendig.

Daraus folgt eine wichtige Regel:

Nicht für die Zahl optimieren. Für das zugrunde liegende Problem optimieren.

100 Punkte sind kein sinnvolles Selbstziel

Angenommen, deine Website erreicht 96 Punkte.

Um auf 100 zu kommen, müsstest du eine nützliche Funktion entfernen oder mehrere Stunden Entwicklungsarbeit investieren.

Für echte Besucher verändert sich praktisch nichts.

Dann ist die Verbesserung möglicherweise wirtschaftlich unsinnig.

Google selbst weist darauf hin, dass perfekte Core-Web-Vitals- oder Tool-Ergebnisse nicht garantieren, ganz oben in den Suchergebnissen zu erscheinen, und dass das Streben nach einem perfekten Wert nur aus SEO-Gründen möglicherweise nicht der beste Einsatz der eigenen Zeit ist.

Sind Core Web Vitals ein Google-Rankingfaktor?

Google sagt, dass Core Web Vitals von seinen Ranking-Systemen verwendet werden. Gleichzeitig gibt es kein einzelnes umfassendes „Page Experience Signal“, das allein über Rankings entscheidet. Google betont außerdem, dass relevante Inhalte weiterhin auch dann gut ranken können, wenn ihre Page Experience nicht perfekt ist.

Das ist eine wichtige Einordnung.

Core Web Vitals sind kein Ersatz für Inhalt.

Ein Artikel wird nicht deshalb zum besten Suchergebnis, weil sein CLS 0,00 beträgt.

Zwei hervorragende Seiten können durch Nutzererfahrung unterscheidbar werden

Wenn mehrere Ergebnisse eine Suchanfrage sehr gut beantworten, kann eine bessere Nutzererfahrung einen zusätzlichen Vorteil darstellen.

Das entspricht auch Googles eigener Beschreibung: Relevanz bleibt entscheidend, gute Page Experience kann aber zum Erfolg beitragen, wenn viele hilfreiche Ergebnisse verfügbar sind.

Die vernünftige SEO-Strategie lautet deshalb nicht:

Erst Core Web Vitals, Inhalt später.

Sondern:

Hilfreiche Inhalte auf einer technisch guten Website.

Core Web Vitals sind vor allem ein Qualitätswerkzeug

Selbst wenn Google morgen sämtliche Rankingwirkungen der Metriken entfernen würde, blieben die zugrunde liegenden Probleme real.

Ein Button, der erst nach einer Sekunde reagiert, ist nervig.

Ein Artikel, der ständig springt, ist nervig.

Ein Titelbild, das ewig nicht erscheint, ist nervig.

Das eigentliche Argument für gute Core Web Vitals sind deshalb die Besucher.

SEO ist ein zusätzlicher Grund, nicht der einzige.

Wie gehe ich bei einem schlechten LCP vor?

Ein schlechter LCP sollte nicht mit zehn zufälligen Optimierungsmaßnahmen gleichzeitig beantwortet werden.

Zuerst wird das LCP-Element identifiziert.

Ist es ein Bild?

Ein Textblock?

Dann betrachtet man den Ablauf.

Wie schnell antwortet der Server?

Wann wird die LCP-Ressource entdeckt?

Wie lange lädt sie?

Was verhindert ihre Darstellung?

Google empfiehlt genau diese Zerlegung in TTFB, Ressourcen-Ladeverzögerung, eigentliche Ladezeit und Renderverzögerung.

Damit entsteht aus „LCP schlecht“ eine konkrete technische Aufgabe.

Wenn TTFB das Problem ist

Dann sollte die Serverseite untersucht werden.

Interessant sind beispielsweise:

Hosting,

Page Caching,

WordPress-Verarbeitung,

Datenbank,

externe Serveraufrufe.

Hier führen unsere Clusterseiten Was ist Webhosting?, Warum Websites langsam werden und Caching einfach erklärt weiter.

Wenn das LCP-Bild spät beginnt

Dann muss überprüft werden, warum der Browser es nicht früher entdeckt.

Vielleicht steckt es tief in einer Abhängigkeitskette.

Vielleicht wird es erst über CSS gefunden.

Vielleicht fügt JavaScript das Element ein.

Vielleicht wurde sogar das wichtigste Bild versehentlich mit Lazy Loading versehen.

Dann besteht das Problem nicht primär in der Bilddatei, sondern in ihrer Priorisierung.

Wenn der Download selbst lange dauert

Jetzt werden:

Dateigröße,

Bildabmessungen,

Format,

Netzwerk,

CDN

interessanter.

Genau dafür dient unser Artikel Bilder für Websites optimieren.

Man sollte nicht alle Ebenen gleichzeitig verdächtigen.

Man sollte diejenige bearbeiten, die tatsächlich Zeit verbraucht.

Wie gehe ich bei schlechtem INP vor?

Bei INP wird zuerst interessant, welche Interaktion langsam war.

Ein schlechter Gesamtwert allein sagt noch nicht:

welcher Button,

welcher Filter,

welches Formular,

welcher Zeitpunkt.

Gutes Real User Monitoring kann deutlich mehr Kontext liefern als ein reiner CrUX-Aggregatwert. Google empfiehlt für die INP-Optimierung Felddaten mit Informationen über die konkrete langsame Interaktion und anschließend eine Reproduktion im Labor.

Danach lässt sich analysieren, ob die Verzögerung vor dem Event-Handler, während der JavaScript-Verarbeitung oder vor der visuellen Aktualisierung entsteht.

Lange Main-Thread-Aufgaben sind verdächtig

Wenn JavaScript den Main Thread mehrere hundert Millisekunden am Stück blockiert, kann der Browser Eingaben nicht rechtzeitig verarbeiten.

Eine typische Optimierungsstrategie besteht deshalb darin, große Aufgaben aufzuteilen, unnötige Arbeit zu entfernen und DOM- beziehungsweise Rendering-Aufwand zu reduzieren.

Auch hier gilt:

Nicht „JavaScript minimieren“ als Ritual.

Sondern herausfinden, welcher Code bei welcher Interaktion tatsächlich blockiert.

Wie gehe ich bei schlechtem CLS vor?

CLS ist häufig visuell gut nachvollziehbar.

Man beobachtet die Seite und sucht nach Elementen, die beim Laden ihre Position verändern.

Besonders verdächtig sind:

Bilder ohne reservierte Dimensionen,

Werbeflächen,

Embeds,

später eingefügte Inhalte,

Webfonts.

Diese Ursachen gehören laut Googles CLS-Leitfaden zu den häufigsten Problemquellen.

Im Idealfall wird der Platz für nachladende Elemente bereits vorher festgelegt.

Der Besucher sieht dann vielleicht noch nicht sofort den Inhalt – aber die restliche Seite bleibt dort, wo sie hingehört.

Mobile und Desktop sollten getrennt betrachtet werden

Eine Website kann am Desktop problemlos gute Werte erreichen und mobil Schwierigkeiten haben.

Das ist nicht überraschend.

Smartphones können besitzen:

langsamere Prozessoren,

weniger Arbeitsspeicher,

schlechtere Netzwerkbedingungen.

Insbesondere JavaScript-Verarbeitung kann auf schwächerer Hardware deutlich stärker auffallen.

Google empfiehlt deshalb die Betrachtung des 75. Perzentils getrennt nach Gerätetypen.

Ein ausgezeichnetes Desktop-Ergebnis repariert also keinen schlechten mobilen INP.

Änderungen brauchen bei Felddaten Geduld

Du optimierst heute ein Titelbild.

Morgen zeigt die Search Console noch denselben schlechten Zustand.

Das bedeutet nicht, dass die Änderung nichts gebracht hat.

CrUX-Daten werden über Zeiträume aggregiert. PageSpeed Insights verwendet für seine Felddaten ein rollierendes 28-Tage-Fenster, und auch die Search Console arbeitet mit aggregierten CrUX-Daten statt ausschließlich mit dem heutigen Seitenzustand.

Labortests können eine technische Verbesserung deshalb viel schneller sichtbar machen.

Felddaten bestätigen anschließend mit Verzögerung, ob die Verbesserung auch bei realen Nutzern ankommt.

Deshalb brauchen wir einen zweistufigen Workflow

Für Casiopeya lässt sich eine vernünftige Performanceanalyse auf ein einfaches Prinzip reduzieren:

Felddaten
↓
Problem erkennen
↓
betroffene Seitentypen identifizieren
↓
im Labor reproduzieren
↓
technische Ursache finden
↓
gezielt ändern
↓
Labortest wiederholen
↓
später Felddaten kontrollieren

Das verhindert zwei typische Fehler.

Erstens optimieren wir nicht auf Verdacht.

Zweitens beurteilen wir eine Änderung nicht ausschließlich anhand eines einzigen synthetischen Tests.

Core Web Vitals sollten nach Seitentyp betrachtet werden

Eine Website besteht oft aus sehr unterschiedlichen Templates.

Bei WordPress beispielsweise:

Startseite,

Wissensartikel,

Kategorie,

Suchseite,

Kontaktformular,

Shopprodukt.

Ein Performanceproblem kann ausschließlich auf einem dieser Seitentypen auftreten.

Wenn das Hero-Bild der Startseite schlecht priorisiert ist, muss deshalb nicht automatisch der gesamte Wissensbereich umgebaut werden.

Wenn ein Plugin hingegen auf jeder Seite blockierendes JavaScript einbindet, kann das Problem systemweit sein.

Diese Unterscheidung spart enorm viel Optimierungsarbeit.

Die größte Verbesserung ist nicht immer der schlechteste Ampelwert

Angenommen:

LCP beträgt 2,7 Sekunden.

CLS beträgt 0,11.

INP beträgt 700 Millisekunden.

Alle drei Werte benötigen Aufmerksamkeit.

Aber der INP deutet hier auf ein wesentlich massiveres Nutzungserlebnis hin.

Optimierungsarbeit sollte deshalb nicht einfach der Reihenfolge der PageSpeed-Anzeige folgen.

Interessanter ist:

Wo ist die größte reale Beeinträchtigung?

Wie viele Besucher betrifft sie?

Wie aufwendig ist die Korrektur?

Performance ist auch Priorisierung.

Nicht jedes Hundertstel braucht eine Optimierung

Wenn CLS bei 0,03 liegt, lohnt es sich normalerweise nicht, Tage damit zu verbringen, 0,00 zu erreichen.

Wenn LCP bei 1,8 Sekunden liegt, ist 1,6 natürlich noch besser.

Vielleicht gibt es aber gleichzeitig ein Formular, dessen Klick erst nach 800 Millisekunden reagiert.

Dann ist klar, wo die Arbeit mehr Nutzen erzeugt.

Grenzwerte sollen Probleme sichtbar machen.

Sie sind keine Aufforderung, jeder Zahl bis zur theoretischen Perfektion hinterherzulaufen.

Performance und Design müssen zusammenarbeiten

Ein großes Titelbild kann für die Marke wichtig sein.

Dann wird es nicht einfach entfernt, nur weil LCP existiert.

Stattdessen wird es:

passend dimensioniert,

komprimiert,

früh entdeckt

und sinnvoll priorisiert.

Eine Webfont kann Teil des Designs sein.

Dann wird geprüft, wie sie effizient geladen werden kann, ohne unnötige Layoutverschiebungen zu erzeugen.

Performanceoptimierung ist kein Krieg gegen Design.

Sie zwingt uns lediglich, die technischen Kosten von Designentscheidungen sichtbar zu machen.

Performance und Funktion müssen ebenfalls zusammenarbeiten

Ein Shop benötigt JavaScript.

Ein Filter benötigt Interaktion.

Ein Mitgliederbereich benötigt dynamische Inhalte.

Die beste Core-Web-Vitals-Seite wäre nicht die Seite, auf der sämtliche Funktionen entfernt wurden.

Sie wäre möglicherweise nur nutzlos.

Deshalb lautet die richtige Frage:

Wie liefern wir die benötigte Funktion mit möglichst wenig unnötiger Wartezeit und Instabilität?

Das ist eine wesentlich bessere Perspektive als die Jagd auf einen PageSpeed-Wert von 100.

Was du dir über Core Web Vitals merken solltest

Core Web Vitals versuchen drei unterschiedliche Aspekte echter Website-Nutzung messbar zu machen.

LCP beantwortet im Kern die Frage:

Wann erscheint ein wesentlicher großer Inhalt?

INP beantwortet:

Wie schnell reagiert die Seite, wenn ich etwas tue?

CLS beantwortet:

Bleibt die Oberfläche während der Nutzung stabil?

Aktuell gelten ein LCP von höchstens 2,5 Sekunden, ein INP von höchstens 200 Millisekunden und ein CLS von höchstens 0,1 als gute Zielwerte am 75. Perzentil.

Noch wichtiger ist aber:

Core Web Vitals sind Diagnosewerkzeuge, keine drei SEO-Punkte, die man abhaken muss.

Ein schlechter Wert ist der Beginn der Untersuchung.

Nicht die Diagnose selbst.