Core Web Vitals und User Experience: was Tempo, Reaktion und Stabilität für dein Geschäft bedeuten

Drei Zahlen dafür, wie sich eine Seite anfühlt

Jeder Besucher stellt einer Seite drei stille Fragen. Ist das, weswegen ich gekommen bin, schon da? Wenn ich auf etwas tippe, passiert dann auch etwas? Bleibt die Seite lange genug ruhig, damit ich sie lesen kann?

Googles Core Web Vitals geben jeder dieser Fragen eine Zahl. Largest Contentful Paint (LCP) misst das Laden: wie lange es dauert, bis der Hauptinhalt sichtbar ist. Interaction to Next Paint (INP) misst die Reaktion: wie schnell die Seite antwortet, wenn jemand klickt, tippt oder etwas eingibt. Cumulative Layout Shift (CLS) misst die Stabilität: wie stark der Inhalt herumspringt, während jemand die Seite benutzt.¹

Für jede Kennzahl gibt es einen Grenzwert für "gut". LCP sollte bei 2,5 Sekunden oder darunter liegen, INP bei 200 Millisekunden oder darunter und CLS bei 0,1 oder darunter. Google bewertet jede Kennzahl beim 75. Perzentil echter Seitenaufrufe, getrennt nach Smartphone und Desktop.¹ Dieser letzte Satz wiegt schwerer als die Grenzwerte selbst, deshalb bekommt er weiter unten einen eigenen Abschnitt.

Die Auswahl ist nicht in Stein gemeißelt. Google schickt die Kennzahlen durch einen Lebenszyklus (experimentell, ausstehend, stabil), und auch eine stabile Kennzahl kann wieder in Rente gehen.¹ Genau das ist 2024 passiert, als INP den First Input Delay abgelöst hat. Wenn ein Artikel, ein Audit oder ein Agenturbericht First Input Delay noch als Core Web Vital aufführt, ist er veraltet.

Rechenbeispiel: der Shop in diesem Artikel

Ehrenfelder Eiche ist ein erfundener Onlineshop für Möbel aus Köln. Hanna führt ihn. Sie verkauft Esstische, Sideboards und Sofas aus massiver Eiche, eine typische Bestellung liegt bei etwa 780 €, die Seite läuft unter ehrenfeldereiche.example. Die meisten Besucher kommen über das Smartphone.

Hannas Beschwerde ist die, die ich am häufigsten höre: "Auf meinem Handy fühlt sich die Seite zäh an, aber die Agentur sagt, die Werte passen." Jeder Abschnitt unten nimmt ihre Zahlen, findet, was nicht stimmt, und behebt es. Der Shop und alle Zahlen sind erfunden.

Largest Contentful Paint: wann das Wichtigste erscheint

LCP ist die Zeit vom Beginn des Ladens bis zu dem Moment, in dem das größte sichtbare Bild, der größte Textblock oder das größte Video im ersten Bildschirm fertig dargestellt ist.² Auf einer Produktseite ist das meist das große Produktfoto oben. In einem Artikel ist es oft die Überschrift oder der erste Absatz.

Die Grenzwerte: bis 2,5 Sekunden ist gut, über 4,0 Sekunden ist schlecht, alles dazwischen gilt als verbesserungswürdig.²

Für sich allein sagt LCP nur, dass die Seite langsam war, nicht warum. Googles Anleitung zur Optimierung zerlegt LCP in vier Teile, die zusammen den ganzen Wert ergeben:³

1. Time to First Byte: wie lange der Server braucht, bis er anfängt, die Seite zu schicken.
2. Ladeverzögerung der Ressource: die Lücke zwischen diesem ersten Byte und dem Moment, in dem der Browser das LCP Bild anfordert (null, wenn das größte Element reiner Text ist).
3. Ladedauer der Ressource: wie lange der Download des Bildes selbst dauert.
4. Renderverzögerung des Elements: die Zeit zwischen dem Eintreffen des Bildes und dem Moment, in dem es tatsächlich erscheint.

Als Formel:

$$\text{LCP} = t_{\text{TTFB}} + t_{\text{delay}} + t_{\text{load}} + t_{\text{render}}$$

Dabei ist $t_{\text{TTFB}}$ die Time to First Byte, $t_{\text{delay}}$ die Ladeverzögerung der Ressource, $t_{\text{load}}$ die Ladedauer der Ressource und $t_{\text{render}}$ die Renderverzögerung des Elements, alle in Sekunden. Um zu sehen, wo die Zeit hingeht, teilst du jeden Teil durch $\text{LCP}$ und nimmst ihn mal 100. Das ergibt seinen Anteil in Prozent. Grundlagen: Prozent.

