Core Web Vitals: erst messen, dann schrauben
Ein Laborlauf misst ein Gerät unter festgelegten Bedingungen, bewertet wird aber, was echte Besucher über 28 Tage erleben, und das erklärt die meisten Widersprüche.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Grün im Testwerkzeug und trotzdem Verbesserungsbedarf in der Search Console
Der übliche Ablauf: Jemand gibt die Adresse in PageSpeed Insights ein, bekommt eine hohe Punktzahl und schließt daraus, dass alles in Ordnung ist. In der Search Console steht dieselbe Seitengruppe weiter unter Verbesserungsbedarf. Beide Zahlen stimmen, sie messen nur nicht dasselbe: Die Punktzahl fasst einen einzelnen Laborlauf auf einem simulierten Gerät zusammen, die Bewertung stützt sich auf echte Aufrufe aus Chrome der letzten 28 Tage, ausgewertet am 75. Perzentil.
Der Schaden ist nicht die falsche Zahl, sondern die falsche Arbeit. Wer die Punktzahl optimiert, verschiebt Skripte nach hinten, schaltet Bilder auf verzögertes Laden und gewinnt im Laborlauf. INP bleibt trotzdem schlecht, weil das Problem erst auftritt, wenn jemand mit dreihundert Zeilen in der Liste auf einen Filter tippt. Ein Laborlauf klickt nirgendwo hin und kann diesen Fall gar nicht sehen.
Wie stark die drei Werte auf die Position in der Suche wirken, lässt sich von außen nicht beziffern, und jede genaue Angabe dazu ist geraten. Sicher ist der unmittelbare Effekt: Eine Seite, deren Text beim Lesen wegspringt, verliert die Person mitten im Satz, und ein Filter, der nach dem Tippen eine halbe Sekunde nichts tut, wird ein zweites Mal getippt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Symptom, Ursache, Lösung
Symptom
Das Testwerkzeug zeigt für die Seite eine hohe Punktzahl, in der Search Console steht dieselbe Seitengruppe trotzdem unter Verbesserungsbedarf.
Ursache
Die Punktzahl stammt aus einem einzelnen Laborlauf auf einem simulierten Mittelklassegerät mit gedrosselter Verbindung. Bewertet werden dagegen Felddaten aus dem Chrome User Experience Report: echte Aufrufe aus einem gleitenden Fenster von 28 Tagen, ausgewertet am 75. Perzentil und getrennt nach Mobil und Desktop.
Lösung
Im selben Bericht nach oben scrollen, dort stehen die Felddaten. Liegen für die einzelne Adresse zu wenige Aufrufe vor, zeigt der Bericht ersatzweise den Wert der ganzen Domain, was bei einer neuen Unterseite regelmäßig in die Irre führt. Für belastbare Zahlen je Seite gehört die web-vitals-Bibliothek in die Anwendung: Sie meldet LCP, INP und CLS aus echten Besuchen an das eigene Auswertungswerkzeug, dort getrennt nach Template.
Symptom
Die Überschrift steht sofort da, wechselt aber nach einem Moment sichtbar die Schrift, oder sie bleibt erst unsichtbar und erscheint dann komplett.
Ursache
Der Browser entdeckt eine Schriftdatei erst, wenn er das CSS geladen, geparst und die Regel auf ein Element angewandt hat. Bis dahin sind mindestens zwei Anfragen vergangen. Mit font-display swap zeigt er solange die Ersatzschrift und tauscht dann sichtbar, was einen Sprung erzeugt, wenn die Ersatzschrift anders breit läuft. Ohne die Angabe bleibt der Text zunächst unsichtbar, und genau er ist oft das LCP-Element.
Lösung
Die tatsächlich genutzte Datei mit rel preload und der Angabe as font sowie crossorigin vorziehen, damit sie nicht erst über das CSS gefunden wird. Als Format woff2 mit einer auf die benötigten Zeichen reduzierten Auswahl. Den Ersatz über size-adjust, ascent-override und descent-override so einstellen, dass er dieselbe Fläche belegt, dann kostet der Tausch keinen Sprung mehr. Und nur die Schnitte laden, die die Seite wirklich benutzt.
Symptom
Beim Lesen rutscht der Text nach unten, meist einmal kurz nach dem Aufbau der Seite.
Ursache
Ein Element bekommt seinen Platz erst, wenn es geladen ist: ein Bild ohne width und height, ein nachgeladener Hinweisbalken über dem Inhalt, eine eingebettete Karte, eine Werbefläche oder ein Schriftwechsel, der die Zeilenzahl ändert. CLS zählt bewusst nur Verschiebungen, die nicht innerhalb einer halben Sekunde auf eine Eingabe folgen. Ein Aufklappmenü, das du selbst geöffnet hast, zählt also nicht, ein Balken, der von allein erscheint, sehr wohl.
Lösung
Jedes Bild und jedes Video bekommt width und height im Markup, damit der Browser aus dem Verhältnis den Platz reserviert, bevor die Datei da ist. Eingebettete Blöcke bekommen aspect-ratio oder eine Mindesthöhe. Alles, was erst nach dem Laden entscheidet, ob es überhaupt erscheint, gehört als Überlagerung über den Inhalt und nicht in den Fluss. Für Elemente, die zwingend Platz brauchen, ist ein reservierter Bereich in der endgültigen Größe die einzige verlässliche Lösung.
Symptom
Ein Klick auf einen Filter oder eine Schaltfläche fühlt sich zäh an, obwohl die Seite schnell aufgebaut war.
Ursache
INP setzt sich aus drei Abschnitten zusammen: der Wartezeit, bis der Handler überhaupt starten darf, seiner eigenen Laufzeit und der Zeit bis zum nächsten gezeichneten Bild. Der dritte Abschnitt ist meist der größte, weil der Handler den Zustand ändert und der Browser danach eine lange Liste neu berechnet, das Layout auffrischt und zeichnet. Der Handler selbst sieht in der Messung dann harmlos aus.
Lösung
Erst die sichtbare Rückmeldung setzen, also den gedrückten Zustand oder die Ladeanzeige, dann dem Browser Gelegenheit zum Zeichnen geben und erst danach rechnen. In Chromium gibt es dafür scheduler.yield, portabel funktioniert ein Umweg über setTimeout mit null Millisekunden. Lange Listen bekommen content-visibility auto, damit der Browser nur den sichtbaren Bereich zeichnet, oder werden gleich nur ausschnittsweise gerendert.
Symptom
Das Testwerkzeug benennt das oberste Bild als LCP-Element, obwohl die Datei klein ist und schnell ankommt.
Ursache
Nicht die Übertragung ist das Problem, sondern der Zeitpunkt der Entdeckung. Ein Bild, das als Hintergrund im CSS gesetzt wird, findet der Browser erst nach dem Laden und Parsen des Stylesheets. Ein Bild, das erst der JavaScript-Aufbau in die Seite schreibt, findet er noch später. Und ein loading lazy am obersten Bild verzögert es zusätzlich, weil der Browser dann erst prüft, ob es überhaupt im sichtbaren Bereich liegt.
Lösung
Das oberste Bild gehört als img direkt in das ausgelieferte HTML, ohne loading lazy und mit fetchpriority high. Wenn es aus einem Karussell kommt, bekommt nur das erste Bild diese Behandlung, alle weiteren bleiben verzögert. Bei einem Hintergrundbild hilft ein preload mit passender imagesrcset-Angabe, besser ist der Umbau zu einem echten img mit object-fit cover.
Drei Werte, drei Schwellen
- 01 LCP misst, wann das größte sichtbare Element steht. Gut sind 2,5 Sekunden.
- 02 INP misst die Zeit vom Klick bis zum nächsten Bild. Gut sind 200 Millisekunden.
- 03 CLS misst, wie stark das Layout von selbst springt. Gut ist ein Wert bis 0,1.
- 04 Bewertet wird das 75. Perzentil echter Aufrufe, nicht der Durchschnitt.
- 05 Mobil und Desktop werden getrennt betrachtet, ein guter Wert reicht nicht für beide.
Was du danach selbst nachvollziehen kannst
Der Weg von einer schlechten Zahl zu einer geänderten Zeile Code ist kürzer, als er aussieht, wenn du in der richtigen Reihenfolge vorgehst: erst klären, ob die Zahl aus dem Feld oder aus dem Labor kommt, dann das verantwortliche Element benennen lassen, dann die Ursache im Markup suchen. Geraten wird an keiner dieser drei Stellen.
Feld und Labor auseinanderhalten
Felddaten stammen aus echten Chrome-Besuchen und entscheiden die Bewertung. Laborläufe sind reproduzierbar und gut zum Suchen von Ursachen. Wer beides verwechselt, optimiert eine Zahl, die niemand bewertet.
Das LCP-Element benennen lassen
Die Zusatzausgabe der web-vitals-Bibliothek nennt das Element und teilt die Zeit auf: Wartezeit bis zur ersten Antwort, Verzögerung bis zum Ladestart, Ladedauer und Zeit bis zur Darstellung. Erst dieser vierte Wert sagt, wo du ansetzt.
Sprünge zuordnen statt raten
Dieselbe Zusatzausgabe nennt bei CLS das Element mit der größten Verschiebung. Damit ist die Suche nach dem nachgeladenen Hinweisbalken oder dem Bild ohne Maßangabe in zwei Minuten erledigt.
Lange Aufgaben aufteilen
INP misst Wartezeit, Laufzeit des Handlers und die Zeit bis zum nächsten gezeichneten Bild. Meist steckt die Zeit im letzten Abschnitt. Du setzt zuerst die sichtbare Rückmeldung und gibst dem Browser danach Gelegenheit zu zeichnen.
Schriften und Bilder früh entdecken lassen
Der Browser kann nur laden, was er kennt. Eine Schrift entdeckt er erst über das CSS, ein per JavaScript eingefügtes Bild noch später. Vorziehen, Priorität setzen und das oberste Bild nicht verzögert laden lassen.
Eine Reihenfolge festlegen
Zuerst der schlechteste Wert auf dem Template mit dem meisten Verkehr, weil ein Template Hunderte Adressen abdeckt. Danach eine Änderung nach der anderen, sonst lässt sich im Feld nicht zuordnen, was gewirkt hat.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was die drei Werte genau messen
LCP misst den Zeitpunkt, zu dem das größte im sichtbaren Bereich dargestellte Element gezeichnet wurde. Kandidaten sind Bilder, das Vorschaubild eines Videos, Hintergrundbilder aus dem CSS und Textblöcke auf Blockebene. Während des Ladens wechselt der Kandidat mehrfach, gezählt wird der letzte vor der ersten Interaktion. Deshalb ist die erste Frage bei einem schlechten LCP nie wie schnell, sondern immer welches Element.
INP beobachtet über den gesamten Besuch Klicks, Tipper und Tastendrücke und meldet am Ende faktisch die langsamste dieser Interaktionen; bei Seiten mit sehr vielen Interaktionen fallen einzelne Ausreißer heraus. Scrollen und Überfahren mit der Maus zählen nicht. Ein Besuch ohne jede Interaktion liefert gar keinen Wert, weshalb Seiten mit reinem Lesetext hier oft gut aussehen, ohne etwas dafür getan zu haben.
CLS ist kein Zeitwert, sondern das Produkt aus zwei Anteilen: dem Anteil des sichtbaren Bereichs, den die verschobenen Elemente zusammen betreffen, und der zurückgelegten Strecke im Verhältnis zur größeren Seite des Anzeigebereichs. Gezählt wird nicht die Summe über den ganzen Besuch, sondern das schlechteste Zeitfenster: Verschiebungen, die höchstens eine Sekunde auseinanderliegen, werden zusammengefasst, ein Fenster ist höchstens fünf Sekunden lang. Verschiebungen innerhalb einer halben Sekunde nach einer Eingabe bleiben außen vor, weil sie erwartet sind.
Warum Feld und Labor auseinandergehen
Die Felddaten stammen aus dem Chrome User Experience Report, gesammelt bei Chrome-Nutzern, die der Übermittlung zugestimmt haben, in einem gleitenden Fenster von 28 Tagen. Je Adresse gibt es Zahlen nur bei ausreichend Verkehr, sonst tritt der Wert der gesamten Domain an ihre Stelle. Und das 75. Perzentil bedeutet: Ein Viertel aller Aufrufe darf schlechter sein, die Seite gilt trotzdem als gut. Umgekehrt kippt ein schlechtes Viertel den Wert, auch wenn der Median hervorragend aussieht.
Der Laborlauf misst einen einzigen Aufruf mit gedrosselter Verbindung und gedrosseltem Prozessor. Er kann INP grundsätzlich nicht messen, weil niemand klickt, und meldet stattdessen die Total Blocking Time als Ersatzgröße. Das ist ein nützlicher Hinweis auf lange Aufgaben im Hauptthread, aber eben kein INP. Wer im Labor an der Total Blocking Time arbeitet, verbessert INP oft mit, manchmal aber auch gar nicht.
Daraus folgt die Arbeitsteilung: Das Labor sagt dir, welche Datei blockiert und welches Element das LCP ist, weil es reproduzierbar ist. Das Feld sagt dir, ob es ein Problem gibt und ob deine Änderung geholfen hat. Und weil das Fenster 28 Tage lang ist, zeigt sich eine Verbesserung dort erst nach und nach, vollständig frühestens nach vier Wochen.
Die vier Bremsen, die im Frontend am häufigsten dahinterstecken
Schriften stehen am Ende einer Entdeckungskette: HTML, dann CSS, dann die Schriftdatei. Solange sie fehlt, zeigt der Browser entweder nichts oder eine Ersatzschrift, und beim Tausch verschiebt sich der Text, wenn die Ersatzschrift anders läuft. Das Gegenmittel besteht aus drei Teilen: die Datei vorziehen, den Zeichensatz reduzieren und die Ersatzschrift metrisch angleichen. Wer nur den ersten Teil macht, verlagert das Problem von LCP auf CLS.
Bei Bildern sind es fast immer vier Dinge: fehlende Maßangaben, verzögertes Laden am falschen Element, eine fehlende oder falsche Priorität und ein sizes-Attribut, das nicht stimmt. Der letzte Punkt ist der unauffälligste: Wenn sizes eine Breite behauptet, die das Bild nie hat, wählt der Browser aus dem srcset eine deutlich größere Datei als nötig, und alle Bemühungen um kleine Dateien laufen ins Leere.
Blockierende Skripte und nachgeschobene Elemente hängen oft zusammen. Ein Skript ohne defer im Kopf hält das Parsen an. Fremdskripte für Einwilligung, Tag-Verwaltung oder Chat laden weitere Skripte nach, und die erscheinen erst nach dem ersten Aufbau, beanspruchen Platz und erzeugen die Verschiebung. Der Reflex, alles nach hinten zu schieben, hilft LCP und schadet INP, weil dann alles gleichzeitig ankommt und den Hauptthread genau in dem Moment blockiert, in dem jemand zum ersten Mal tippt.
Womit du misst, ohne zu raten
Die web-vitals-Bibliothek gibt es in einer Variante mit Zusatzangaben. Für LCP liefert sie das Element als Selektor und die Aufteilung in Wartezeit bis zur ersten Antwort, Verzögerung bis zum Ladestart, Ladedauer und Zeit bis zur Darstellung. Für CLS nennt sie das Element mit der größten Verschiebung, für INP den Abschnitt und das Element, auf das geklickt wurde. Das ist der kürzeste Weg von einer Zahl zu einer Zeile Code, und er kostet ein paar Kilobyte.
In den Entwicklerwerkzeugen von Chrome markiert die Aufzeichnung im Leistungsbereich das LCP-Element und jede Verschiebung auf der Zeitachse. Die Einträge zu langen Animationsbildern zeigen zusätzlich, welches Skript den Hauptthread festgehalten hat, statt nur die Dauer zu melden. Für INP ist das die entscheidende Ansicht, weil sie den Unterschied zwischen langsamer Rechnung und langsamem Zeichnen sichtbar macht.
Was du nicht brauchst, ist ein Überwachungsdienst mit Monatsgebühr, bevor du die eigenen Felddaten gelesen hast. Und was du auf keinen Fall brauchst, ist eine Punktzahl in einem Wochenbericht: Sie schwankt zwischen zwei Läufen auf demselben Rechner, und die Diskussion über die Schwankung frisst die Zeit, die die eigentliche Ursache gekostet hätte.
Die Reihenfolge, in der sich die Arbeit lohnt
Zuerst das Template mit dem meisten Verkehr, nicht die Startseite aus Gewohnheit. Ein Template deckt Hunderte Adressen ab, und die Bewertung gruppiert Adressen mit ähnlichem Verhalten ohnehin zusammen. Wer eine einzelne Seite optimiert, verschiebt eine Zahl, die in der Gruppe kaum sichtbar wird.
Danach nach Aufwand sortiert: CLS ist meist am billigsten zu reparieren, weil Maßangaben und reservierte Flächen reine Markup-Arbeit sind. LCP folgt, weil dort Reihenfolge und Priorität entscheiden und selten die Architektur. INP kostet am meisten, weil dahinter oft die Frage steht, wie viel Arbeit eine Interaktion überhaupt auslösen darf.
Und dann eine Änderung nach der anderen, mit einer Notiz, wann sie live ging. Weil das Feld in einem Fenster von 28 Tagen misst, lässt sich sonst nicht auseinanderhalten, welche von drei gleichzeitig ausgelieferten Änderungen gewirkt hat und welche nichts gebracht hat.
Dazu passende Kurse
Wenn du an eigenen Seiten nachvollziehen willst, was die drei Kennzahlen über eine Seite verraten , gehört das in die Kurse rund um Webentwicklung bei cmt.
Ein großer Teil der Ursachen sitzt im CSS, deshalb lohnt es sich, Bilder, Schriften und Layout im Stylesheet sauber aufsetzen .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Die Schulung ist gerade für Einsteiger oder Entwickler*innen mit eingestaubtem Basiswissen sehr hilfreich.
Ich bin sehr glücklich Franz als Trainer gehabt zu haben. Er hat offensichtlich unglaublich viel Wissen zu den Themen, und schafft es, dieses auch interaktiv und verständlich weiterzugeben.
Häufige Fragen
Wie lange dauert es, bis eine Verbesserung sichtbar wird?
Zählt die Punktzahl aus PageSpeed Insights?
Was ist aus First Input Delay geworden?
Reicht es, die Startseite zu optimieren?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Webentwicklung-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Werte, die auch bei echten Besuchern stimmen
In den Kursen zu Frontend und Auslieferung bei cmt gehst du die Kette vom Markup bis zum Bauwerkzeug durch und siehst, an welcher Stelle Ladezeit tatsächlich entsteht.