Core Web Vitals verbessern: ein Praxisleitfaden zu LCP, INP und CLS

Die Core Web Vitals sind drei Messgrößen, mit denen Google beschreibt, wie es sich anfühlt, eine Seite zu laden und zu nutzen: wie schnell der Hauptinhalt erscheint, wie schnell die Seite auf eine Interaktion reagiert und wie stark das Layout hin und her springt. Sie fließen in Googles Bewertung der Nutzererfahrung auf der Seite ein, auch wenn relevante, hilfreiche Inhalte für das Ranking weit mehr zählen. Vor allem aber sind sie ein guter Gradmesser dafür, ob sich Ihre Website schnell anfühlt.

Die drei Metriken und was als gut gilt

• Largest Contentful Paint (LCP) – der Zeitpunkt, zu dem das größte Bild oder der größte Textblock im Viewport dargestellt ist. Gut: höchstens 2,5 Sekunden; schlecht: mehr als 4 Sekunden.
• Interaction to Next Paint (INP) – wie lange die Seite braucht, um sichtbar auf Klicks, Tippen und Tastatureingaben zu reagieren, über den gesamten Besuch hinweg. Gut: höchstens 200 Millisekunden; schlecht: mehr als 500 ms. INP hat im März 2024 First Input Delay als Core Web Vital abgelöst.
• Cumulative Layout Shift (CLS) – wie stark sich sichtbare Inhalte unerwartet verschieben. Gut: höchstens 0,1; schlecht: mehr als 0,25.

Eine Seite besteht, wenn 75 % der Seitenaufrufe (das 75. Perzentil) bei jeder Metrik den Schwellenwert für „gut“ einhalten – getrennt gemessen für Mobilgeräte und Desktop. Das langsamere Viertel Ihrer Besucher fällt also nicht ins Gewicht, der typische Besucher mit einem Mittelklasse-Smartphone dagegen schon.

Labordaten und Felddaten im Vergleich

Felddaten stammen von echten Besuchern. Der Chrome UX Report von Google erfasst sie bei Chrome-Nutzern, die zugestimmt haben, über ein gleitendes 28-Tage-Fenster. Diese Daten zeigen der Core-Web-Vitals-Bericht der Search Console und der obere Bereich von PageSpeed Insights. Es sind die Daten, die zählen – sie setzen aber ausreichend Traffic voraus und ändern sich nur langsam.

Labordaten entstehen, wenn die Seite einmal unter kontrollierten Bedingungen geladen wird, so wie Lighthouse es tut. Sie liegen für jede Seite sofort vor und zeigen Ihnen, warum eine Metrik schlecht ausfällt – damit sind sie das Werkzeug für die Diagnose. Ein einzelner Labordurchlauf auf einem simulierten Smartphone entspricht aber nicht den echten Geräten und Netzen Ihrer Besucher, und den INP kann ein Labortest gar nicht messen, weil niemand mit der Seite interagiert. Die Total Blocking Time (TBT), also die Zeit, in der der Main-Thread während des Ladens zu beschäftigt ist, um zu reagieren, kommt ihm im Labor am nächsten.

Nutzen Sie beides: Felddaten, um zu erfahren, ob Sie ein Problem haben und ob Ihre Korrektur gewirkt hat, und Labordaten, um die Ursache zu finden. Wenn Sie eigene Felddaten erheben möchten: Die Open-Source-JavaScript-Bibliothek web-vitals meldet alle drei Metriken aus echten Besuchen an Ihre Webanalyse.

LCP verbessern

Die LCP-Zeit setzt sich aus vier Teilen zusammen: der Time to First Byte, der Verzögerung, bis der Browser mit dem Laden der LCP-Ressource beginnt, der Zeit für deren Download und der Verzögerung bis zur Darstellung. Finden Sie heraus, welcher Teil groß ist, und dann:

• Beschleunigen Sie die Serverantwort mit Seiten-Caching und einem CDN, damit das HTML schnell ankommt.
• Machen Sie das LCP-Bild früh auffindbar: Verwenden Sie ein normales <img> im HTML statt eines CSS-Hintergrunds oder eines per JavaScript eingefügten Bildes, und setzen Sie darauf niemals loading="lazy".
• Priorisieren Sie es: Versehen Sie das LCP-Bild mit fetchpriority="high" oder laden Sie es per Preload vor, wenn es erst spät referenziert wird.
• Verkleinern Sie es: Liefern Sie es in seiner Anzeigegröße als WebP oder AVIF aus – mehr dazu unter Bildgröße reduzieren.
• Entfernen Sie renderblockierende Ressourcen: Binden Sie kritisches CSS inline ein, laden Sie verzichtbare Skripte verzögert und vermeiden Sie aufwendiges clientseitiges Rendering, bevor der Hauptinhalt erscheint.