Die Anleitung nennt eine grobe Richtung für eine Seite in gutem Zustand: etwa 40 % des LCP für die Time to First Byte, etwa 40 % für den Download und jeweils unter 10 % für die beiden Verzögerungen. Die zwei Teile mit "Verzögerung" im Namen sollten also nahe null liegen. Die Anleitung sagt klar, dass das Richtwerte sind und die Aufteilung kaum eine Rolle spielt, solange LCP zuverlässig unter 2,5 Sekunden bleibt.³

Rechenbeispiel: die Seite des Eichentischs

Auf der Produktseite des meistverkauften Esstischs von Ehrenfelder Eiche ist das LCP Element das große Foto des Tischs. Auf dem Smartphone liegt LCP beim 75. Perzentil bei 4,6 Sekunden. Das ist schlecht.

Gemessen in den Entwicklertools des Browsers mit gedrosseltem Smartphoneprofil, verteilen sich die vier Teile so:

Teil	Zeit	Anteil am LCP
Time to First Byte	0,9 s	19,6 %
Ladeverzögerung der Ressource	1,1 s	23,9 %
Ladedauer der Ressource	2,1 s	45,7 %
Renderverzögerung des Elements	0,5 s	10,9 %
Summe	4,6 s	100 %

Der erste Anteil, ausgerechnet: $0{,}9 \div 4{,}6 = 0{,}196$, also 19,6 %. Die anderen gehen genauso.

Zwei Dinge fallen auf. Die Ladeverzögerung liegt bei 23,9 %, weit über den groben 10 %. Der Grund: Das Foto steckt in einem Karussellskript, der Browser entdeckt das Bild also erst, nachdem das Skript gelaufen ist. Und der Download selbst dauert 2,1 Sekunden, weil das Foto eine Datei mit 2,4 MB ist, gemacht für einen großen Monitor und an ein Handy geschickt.

Interaction to Next Paint: wann die Seite antwortet

INP misst, wie schnell eine Seite während des ganzen Besuchs auf Klicks, Tippen und Tastendrücke reagiert. Mit der Maus über etwas fahren und Scrollen zählen nicht. Der gemeldete Wert ist grob gesagt die langsamste Interaktion des Besuchs, wobei pro 50 Interaktionen ein Ausreißer ignoriert wird, damit ein einzelner Hänger auf einer viel genutzten Seite nicht alles bestimmt.⁴

Die Grenzwerte: bis 200 Millisekunden ist gut, über 500 Millisekunden ist schlecht.⁴

INP ist am 12. März 2024 ein Core Web Vital geworden und hat an diesem Tag den First Input Delay (FID) ersetzt.⁵ Der Grund lohnt sich, denn er erklärt, warum manche Seiten, die vorher gut aussahen, plötzlich nicht mehr gut aussahen. FID hat nur die Eingabeverzögerung der ersten Interaktion auf einer Seite gemessen. INP beobachtet alle, von der Eingabeverzögerung über die Zeit, die der Code zum Ausführen braucht, bis zu dem Moment, in dem der Browser das nächste Bild zeichnet.⁴ Laut Chromes Nutzungsdaten verbringen Menschen 90 % ihrer Zeit auf einer Seite, nachdem sie geladen ist.⁴ Eine Kennzahl, die nur auf das erste Tippen geschaut hat, hat den Großteil des Besuchs verpasst.

Jede Interaktion hat drei Phasen:⁴

1. Eingabeverzögerung: die Zeit, bevor die Seite überhaupt anfangen kann, das Tippen zu verarbeiten, meist weil der Browser gerade mit einem anderen Skript beschäftigt ist.
2. Verarbeitungsdauer: die Zeit, die der eigene Code der Seite für die Verarbeitung braucht.
3. Darstellungsverzögerung: die Zeit vom Ende dieses Codes bis zu dem Moment, in dem sich der Bildschirm wirklich ändert.

$$\text{INP}_{\text{interaction}} = t_{\text{input}} + t_{\text{processing}} + t_{\text{presentation}}$$

Dabei ist $\text{INP}_{\text{interaction}}$ die Latenz einer einzelnen Interaktion, $t_{\text{input}}$ die Eingabeverzögerung, $t_{\text{processing}}$ die Verarbeitungsdauer und $t_{\text{presentation}}$ die Darstellungsverzögerung, alle in Millisekunden. Dieselbe Anteilsrechnung wie beim LCP zeigt dir, welche Phase du angehen solltest. Grundlagen: Prozent.

