Core Web Vitals verbessern: LCP, INP und CLS verständlich erklärt

Drei Kennzahlen, drei Fragen

Der LCP (Largest Contentful Paint) misst den Zeitpunkt, an dem das größte Element lädt; ich ziele auf unter 2,5 Sekunden. Der INP (Interaction to Next Paint) misst die Reaktionszeit bei Klicks, wobei ich 200 Millisekunden anstrebe. Den CLS (Cumulative Layout Shift) nutze ich für Layout-Stabilität und versuche, unter 0,1 zu bleiben.

Ich werte stets das 75. Perzentil der echten Besuche aus. Das heißt, drei von vier Aufrufen müssen meine Zielwerte erreichen, nicht nur ein reiner Durchschnittswert.

Felddaten und Labordaten auseinanderhalten

Felddaten spiegeln meine echte Nutzerschaft wider, während Labordaten mir bei der Fehlersuche helfen. Beide sind für mich wichtig, da gerade in Deutschland die Nutzung mobiler Netze und älterer Hardware eine Rolle spielt, die ein lokaler Test nicht immer simuliert.

Bei kleinen Projekten fehlen oft genug Felddaten. In solchen Fällen nutze ich Labordaten als wichtigen Anhaltspunkt, bin mir aber bewusst, dass sie kein exaktes Bild meiner Nutzer liefern.

Typische Ursachen und ihre Behebung

Ich arbeite bekannte Ursachen in einer festen Abfolge ab und messe nach jeder Änderung neu, ob sich meine Werte gebessert haben.

• Ein schlechter LCP liegt bei mir oft an zu schweren Hero-Bildern, fehlenden Preloads oder langsamen Serverantwortzeiten.
• Einen schwachen INP-Wert erkläre ich mir meist durch zu viel JavaScript im Hauptthread oder schwere Drittanbieter-Skripte wie Chat-Widgets.
• Einen hohen CLS-Wert bemerke ich oft bei Bildern ohne Größenangaben, Banner, die nachträglich laden, oder verzögert geladene Schriftarten.
• Auch Cookie-Banner, die Inhalte beim Laden verschieben, führen häufig zu einem schlechten CLS.

Eine praktische Reihenfolge

Ich nutze den Bericht in der Search Console, da Seiten mit ähnlichem Layout dort gruppiert sind. Ich behebe Ursachen erst für die größte Gruppe, statt jede URL einzeln anzupassen.

Ich entferne überflüssige Skripte, da jedes Widget Ladezeit kostet, die der Nutzer zahlt. Und ich vergesse nicht: Eine extrem schnelle Seite mit inhaltlich wertlosen Inhalten rankt trotzdem nicht, da die Vitals nur ein Teil der Gleichung sind.

Umsetzung: Messen, entscheiden, nachprüfen

Ich beginne mit dem Bericht zur Seitenindexierung und notiere, welche Gruppen optimierungsbedürftig sind. Ich rufe eine typische Seite der Gruppe in einem Labortest auf und suche nach dem größten Hebel. Oft zeigt der Test, welches Element den LCP-Wert bestimmt oder welche Skripte den Hauptthread blockieren.

Ich behebe die Ursache, veröffentliche und warte, bis genug Felddaten vorliegen. Die Search Console basiert auf einem rollierenden Zeitraum, weshalb Verbesserungen erst nach und nach wirken. In der Zwischenzeit prüfe ich im Labor, ob meine Änderung gegriffen hat. Verbessert sich der Wert, ohne Inhalt oder Funktion zu schaden, behalte ich die Änderung bei. Beeinträchtigt sie etwa die Bedienung eines Formulars, wäge ich ab.

• Ich identifiziere die Ursache im Labortest: Bilder, Skripte, Schriften oder Banner.
• Ich nehme pro Veröffentlichung nur eine Änderung vor.
• Ich warte auf Felddaten und nutze den Labortest als Zwischenkontrolle.
• Ich teste ausgetauschte Drittanbieter-Skripte auf ihre Funktion.

Beispiel: Ein Hero-Bild bremst die Startseite

Ein Café bindet ein Foto in Originalgröße ein. Die Datei wiegt mehrere Megabyte und lädt sehr langsam, was besonders im Mobilfunknetz dazu führt, dass der wichtigste Inhalt erst spät erscheint.

Meine Lösung: Ich skaliere das Bild auf die benötigte Größe, wähle ein modernes Format, gebe die Abmessungen im Code an und deaktiviere das „Lazy Loading“ für Bilder im sichtbaren Bereich. Danach prüfe ich das Ergebnis mit realen Nutzerdaten, statt mich nur auf Labordaten zu verlassen.

Häufige Fragen zu Core Web Vitals