Core Web Vitals: LCP, INP und CLS richtig verbessern
Die Core Web Vitals beschreiben ausgewählte Aspekte der Nutzererfahrung: wie schnell ein wichtiges Inhaltselement sichtbar wird, wie zügig die Seite auf Interaktionen reagiert und wie stabil sich das Layout verhält. Sie sind eine gute Orientierung für konkrete Verbesserungen. Ein einzelner Testlauf ist jedoch weder ein vollständiges Qualitätsurteil noch eine Zusage für Suchpositionen. Entscheidend ist, welche Probleme reale Besucher auf deinen wichtigen Seitentypen erleben.
In diesem Artikel
Die drei Messgrößen im Zusammenhang lesen
Largest Contentful Paint, kurz LCP, misst den Zeitpunkt, zu dem das größte relevante Inhaltselement im sichtbaren Bereich gerendert wird. Das kann ein großes Bild oder ein Textblock sein. Interaction to Next Paint, INP, beschreibt die Reaktionsfähigkeit bei Interaktionen über den Besuch hinweg. Cumulative Layout Shift, CLS, bewertet unerwartete Layoutverschiebungen. Keine dieser Größen lässt sich allein aus einer Serverausstattung zuverlässig vorhersagen.
Als gut gelten LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1. Für eine gute Einordnung müssen die drei Bedingungen jeweils am 75. Perzentil der betrachteten Besuche erfüllt sein. Mobile und Desktop-Erfahrungen können sich unterscheiden. Werte ohne Angabe des Datentyps, der betrachteten Seite und des Zeitraums sind deshalb schwer zu vergleichen.
| Messgröße | Guter Bereich | Häufige Ansatzpunkte |
|---|---|---|
| LCP | ≤ 2,5 Sekunden | Serverantwort, Hauptbild, blockierende Ressourcen |
| INP | ≤ 200 Millisekunden | Lange JavaScript-Aufgaben und Interaktionsabläufe |
| CLS | ≤ 0,1 | Reservierter Platz und stabile Schrift-/Bilddarstellung |
Felddaten und Laborwerte unterscheiden
Felddaten stammen aus tatsächlich beobachteten Besuchen. Dabei unterscheiden sich Geräte, Netzverbindungen und Nutzungsabläufe. Für kleine oder neue Websites stehen unter Umständen keine ausreichenden öffentlichen Daten bereit. Das ist kein automatischer Nachweis einer schlechten Website. Es bedeutet zunächst, dass eine belastbare öffentliche Feldbewertung fehlt. Eigene Messungen müssen datenschutzgerecht geplant und sauber interpretiert werden.
Ein Labortest läuft dagegen unter festgelegten oder simulierten Bedingungen. Er hilft, ein Problem wiederzufinden und eine Änderung zu vergleichen. Ein Laborwert bildet aber nicht alle echten Interaktionen ab. Besonders die Reaktionsfähigkeit verlangt eine Prüfung konkreter Bedienabläufe. Berichte deshalb getrennt, was im Labor beobachtet wurde und ob eine Feldbewertung existiert. Ein Screenshot eines grünen Testlaufs ersetzt diese Einordnung nicht.
LCP: Das sichtbare Hauptelement zuerst versorgen
Finde zunächst heraus, welches Element der Test als LCP erkennt. Bei einem großen Bild helfen passende Abmessungen, moderne Bildformate und ein zur Bildschirmgröße passendes Bild. Das sofort sichtbare Hauptbild sollte nicht durch unnötiges Lazy Loading oder erst spät ausgeführtes JavaScript entdeckt werden. Übertriebene Bildgrößen und eine lange Serverantwort können gleichzeitig zum Problem beitragen.
Prüfe außerdem, ob wichtige Stylesheets oder Schriften die Darstellung aufhalten. Lokale Schriften allein garantieren noch keine schnelle Anzeige; Dateigröße und Ladeverhalten bleiben relevant. Arbeite am tatsächlichen Engpass: Wenn zuerst mehrere Sekunden auf HTML gewartet wird, ist ein minimal kleineres Logo nicht die wichtigste Änderung. Miss denselben Seitentyp nach jeder größeren Anpassung erneut.
INP: Interaktionen als Abläufe untersuchen
Teste Navigation, Suche, Filter, Warenkorb und Dialoge auf einem weniger leistungsfähigen Gerät. Lange JavaScript-Aufgaben können verhindern, dass der Browser zügig auf eine Eingabe reagiert. Große Skriptpakete und aufwendige Arbeiten direkt im Ereignishandler verdienen Aufmerksamkeit. Teile umfangreiche Arbeit sinnvoll auf und entferne Funktionen, die für die Aufgabe keinen Nutzen bringen.
Eine sichtbare Rückmeldung unterstützt die Bedienung, ersetzt aber keine funktionierende Reaktion. Beobachte auch aufeinanderfolgende Aktionen und Zustände nach längerer Nutzung. Ein Filter kann beim ersten Klick unauffällig und nach vielen Interaktionen problematisch sein. Dokumentiere, welche konkrete Aktion betroffen ist, statt nur pauschal „JavaScript optimieren“ als Aufgabe festzuhalten.
CLS: Platz vorsehen und Änderungen prüfen
Bilder und eingebettete Inhalte sollten ihren benötigten Platz früh reservieren, etwa durch passende Größenangaben oder ein Seitenverhältnis. Nachladende Banner und dynamische Hinweise dürfen den bereits gelesenen Text nicht überraschend verschieben. Schriften mit deutlich anderen Abmessungen können beim Austausch ebenfalls für Bewegung sorgen. Prüfe deshalb den gesamten Ladeablauf, nicht nur den fertig aufgebauten Zustand.
Führe eine kurze Prioritätenliste nach Seitentyp: Startseite, Artikel, Produkt und gegebenenfalls Checkout. Behebe zuerst das Problem mit dem größten Einfluss auf echte Aufgaben. Anschließend prüfst du Darstellung, Bedienbarkeit und Messwerte gemeinsam. Diese Website veröffentlicht keine erfundenen Leistungswerte; verlässliche Aussagen brauchen einen benannten Messlauf oder eine ausreichend belastbare Feldgrundlage.
Quellen & Dokumentation
Primärquellen, geprüft am 3. November 2026. Angaben gelten im beschriebenen Zusammenhang; die konkrete Umgebung und der gebuchte Leistungsumfang bleiben maßgeblich.
Dazu passt auch
LiteSpeed-Seiten-Cache: Cache-Hit, Cache-Miss und sichere Ausnahmen
Wie LSCache fertige Seiten wiederverwendet, wann ein Purge sinnvoll ist und warum Warenkorb, Login und persönliche Inhalte besondere Regeln brauchen.
HTTP/2, HTTP/3 und QUIC: Was sich für Websites verändert
HTTP/3 verwendet QUIC statt TCP. Verstehe Streams, Paketverlust, Voraussetzungen und warum ein Protokollname noch keine schnellere Website garantiert.
NVMe und SSD beim Hosting: Was die Speicherangabe wirklich sagt
NVMe beschreibt eine Speicheranbindung, SSD das Speichermedium. Erfahre, welche Aussagen daraus folgen und warum sie keine Website-Benchmark ersetzen.