Googles Anleitung zur Optimierung von INP zeigt zuerst auf lange Aufgaben im Hauptthread. Das ist die eine Spur, auf der der Browser Skripte ausführt, das Layout berechnet und den Bildschirm zeichnet. Solange dort ein langes Skript läuft, muss ein Tippen warten.⁶

Rechenbeispiel: einen Bezugsstoff wählen

Bei Ehrenfelder Eiche ist die langsamste häufige Interaktion das Tippen auf ein Stoffmuster auf einer Sofaseite. Die Seite tauscht daraufhin Foto und Preis. Beim 75. Perzentil auf dem Smartphone liegt INP bei 380 Millisekunden, das ist verbesserungswürdig.

In den Entwicklertools gemessen, setzt sich ein typisches langsames Tippen so zusammen:

$$210 + 120 + 50 = 380 \text{ ms}$$

Dabei ist $t_{\text{input}} = 210$, $t_{\text{processing}} = 120$ und $t_{\text{presentation}} = 50$, alle in Millisekunden. Die Eingabeverzögerung macht 55 % der Summe aus ($210 \div 380 = 0{,}553$). Die Seite ist also nicht langsam darin, das Tippen zu verarbeiten. Sie ist mit etwas anderem beschäftigt, wenn das Tippen ankommt. Hier sind es ein Bewertungswidget und ein Chatwidget, die beide große Skripte starten, sobald der Besucher anfängt zu scrollen und zu tippen.

Cumulative Layout Shift: wann die Seite stillhält

CLS misst, wie stark sichtbarer Inhalt sich unerwartet verschiebt, während die Seite benutzt wird.⁷ Googles eigene Erklärung nennt die Kosten deutlich: Eine plötzliche Verschiebung kann dazu führen, dass jemand das Falsche antippt, und als Beispiel dient jemand, der eine große Bestellung bestätigt, die er eigentlich stornieren wollte.⁷ In einem Möbelshop mit Bestellungen um 780 € ist das keine abstrakte Sorge.

Jede unerwartete Bewegung bekommt einen Wert für die Layoutverschiebung:

$$s = f_{\text{impact}} \times f_{\text{distance}}$$

Dabei ist $s$ der Wert einer einzelnen Verschiebung. $f_{\text{impact}}$ ist der Auswirkungsanteil: der Teil des Bildschirms, den das bewegte Element vor und nach der Bewegung zusammen bedeckt. $f_{\text{distance}}$ ist der Distanzanteil: wie weit sich das Element bewegt hat, gemessen an der längsten Seite des Bildschirms. Beide sind Verhältnisse zwischen 0 und 1. Grundlagen: Verhältnisse und Raten.

Verschiebungen werden zu Schüben gebündelt, den sogenannten Sitzungsfenstern: Verschiebungen mit weniger als einer Sekunde Abstand, in einem Fenster von höchstens fünf Sekunden. CLS ist die Summe des schlimmsten Fensters. Verschiebungen innerhalb einer halben Sekunde nach einem Tippen, Klick oder Tastendruck gelten als erwartet und zählen nicht, denn die hat der Besucher selbst ausgelöst.⁷

Die Grenzwerte: bis 0,1 ist gut, über 0,25 ist schlecht.⁷ Die häufigsten Ursachen laut Googles Anleitung sind Bilder ohne Größenangaben, Werbung, eingebettete Inhalte und iframes ohne Größenangaben, Inhalte, die nach dem Laden eingefügt werden, und Webfonts.⁸

Rechenbeispiel: das Banner zur Ratenzahlung

Auf der Produktseite von Ehrenfelder Eiche lädt ein Banner "in Raten zahlen" spät über das Skript eines Drittanbieters und schiebt Preis, Foto und Button nach unten.

Der bewegte Block bedeckt über das Bild vorher und nachher hinweg 60 % des Handybildschirms, also $f_{\text{impact}} = 0{,}60$. Er rutscht um ein Viertel der Bildschirmhöhe nach unten, also $f_{\text{distance}} = 0{,}25$.

$$s_1 = 0{,}60 \times 0{,}25 = 0{,}15$$

Dabei ist $s_1$ der Wert der ersten Verschiebung, $0{,}60$ ihr Auswirkungsanteil und $0{,}25$ ihr Distanzanteil.

Keine Sekunde später lädt die Sternebewertung über dem Button und schubst den Block noch einmal: Auswirkung 0,35, Distanz 0,20.

$$s_2 = 0{,}35 \times 0{,}20 = 0{,}07$$

Dabei ist $s_2$ der Wert der zweiten Verschiebung.

