Core Web Vitals: Was LCP, INP und CLS wirklich messen.

Largest Contentful Paint, kurz LCP, meldet den Renderzeitpunkt des größten Bildes, Textblocks oder sichtbaren Videobereichs im anfänglichen Ansichtsfenster. Die Kennzahl sagt nicht, dass zu diesem Zeitpunkt jede Ressource geladen oder jede Funktion bereit ist. Sie nähert sich vielmehr der Frage, wann der prägende Seiteninhalt für den Besucher sichtbar geworden ist.

Interaction to Next Paint, kurz INP, betrachtet die Latenz von Klicks, Berührungen und Tastatureingaben über den gesamten Besuch. Meist prägt die langsamste beobachtete Interaktion den Wert. Bei Seiten mit vielen Interaktionen wird für jeweils 50 Interaktionen die höchste Latenz aus der Berechnung ausgeschlossen. INP ist kein Durchschnitt und keine reine JavaScript-Laufzeit. Eingabeverzögerung, Verarbeitung und die Zeit bis zum nächsten gezeichneten Bild gehören zusammen.

Cumulative Layout Shift, kurz CLS, bewertet unerwartete Verschiebungen sichtbarer Inhalte. Maßgeblich ist der stärkste zusammenhängende Schub solcher Verschiebungen. Eine bewusst ausgelöste, nachvollziehbare Veränderung ist nicht automatisch ein Problem. Kritisch wird es, wenn Text springt, ein Link unter dem Zeiger wegrutscht oder eine Schaltfläche an die Stelle einer anderen rückt.

04.1LCP: Antwort, Entdeckung, Laden und Rendern

Ein großes Hero-Bild ist ein auffälliger Kandidat, aber nicht automatisch die ganze Ursache. LCP beginnt mit der Navigation. Langsame Weiterleitungen, eine späte Serverantwort und die Entfernung zum Hostingstandort verbrauchen bereits Zeit, bevor der Browser das Dokument verarbeitet. Danach muss die wichtigste Ressource im HTML oder über einen passenden Ladehinweis früh auffindbar sein. Erst dann folgen Übertragung, Dekodierung und Darstellung. Blockierendes CSS, Webfonts oder viel Arbeit im Hauptthread können ein bereits geladenes Element weiter vom sichtbaren Renderzeitpunkt fernhalten.

Die richtige Reihenfolge lautet daher: LCP-Element bestimmen, Zeitanteile prüfen und den größten Anteil bearbeiten. Ein Hauptbild sollte in einer angemessenen Größe ausgeliefert, nicht absichtlich verzögert geladen und im frühen Dokument auffindbar sein. Ein pauschales Vorladen aller Bilder wäre dagegen kontraproduktiv, weil frühe Bandbreite begrenzt ist. Auch ein schnelleres Hosting löst kein Bild, das erst nach mehreren Skripten entdeckt wird.

04.2INP: Den Hauptthread wieder ansprechbar machen

Der Browser braucht den Hauptthread für Ereignisse, Layout und Darstellung. Lange Aufgaben können eine Eingabe warten lassen, obwohl die Oberfläche fertig aussieht. Häufige Ursachen sind große Skriptpakete, aufwendige Initialisierung, umfangreiche DOM-Änderungen und Ereignisbehandlungen, die zu viel Arbeit in einem Zug erledigen. Verbesserungen beginnen mit weniger unnötigem Code und kleineren Aufgaben. Eine Reaktion sollte früh sichtbar werden; aufwendige Folgearbeit kann, wenn die Funktion es erlaubt, später oder außerhalb des Hauptthreads stattfinden.

Ein einzelner schneller Menüknopf beweist noch keinen guten INP. Längere Besuche, Filter, Formulare, Akkordeons und nachgeladene Bereiche müssen in die Messung einbezogen werden. Besonders wichtig ist die Phase direkt nach dem Laden: Nutzer können bereits klicken, während Skripte noch ausgewertet werden. Deshalb gehören Ladeplanung und Interaktionsplanung zusammen.

04.3CLS: Platz reservieren, bevor Inhalte eintreffen