INP verbessern

Der INP ist schlecht, wenn der Main-Thread des Browsers in dem Moment beschäftigt ist, in dem jemand interagiert – meist mit dem Ausführen von JavaScript –, oder wenn die durch die Interaktion ausgelöste Arbeit lange braucht, bis etwas dargestellt wird.

• Liefern Sie weniger JavaScript aus. Entfernen Sie ungenutzte Bibliotheken und Plugins, teilen Sie Bundles auf und hydrieren Sie keine Seitenbereiche, die nicht interaktiv sein müssen.
• Zerlegen Sie lange Tasks. Teilen Sie Arbeit, die länger als 50 ms dauert, in kleinere Abschnitte auf und geben Sie dazwischen die Kontrolle an den Browser zurück – mit setTimeout oder, wo unterstützt, mit scheduler.yield().
• Tun Sie weniger in Event-Handlern. Aktualisieren Sie zuerst die Oberfläche und erledigen Sie dann die aufwendige Arbeit. Entprellen Sie Eingabe-Handler (Debouncing).
• Prüfen Sie Drittanbieter-Skripte. Chat-Widgets, Tag-Manager und A/B-Testing-Tools führen oft bei jeder Interaktion aufwendigen Code aus. Laden Sie sie später oder nur bei Bedarf.
• Halten Sie das DOM überschaubar, denn ein großes DOM verlangsamt jedes erneute Rendern.

CLS verbessern

• Geben Sie Bildern und Videos Abmessungen mit den Attributen width und height oder per CSS mit aspect-ratio, damit der Platz reserviert ist, bevor sie laden.
• Reservieren Sie Platz für Anzeigen, Einbettungen und Banner. Geben Sie ihren Containern eine Mindesthöhe und fügen Sie keine Inhalte oberhalb dessen ein, was der Besucher gerade liest.
• Bändigen Sie Webfonts. Verwenden Sie font-display: swap oder optional, laden Sie wichtige Schriften vorab und nutzen Sie eine Ersatzschrift mit angeglichenen Metriken (size-adjust), um die Verschiebung beim Eintreffen des Webfonts zu verringern.
• Animieren Sie mit transform, nicht mit Eigenschaften wie top oder height, die umliegende Inhalte verschieben.
• Lassen Sie den Back-Forward-Cache seine Arbeit tun – verzichten Sie auf unload-Handler –, damit Seiten bei der Rückkehr sofort und ohne Verschiebungen wiederhergestellt werden.

Wo Rudra ins Spiel kommt

Der kostenlose Website-Speed-Checker führt einen einzelnen Lighthouse-Labortest mit der standardmäßigen Mobilgeräte-Simulation aus. Jede Metrik wird mit ihrem Messwert angezeigt, als Labormessung aus einem einzelnen Durchlauf gekennzeichnet und mit den veröffentlichten Schwellenwerten verglichen – LCP 2,5 s / 4 s, CLS 0,1 / 0,25, TBT 200 / 600 ms. Nicht bestandene Prüfungen nennen bis zu fünf der verantwortlichen Dateien oder Elemente samt geschätzter Einsparung, damit Sie wissen, wo Sie ansetzen können. Den INP misst der Checker nicht, und Felddaten enthält er auch nicht. Diese finden Sie in der Search Console oder in PageSpeed Insights. Warum eine Seite insgesamt langsam ist, lesen Sie unter Warum ist meine Website langsam?.

Ein Vorgehen, das funktioniert

1. Sehen Sie im Core-Web-Vitals-Bericht der Search Console nach, welche Metrik durchfällt und bei welcher Gruppe von Seiten.
2. Wählen Sie eine repräsentative Seite aus dieser Gruppe und führen Sie mehrmals einen Labortest durch.
3. Beheben Sie zuerst die größte Ursache, spielen Sie die Änderung ein und testen Sie erneut im Labor.
4. Warten Sie, bis sich die Felddaten aktualisiert haben (das Fenster umfasst 28 Tage), bevor Sie das Ergebnis beurteilen.