Beide liegen im selben Sitzungsfenster, das Fenster kommt also auf $0{,}15 + 0{,}07 = 0{,}22$. Beim 75. Perzentil auf dem Smartphone liegt der CLS der Seite bei 0,22. Das ist verbesserungswürdig und schon nah an schlecht. Niemand hat irgendetwas angetippt. Die Seite hat sich von allein bewegt.

Warum das 75. Perzentil und nicht der Durchschnitt

Google bewertet eine Seite nicht nach ihrem durchschnittlichen Ladevorgang. Google nimmt alle echten Seitenaufrufe, sortiert sie und liest den Wert ab, der drei Viertel des Weges nach oben liegt. Das ist das 75. Perzentil, oft p75 geschrieben.¹

Ein Perzentil ist eine Position in einer sortierten Liste. Der Median ist das 50. Perzentil, der mittlere Wert. Das 75. Perzentil ist der Wert, bei dem oder unter dem drei Viertel der Aufrufe liegen. Eine einfache Art, es zu finden, ist die Methode des nächsten Rangs:

$$k = \lceil 0{,}75 \times n \rceil$$

Dabei ist $n$ die Zahl der Seitenaufrufe, $k$ der Rang des p75 Werts, wenn die Aufrufe vom schnellsten zum langsamsten sortiert sind, und $\lceil \, \rceil$ bedeutet: auf die nächste ganze Zahl aufrunden. Grundlagen: Verteilungen und Grundlagen: Median und Modus.

Warum gerade p75? Googles Forschungsarbeit zu den Grenzwerten setzt zwei Ziele, die gegeneinander ziehen. Der Wert soll zeigen, dass die meisten Besuche das Ziel erreicht haben, und er soll sich nicht von ein paar extremen Ausreißern herumwerfen lassen. Die Autoren kamen zu dem Schluss, dass das 75. Perzentil einen vernünftigen Ausgleich schafft: Wenn es den Grenzwert erfüllt, waren drei von vier Besuchen mindestens so gut.⁹

Der Durchschnitt scheitert an beidem. Ladezeiten sind schief verteilt. Die meisten liegen eng beieinander, und ein langer Schwanz aus langsamen Handys mit schwachem Empfang zieht den Mittelwert nach oben. Dann zieht ein einziger Besuch vom Bürolaptop mit vollem Cache ihn wieder nach unten. Ein Mittelwert kann gut aussehen, während ein Viertel deiner Besucher wartet.

Eine verwandte Zahl ist der Anteil der Aufrufe, die "gut" erreicht haben:

$$\text{Anteil gut} = \frac{n_{\text{gut}}}{n}$$

Dabei ist $n_{\text{gut}}$ die Zahl der Seitenaufrufe beim oder unter dem Grenzwert für gut und $n$ die Gesamtzahl der Aufrufe. Grundlagen: Verhältnisse und Raten. Eine Seite besteht eine Kennzahl, wenn dieser Anteil mindestens 75 % beträgt. Das ist dieselbe Aussage wie "p75 liegt innerhalb des Grenzwerts".

Rechenbeispiel: 20 Seitenaufrufe

Hanna exportiert 20 echte Aufrufe der Esstischseite vom Smartphone, mit ihrem LCP in Sekunden, schon sortiert:

1,4, 1,6, 1,7, 1,9, 2,0, 2,1, 2,2, 2,3, 2,4, 2,6, 2,8, 3,0, 3,1, 3,3, 3,6, 3,9, 4,2, 4,8, 5,5, 7,1

Schritt eins, der Rang: $k = \lceil 0{,}75 \times 20 \rceil = \lceil 15 \rceil = 15$.

Schritt zwei, den 15. Wert ablesen: 3,6 Sekunden. Das ist das p75, und es ist verbesserungswürdig.

Schritt drei, zum Vergleich der Median: Bei 20 Werten liegt er zwischen dem 10. und dem 11., also $(2{,}6 + 2{,}8) \div 2 = 2{,}7$ Sekunden.

Schritt vier, der Anteil gut: Neun Aufrufe liegen bei oder unter 2,5 Sekunden, also $9 \div 20 = 0{,}45$, das sind 45 %. Weit entfernt von 75 %.

Schritt fünf, der schnellste Aufruf: 1,4 Sekunden. Ungefähr das sieht Hanna auf ihrem eigenen Handy im WLAN im Laden, und deshalb "fühlt sich die Seite gut an". Bewertet wird die Seite aber nicht auf ihrem Handy.

Felddaten und Labordaten sind verschiedene Werkzeuge

Es gibt zwei Arten, all das zu messen, und wer sie verwechselt, hat den Großteil der Streitereien schon ausgelöst.