Bilder und Videos ohne intrinsische Maße sind ein klassischer Auslöser. Der Browser kennt ihren Platz erst nach dem Laden und schiebt vorhandenen Inhalt zur Seite. Breite und Höhe beziehungsweise ein verlässliches Seitenverhältnis geben ihm die nötige Geometrie vorher. Dasselbe Prinzip gilt für Banner, eingebettete Werkzeuge und Hinweise, die oberhalb bereits sichtbarer Inhalte erscheinen. Ihr Raum wird reserviert oder die Ergänzung wird an einer Stelle angeboten, an der sie nichts Überraschendes verdrängt.

Schriften können ebenfalls Verschiebungen verursachen, wenn Ersatzschrift und Webfont stark unterschiedliche Maße haben. Die Lösung ist nicht grundsätzlich, eigene Schriften zu vermeiden. Schriftdateien, Schnitte, Ladeverhalten und Fallbacks müssen als Teil des Layouts geplant werden. Bei Animationen sind Transformationen oft stabiler als Änderungen an geometrischen Eigenschaften. Bewegung muss zusätzlich die Einstellung für reduzierte Bewegung respektieren.

Eine schnelle Seite kann unverständlich, unzugänglich oder technisch unsicher sein. Umgekehrt darf fachlich wertvoller Inhalt nicht durch unnötige Wartezeit oder eine träge Navigation verborgen werden. Performance gehört deshalb in dieselbe Qualitätsprüfung wie responsives Layout, Tastaturbedienung, sichere Übertragung, robuste Formulare und klare Inhalte.

Auch zusätzliche Messgrößen behalten ihren Wert. Time to First Byte und First Contentful Paint helfen, LCP zu erklären. Ressourcenmenge, Übertragungsgröße und Cacheverhalten zeigen betriebliche Risiken, die ein einzelner Seitenaufruf nicht vollständig abbildet. Verfügbarkeit und Fehlerstatus gehören ebenso dazu. Wenn ein Kontaktformular schnell erscheint, aber nicht zuverlässig absendet, hat die Website ihre Aufgabe nicht erfüllt.

Die Gestaltung selbst ist kein Gegner der Geschwindigkeit. Hochwertige Typografie, Medien und Bewegung können funktionieren, wenn sie früh priorisiert, passend dimensioniert und auf schwächeren Geräten geprüft werden. Die bessere Frage lautet nicht „Wie entfernen wir alles?“, sondern „Welcher Bestandteil trägt zur Aufgabe bei, und wie liefern wir ihn ohne vermeidbare Verzögerung aus?“ Im Artikel Warum ein Entwurf noch keine fertige Website ist wird diese Trennung zwischen sichtbarer Oberfläche und belastbarer Umsetzung vertieft.

Ist eine Website mit 100 Punkten bei Lighthouse automatisch schnell?

Nein. Der Wert beschreibt einen simulierten Lauf und die Gewichtung der dort gemessenen Labordaten. Reale Geräte, Netze, Cachezustände und Interaktionen können andere Ergebnisse erzeugen. Felddaten und die konkreten Nutzerwege müssen zusätzlich geprüft werden.

Reicht PageSpeed Insights für eine Performancebewertung?

PageSpeed Insights ist ein sinnvoller Einstieg, weil es verfügbare CrUX-Felddaten und eine Lighthouse-Diagnose getrennt zeigt. Für eine Ursachenanalyse werden zusätzlich Entwicklertools und wiederholbare Tests benötigt. Bei größeren oder stark unterschiedlichen Nutzergruppen kann eigenes Real User Monitoring die fehlende Detailtiefe liefern.

Sind Core Web Vitals ein Rankingfaktor?

Google verwendet Core Web Vitals in seinen Rankingsystemen. Gute Werte garantieren jedoch keine gute Position und können fehlende Relevanz oder schwache Inhalte nicht ausgleichen. Optimiert wird deshalb zuerst für eine bessere Nutzung, nicht für eine vermeintlich sichere Rangfolge.

Wann wird eine Verbesserung in den Felddaten sichtbar?

Ein Labortest reagiert unmittelbar auf die veröffentlichte Änderung. CrUX fasst reale Daten in einem rollierenden 28-Tage-Fenster zusammen und benötigt ausreichend Besuche. Der öffentliche Feldwert verändert sich deshalb schrittweise und kann bei neuen oder wenig besuchten URLs fehlen.