Labordaten entstehen, wenn die Seite unter kontrollierten Bedingungen geladen wird: ein Gerät, ein Netz, ein Standort. Lighthouse, das Werkzeug hinter den meisten "Performance Scores", liefert Labordaten. Felddaten kommen von echten Besuchern auf ihren eigenen Geräten und Verbindungen.¹⁰

Googles wichtigste Quelle für Felddaten ist der Chrome User Experience Report (CrUX): Daten dazu, wie echte Chrome Nutzer beliebte Websites erleben.¹¹ Nicht jeder Chrome Nutzer zählt. Die Berichte zu Nutzungsstatistiken müssen aktiviert sein, der Browserverlauf muss synchronisiert werden, und es darf keine Passphrase für die Synchronisierung gesetzt sein, auf Chrome für den Desktop oder Chrome unter Android. Chrome auf dem iPhone liefert keine Daten. Eine Seite oder eine Website braucht genug Besucher, um aufgenommen zu werden, und die genaue Zahl veröffentlicht Google nicht.¹² Die Werte sind ein gleitender Durchschnitt über die letzten 28 Tage.¹³

Labor und Feld weichen aus guten Gründen voneinander ab. Das Labor nutzt ein Gerät und ein Netz, deine Besucher Hunderte. Das Labor startet meist mit leerem Cache. Und das Labor scrollt nicht, markiert keinen Text und tippt nirgends drauf, es kann also nicht sehen, was während eines echten Besuchs passiert. INP lässt sich im Labor überhaupt nicht messen, weil ein Labortest nicht vorhersagen kann, wann ein Mensch mit der Seite interagiert. Lighthouse zeigt stattdessen die Total Blocking Time als Ersatz, und eine Seite kann eine gute Total Blocking Time und trotzdem einen schlechten INP haben.¹⁰

Googles Empfehlung lautet, Felddaten Vorrang zu geben, weil sie zeigen, was Menschen wirklich erleben, und Labordaten zu nutzen, um die Ursache zu finden.¹⁰ Genau so arbeite ich damit: Das Feld sagt mir, wo es wehtut, das Labor sagt mir, warum.

Ist eine Website zu klein für CrUX, kann sie ihre eigenen Felddaten sammeln, indem sie die drei Kennzahlen aus echten Besuchen als Analytics Event verschickt. Auf Websites, die ich baue, wird dieses Event erst gesendet, wenn der Besucher der Analyse zugestimmt hat, wie alles andere, was ich messe.

Rechenbeispiel: der Score, der "passt" sagte

Hannas Agentur lässt Lighthouse auf einem Desktoprechner laufen und meldet einen Performance Score in den 90ern und einen LCP von 1,8 Sekunden. CrUX sagt für dieselbe Seite auf dem Smartphone: LCP 4,6 Sekunden beim p75, INP 380 Millisekunden und CLS 0,22.

Beides stimmt. Der Labortest lief auf einem schnellen Rechner am Kabel, hat nie auf ein Stoffmuster getippt und nie auf das Banner zur Ratenzahlung gewartet, das erst lädt, wenn jemand scrollt. Die Felddaten beschreiben ihre Kundschaft. Der Lighthouse Score beschreibt den Rechner der Agentur.

Wie viel die drei Zahlen in der Suche wiegen

An dieser Stelle hat die alte Fassung dieses Artikels übertrieben. Deshalb bin ich hier genau und lasse Google selbst sprechen.

Google schreibt: "Core Web Vitals werden von unseren Rankingsystemen genutzt." Und empfiehlt Websiteinhabern, gute Werte anzustreben, "um in der Google Suche erfolgreich zu sein und allgemein eine hohe Nutzerfreundlichkeit zu bieten".¹⁴ Sie zählen also.

Genauso deutlich ist Google bei den Grenzen. Gute Ergebnisse in Berichten wie dem Bericht zu den Core Web Vitals in der Search Console garantieren laut Google nicht, dass deine Seiten ganz oben in den Suchergebnissen stehen. Und zum Jagen nach der perfekten Zahl heißt es: "Wahrscheinlich hast du Wichtigeres zu tun, als nur der SEO wegen einen perfekten Wert anzustreben."¹⁴

Der nützlichste Satz der ganzen Seite ist dieser: "Die Google Suche versucht immer, die relevantesten Inhalte anzuzeigen", auch wenn die Nutzerfreundlichkeit einer Seite in mancher Hinsicht schwach ist. Gibt es aber für eine Suchanfrage viele ähnlich hilfreiche Inhalte, dann "kann in solchen Fällen" eine hohe Nutzerfreundlichkeit "zum Erfolg in der Google Suche beitragen".¹⁴

Die Nutzerfreundlichkeit einer Seite ist also ein Signal unter vielen, und guter Inhalt gewinnt trotzdem. Tempo entscheidet bei Gleichstand. Eine Seite, die niemand braucht, rettet es nicht. Ich bringe die Core Web Vitals für die Menschen in Ordnung, die auf der Seite landen, und nehme jede Hilfe beim Ranking als Zugabe mit.

Rechenbeispiel: der Ratgeber zur Tischgröße

Hanna hat einen wirklich nützlichen Ratgeber dazu, welche Größe ein Esstisch haben sollte, mit einer Maßtabelle. Ein großer Händler hat zur selben Suchanfrage eine dünne Seite, die in unter zwei Sekunden lädt. Hannas Ratgeber kann vor ihr ranken, obwohl ihr LCP noch schlecht ist, weil er die Frage besser beantwortet. Wichtig wird das Tempo gegenüber den drei anderen Shops, deren Ratgeber ungefähr so gut sind wie ihrer. Dort kann es den Ausschlag geben.

Was Tempo mit dem Umsatz macht, und was niemand ehrlich versprechen kann

Die alte Fassung dieses Artikels hat behauptet, schnellere Seiten konvertieren besser, ohne irgendeinen Beleg. Hier ist eine Zahl mit einem Test dahinter, samt ihren Grenzen.

Vodafone hat auf einer Landingpage einen A/B Test gemacht und bezahlten Traffic 50/50 auf die bestehende Version und eine für die Web Vitals optimierte Version aufgeteilt. Die optimierte Version hat das Rendern eines Widgets auf den Server verlegt, das wichtige HTML auf dem Server gerendert und ihre Bilder verkleinert und komprimiert. Nach Vodafones eigenem Ergebnis verbesserte sich der LCP im Feld um 31 %, und die optimierte Seite brachte 8 % mehr Verkäufe, ein um 15 % besseres Verhältnis von Leads zu Besuchen und ein um 11 % besseres Verhältnis von Warenkörben zu Besuchen.¹⁵

Das ist ein richtiger Test mit Kontrollgruppe, und so etwas ist selten. Es ist aber auch eine Firma, eine Landingpage, bezahlter Traffic, im Jahr 2021. Es zeigt, dass der Effekt echt sein kann, nicht, was dein Shop sehen wird.

Diese Zahlen sind prozentuale Veränderungen, keine Prozentpunkte:

$$\Delta\% = \frac{v_{\text{new}} - v_{\text{old}}}{v_{\text{old}}} \times 100$$

Dabei ist $\Delta\%$ die prozentuale Veränderung, $v_{\text{old}}$ der Wert vorher und $v_{\text{new}}$ der Wert nachher. Ein negatives Ergebnis bei einer Zeit heißt, dass es schneller geworden ist. Grundlagen: Prozent.

In den Shops, an denen ich gearbeitet habe, war der Effekt in der Richtung beständig und in der Größe unbeständig, von deutlich sichtbar bis im Rauschen verschwunden. Das sage ich Kunden so, statt ihnen eine Zahl zu nennen. Wer dir vor jeder Messung deines Traffics ein Umsatzplus aus einem Tempoprojekt verspricht, verkauft und misst nicht.

Tempo ist außerdem nur eine Quelle von Reibung. Eine Seite kann in einer Sekunde laden und Leute trotzdem an eine schwammige Überschrift oder ein Formular verlieren, das zu viel will. Diese Seite der Sache, Text, Ablauf und Formulare, behandle ich im Clarity Framework, mit dem ich Reibung aus der Conversion nehme, und wiederhole sie hier nicht.

Rechenbeispiel: was Hanna sagen darf und was nicht

Wenn Hannas LCP von 4,6 auf 2,2 Sekunden sinkt:

$$\Delta\% = \frac{2{,}2 - 4{,}6}{4{,}6} \times 100 = \frac{-2{,}4}{4{,}6} \times 100 = -52{,}2\%$$

Dabei ist $v_{\text{old}} = 4{,}6$ und $v_{\text{new}} = 2{,}2$ Sekunden, also $\Delta\% = -52{,}2\%$.

Der LCP ist um 52,2 % schneller. Was sie nicht rechnen darf: "Vodafone hatte bei 31 % mehr Tempo 8 % mehr Verkäufe, also bekomme ich ungefähr 13 %." Deren Test lief mit einem anderen Geschäft, anderem Traffic und anderen Seiten. Ihre eigene Zahl erfährt sie nur, wenn sie ihre eigenen Verkäufe misst, am besten mit einem Test, und wenn ihr Traffic für einen Test zu klein ist, mit einem ehrlichen Vorher Nachher Vergleich, den sie mit Vorsicht liest.

Eine langsame Seite diagnostizieren, von oben nach unten

Mein Vorgehen ist absichtlich langweilig. Jeder Schritt grenzt das Problem weiter ein, bevor irgendjemand Code anfasst.

Der Ablauf liest sich von oben. Die erste Entscheidung betrifft nur die Frage, woher die Zahlen kommen. Der hervorgehobene Schritt ist der wichtigste: an der Kennzahl arbeiten, die am weitesten von gut entfernt ist, eine Ursache nach der anderen. Den letzten Schritt lassen die meisten aus. Weil CrUX ein gleitender Durchschnitt über 28 Tage ist,¹³ zeigt sich eine Verbesserung, die heute live geht, dort erst nach vier Wochen vollständig. Deine eigenen Events mit Einwilligung zeigen sie früher.

Rechenbeispiel: Hannas drei Verbesserungen

Die Schritte, angewendet auf die Seiten von Esstisch und Sofa:

1. Für die Produktseiten gibt es Felddaten. Auf dem Smartphone beim p75: LCP 4,6 s, INP 380 ms, CLS 0,22. Alle drei liegen außerhalb von gut.
2. Gemessen am jeweiligen Grenzwert liegt CLS am weitesten daneben (0,22 statt 0,1), dann INP, dann LCP. Hanna fängt mit CLS an, auch weil diese Verbesserung am wenigsten Gefahr läuft, etwas kaputt zu machen.
3. CLS: Das Banner zur Ratenzahlung und die Sternebewertung bekommen ihren Platz im Layout reserviert, bevor sie laden. Darunter bewegt sich nichts mehr.
4. INP: Das Bewertungswidget und das Chatwidget laden jetzt erst, wenn ein Besucher zu den Bewertungen scrollt oder auf den Chatbutton tippt. Der Hauptthread ist frei, wenn jemand auf ein Stoffmuster tippt.
5. LCP: Das große Produktfoto kommt aus dem Karussellskript heraus, steht direkt im HTML der Seite und ist als hohe Priorität markiert. Es wird in der Größe des Bildschirms ausgeliefert, der es anfordert, auf dem Handy etwa 200 KB statt 2,4 MB.
6. Sie liefert jede Verbesserung in einem eigenen Release aus, prüft sie im Labor und wartet dann.

Der Kölner Shop, vorher und nachher

28 Tage nach der letzten Verbesserung zeigen die CrUX Werte für die Produktseiten auf dem Smartphone beim p75: LCP 2,2 Sekunden, INP 170 Millisekunden, CLS 0,05. Alle drei sind gut.

Die drei Kennzahlen haben verschiedene Einheiten, Sekunden, Millisekunden und einen Wert ohne Einheit, sie passen so also nicht auf eine gemeinsame Achse. Um sie zu vergleichen, drücke ich jeden Wert als Anteil seines Grenzwerts für gut aus:

$$r = \frac{v}{v_{\text{good}}} \times 100$$

Dabei ist $r$ der Wert in Prozent des Grenzwerts, $v$ der gemessene Wert beim p75 und $v_{\text{good}}$ der Grenzwert für gut bei dieser Kennzahl (2,5 Sekunden, 200 Millisekunden oder 0,1). Alles bei oder unter 100 % ist gut. Grundlagen: Verhältnisse und Raten.

Vorher: LCP $4{,}6 \div 2{,}5 = 184\%$, INP $380 \div 200 = 190\%$, CLS $0{,}22 \div 0{,}1 = 220\%$. Nachher: LCP $2{,}2 \div 2{,}5 = 88\%$, INP $170 \div 200 = 85\%$, CLS $0{,}05 \div 0{,}1 = 50\%$.

Die waagerechte Achse zeigt jede Kennzahl zweimal, vor und nach den Verbesserungen. Die senkrechte Achse zeigt den p75 Wert in Prozent seines Grenzwerts für gut, 100 % liegt also genau auf der Linie, und alles darunter ist gut. Vorher ragen alle drei Balken weit über 100 % hinaus, am schlimmsten die Layoutverschiebung mit mehr als dem Doppelten ihres Grenzwerts. Nachher liegen alle drei unter 100 %. Die Erkenntnis ist nicht, dass der Shop jetzt irgendwie allgemein schnell ist. Sie ist, dass drei von vier Besuchen auf dem Smartphone jetzt das Hauptfoto innerhalb von 2,5 Sekunden sehen, innerhalb von 200 Millisekunden eine Reaktion auf ihr Tippen bekommen und eine Seite vor sich haben, die stillhält. Ob dadurch mehr Tische verkauft wurden, ist eine andere Frage, und die beantwortet Hanna aus ihren eigenen Verkaufszahlen, nicht aus diesem Diagramm.

Wo es meistens schiefgeht

Einem Lighthouse Score hinterherlaufen. Das sind Labordaten von einem einzigen Rechner. Google sagt selbst, dass du wahrscheinlich Wichtigeres zu tun hast, als nur der SEO wegen einen perfekten Wert anzustreben.¹⁴ Verbessere die Felddaten und lass den Score folgen.

Auf dem eigenen Handy im WLAN im Laden testen. Das ist der Aufruf mit 1,4 Sekunden am schnellen Ende der sortierten Liste. Bewertet wird die Seite beim 75. Perzentil, und dieser Besucher sitzt im Regionalexpress irgendwo hinter Leverkusen.

Den Desktop anschauen und es dabei belassen. Smartphone und Desktop werden getrennt gemessen,¹ und für die meisten Shops liegt das Problem auf dem Smartphone.

Drei Dinge auf einmal ändern. Wenn sich die Zahl bewegt, weißt du nicht, welche Änderung es war.

Ein Umsatzplus versprechen. Miss es stattdessen.

Tempo ist eine Höflichkeit, die man messen kann

Core Web Vitals sind kein Rankingtrick. Sie beantworten drei schlichte Fragen, die jeder Besucher stellt: Ist es da, reagiert es, bleibt es ruhig? Google gewichtet sie bescheiden. Deine Besucher spüren sie jedes Mal, wenn sie warten.

Lies die Felddaten beim 75. Perzentil, Smartphone zuerst. Verbessere die Kennzahl, die am weitesten von gut entfernt ist, eine Ursache nach der anderen, und miss vier Wochen später noch einmal. Unspektakuläre Arbeit, und mit das Verlässlichste, was du für eine Website tun kannst.

Footnotes

1. Philip Walton, Web Vitals, web.dev, Google, 2024, https://web.dev/articles/vitals?hl=de

2. Philip Walton und Barry Pollard, Largest Contentful Paint (LCP), web.dev, Google, 2025, https://web.dev/articles/lcp?hl=de

3. Philip Walton und Barry Pollard, Largest Contentful Paint optimieren, web.dev, Google, 2025, https://web.dev/articles/optimize-lcp?hl=de

4. Jeremy Wagner und Barry Pollard, Interaction to Next Paint (INP), web.dev, Google, 2025, https://web.dev/articles/inp?hl=de

5. Jeremy Wagner und Rick Viscomi, Interaction to Next Paint wird am 12. März zu einem Core Web Vitals Messwert, web.dev Blog, Google, 2024, https://web.dev/blog/inp-cwv-march-12?hl=de

6. Jeremy Wagner, Philip Walton und Barry Pollard, Interaction to Next Paint optimieren, web.dev, Google, 2025, https://web.dev/articles/optimize-inp?hl=de

7. Milica Mihajlija und Philip Walton, Cumulative Layout Shift (CLS), web.dev, Google, 2023, https://web.dev/articles/cls?hl=de

8. Addy Osmani und Barry Pollard, Cumulative Layout Shift optimieren, web.dev, Google, 2025, https://web.dev/articles/optimize-cls?hl=de

9. Bryan McQuade und Barry Pollard, So wurden die Grenzwerte für die Core Web Vitals Messwerte definiert, web.dev, Google, 2025, https://web.dev/articles/defining-core-web-vitals-thresholds?hl=de

10. Philip Walton, Warum sich Labor und Felddaten voneinander unterscheiden, web.dev, Google, 2022, https://web.dev/articles/lab-and-field-data-differences?hl=de

11. Chrome for Developers, Übersicht über CrUX, Dokumentation zum Chrome UX Report, Google, 2024, https://developer.chrome.com/docs/crux?hl=de

12. Chrome for Developers, CrUX Methodik, Dokumentation zum Chrome UX Report, Google, 2024, https://developer.chrome.com/docs/crux/methodology?hl=de

13. Chrome for Developers, CrUX API, Dokumentation zum Chrome UX Report, Google, 2026, https://developer.chrome.com/docs/crux/api?hl=de

14. Google Search Central, Nutzerfreundlichkeit von Seiten bei Google, Google for Developers, 2026, https://developers.google.com/search/docs/appearance/page-experience?hl=de

15. web.dev, Vodafone: Eine Verbesserung des LCP um 31 % steigerte den Umsatz um 8 %, web.dev Fallstudien, Google, 2021, https://web.dev/case-studies/vodafone?hl=de