Core Web Vitals: LCP, INP und CLS

Modul 4: Geschwindigkeit, Mobilgeräte und https · Lesezeit: 13 Minuten

Lernziel: Nach dieser Lektion können Sie die drei Core Web Vitals mit ihren Grenzwerten erklären, den Unterschied zwischen Felddaten und Labordaten benennen, eine Messung mit PageSpeed Insights lesen, die wichtigsten Ursachen einer schlechten Bewertung angehen und ehrlich einschätzen, wie stark Geschwindigkeit in den Suchergebnissen zählt.

Kernbegriffe: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75. Perzentil, Felddaten (CrUX), Labordaten (Lighthouse), PageSpeed Insights, Core Web Vitals-Bericht in der Search Console, TTFB, Komprimierung, width und height bei Bildern, loading="lazy", Nutzerfreundlichkeit der Seite (Page Experience)

Geschwindigkeit in drei Zahlen

"Ist meine Website schnell?" ist eine vage Frage. Google und die Entwickler von Chrome haben daraus drei messbare Fragen gemacht, die Core Web Vitals:

Ein paar Dinge sollten Sie genau verstehen:

• LCP misst den Moment, in dem das größte sichtbare Element erscheint. Das ist meist ein großes Foto ganz oben (das "Hero"-Bild) oder ein großer Textblock. Bei Bloemenatelier Lotte ist es das Foto des Blumengestecks auf der Startseite.
• INP betrachtet alle Klicks, Tipps und Tastenanschläge während des Besuchs und meldet (fast) die langsamste Reaktion. INP hat am 12. März 2024 den älteren Messwert FID (First Input Delay) abgelöst, der nur den ersten Klick und nur die Wartezeit vor der Verarbeitung betrachtete. Begegnet Ihnen FID in einem älteren Artikel, ist das überholt.
• CLS ist keine Zeit, sondern ein Wert ohne Einheit. Er steigt, wenn sich Dinge verschieben, während Sie lesen: Sie wollen auf eine Schaltfläche tippen, und genau in diesem Moment schiebt sich oben ein Banner hinein, sodass Sie etwas anderes antippen.

Das 75. Perzentil

Eine Seite "besteht" die Core Web Vitals, wenn 75 Prozent der Besuche bei allen drei Werten gut abschneiden, getrennt gemessen für Mobilgeräte und Desktop. Das nennt man das 75. Perzentil. Es bedeutet: Nicht Ihr eigener schneller Computer am Glasfaseranschluss zählt, sondern die Erfahrung der meisten Besucher, auch derjenigen mit einem älteren Smartphone im 4G-Netz.

Felddaten und Labordaten

Es gibt zwei Arten von Messungen, und sie liefern oft unterschiedliche Zahlen.

• Felddaten stammen von echten Besuchern. Chrome erfasst (bei Nutzern, die das erlauben) anonym, wie schnell Seiten waren, im Chrome User Experience Report (CrUX). PageSpeed Insights zeigt die Felddaten der letzten 28 Tage. Der Core Web Vitals-Bericht in der Search Console nutzt dieselbe Quelle. Hat Ihre Seite zu wenige Besucher, zeigt PageSpeed Insights die Werte Ihrer gesamten Website (den "Origin"), und hat auch diese zu wenige, gibt es keine Felddaten.
• Labordaten stammen aus einem simulierten Test mit Lighthouse: einmaliges Laden auf einem nachgebildeten durchschnittlichen Smartphone mit entsprechender Verbindung. Lighthouse kann INP nicht messen (es klickt ja niemand) und liefert deshalb andere Werte, etwa Total Blocking Time, die einen Hinweis auf INP geben.

Für die Bewertung zählen die Felddaten. Labordaten sind praktisch, um Ursachen zu finden und nach einer Verbesserung sofort zu sehen, ob sie wirkt, ohne 28 Tage zu warten.

Wie stark zählt das?

Hier wird viel übertrieben. Das sagt Google selbst in der Dokumentation zur Nutzerfreundlichkeit von Seiten (Page Experience):

• "Core Web Vitals are used by our ranking systems": Sie fließen also ein.
• Es gibt kein eigenes "Page-Experience-Signal". Andere Bestandteile einer guten Nutzererfahrung (https, keine aufdringlichen Pop-ups, gute Bedienbarkeit auf Mobilgeräten) bringen Sie laut Google nicht direkt weiter nach oben, machen Ihre Website aber angenehmer.
• "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." Eine langsame Seite mit der besten Antwort kann also ganz oben stehen.
• Eine perfekte Bewertung nur für SEO anzustreben, ist laut Google "vielleicht nicht die beste Verwendung Ihrer Zeit".

Fazit: Sorgen Sie dafür, dass Sie im grünen oder zumindest im orangefarbenen Bereich liegen, vor allem weil Besucher eine langsame oder springende Seite verlassen. Von 90 auf 100 Punkte in Lighthouse zu jagen, bringt in den Suchergebnissen wenig.

Ursachen, die Sie selbst angehen können

Eine langsame erste Antwort (TTFB)

Alles beginnt mit dem Moment, in dem das erste Byte des HTML ankommt, der Time to First Byte. TTFB ist selbst kein Core Web Vital, aber eine langsame TTFB macht einen guten LCP-Wert fast unmöglich. web.dev nennt als Richtwert: gut sind 0,8 Sekunden oder weniger, schlecht sind mehr als 1,8 Sekunden. Ursachen laut web.dev: zu wenig Rechenleistung beim Hosting, kein Cache (jede Seite wird neu aufgebaut, typisch bei WordPress ohne Cache-Plugin), Weiterleitungen (Lektion 4.1) und ein weit entfernter Server ohne CDN.

Komprimierung gehört dazu: Der Server sollte HTML, CSS und JavaScript komprimiert mit gzip oder Brotli senden. Sie erkennen das an der Kopfzeile Content-Encoding: gzip oder br. Fast jedes Hosting macht das standardmäßig, aber eine falsche Einstellung oder ein alter Server kann es abschalten.

Bilder

Bilder sind die häufigste Ursache für schlechte LCP- und CLS-Werte:

1. Zu groß. Ein Foto mit 4.000 Pixeln Breite und 5 MB für einen Bereich von 800 Pixeln. Verkleinern Sie Bilder vor dem Hochladen und verwenden Sie ein modernes Format wie WebP oder AVIF.

2. Keine Breite und Höhe. Ohne width und height weiß der Browser nicht, wie viel Platz das Bild braucht, und der Text darunter springt, sobald es geladen ist. web.dev empfiehlt, width und height bei jedem <img> anzugeben:

   <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">

3. Das wichtigste Foto verzögert laden. loading="lazy" lädt ein Bild erst, wenn es in den sichtbaren Bereich kommt. Gut für Fotos weiter unten, aber web.dev sagt klar: Bilder, die beim Öffnen bereits sichtbar sind, und vor allem das LCP-Bild sollten Sie nicht verzögert laden. Sonst wartet der Browser ausgerechnet mit dem Foto, das Ihren LCP-Wert bestimmt.

Springende Inhalte und langsame Reaktionen

Weitere Ursachen für CLS laut web.dev: Schriftarten, die beim Laden ihre Größe ändern, Anzeigen und eingebettete Widgets, die sich selbst vergrößern, und Inhalte, die nachträglich oberhalb der bestehenden Inhalte eingefügt werden (etwa ein Cookie-Banner, der die Seite nach unten schiebt, statt darüber zu liegen). Ein schlechter INP-Wert entsteht fast immer durch zu viel JavaScript: schwere Themes, Slider, Chat-Widgets und Tracker von Drittanbietern. Prüfen Sie jedes Plugin und jeden eingebetteten Dienst kritisch; weniger ist hier wirklich mehr.

In der Praxis: Messen mit PageSpeed Insights

Rufen Sie pagespeed.web.dev auf, geben Sie die Adresse Ihrer Startseite ein und klicken Sie auf Analysieren. Sie erhalten zwei Tabs (Mobilgerät und Desktop). Oben steht die Bewertung der Core Web Vitals auf Basis der Felddaten, sofern vorhanden. Darunter folgt der Lighthouse-Test mit einer Punktzahl und einer Liste "Diagnose" mit konkreten Punkten, zum Beispiel zu Bildern, die größer sind als nötig, oder zu einem LCP-Bild, das verzögert geladen wird (die genauen Bezeichnungen ändern sich mit neuen Lighthouse-Versionen). Beginnen Sie mit Mobilgerät: Dort sind die Werte meist schlechter, und Google betrachtet zuerst die mobile Version (Lektion 4.2).

Haben Sie Ihre Website in der Search Console (Modul 2), sehen Sie auch unter Nutzerfreundlichkeit, Core Web Vitals nach. Dort finden Sie Gruppen ähnlicher Seiten mit ihrem Status, auch für Seiten, die Sie selbst nicht getestet haben.

Eine Website aus dem AI Builder setzt Breite und Höhe bei Bildern, deren Maße bekannt sind, lädt das erste Foto der Seite sofort und mit Vorrang (fetchpriority="high") und den Rest verzögert, und erstellt beim Veröffentlichen von großen Fotos eine 800 Pixel breite Variante. In WordPress helfen ein Cache-Plugin und das Verkleinern von Bildern am meisten; der WordPress-Kurs geht in Modul 6 genauer darauf ein. Bei anderen Website-Baukästen und Hostinganbietern funktioniert es ähnlich: Die Schaltflächen unterscheiden sich, die Ursachen sind dieselben.

Zusammenfassung

• Die Core Web Vitals sind LCP (gut bis 2,5 s), INP (gut bis 200 ms, seit März 2024 anstelle von FID) und CLS (gut bis 0,1), gemessen am 75. Perzentil je Gerätetyp.
• Felddaten (CrUX, 28 Tage) bestimmen die Bewertung; Labordaten (Lighthouse) helfen, Ursachen zu finden.
• Google nutzt die Core Web Vitals im Ranking, aber Relevanz hat Vorrang: Eine perfekte Bewertung ist kein Selbstzweck.
• Größter Gewinn: schnelle Serverantwort mit Cache und Komprimierung, kleine Bilder mit width und height, das wichtigste Foto nicht verzögert laden, weniger JavaScript von Drittanbietern.

Quiz

Aufgabe

Aufgabe A4.3: Schnelle Antwort und leichte Bilder. Geben Sie die Adresse einer Seite ein. Das Programm misst dreimal die Zeit bis zum ersten Byte (TTFB) von unserem Server aus und nimmt den mittleren Wert, prüft, ob das HTML komprimiert gesendet wird (gzip, Brotli oder zstd), zählt die Bilder ohne width und height und prüft, ob das wichtigste Bild oben auf der Seite nicht mit loading="lazy" geladen wird. Beachten Sie: Dies ist eine Messung von einem einzigen Standort aus, keine Messung Ihrer Besucher. Keine eigene Website? Verwenden Sie www.wikipedia.org.

Aufgabe D4.3: Ihre Core Web Vitals. Lassen Sie PageSpeed Insights für Ihre Startseite und für eine weitere wichtige Seite laufen, zuerst für Mobilgerät. Notieren Sie je Seite: ob es Felddaten gibt (für die Seite oder die gesamte Website), LCP, INP und CLS aus den Felddaten, die Lighthouse-Punktzahl und das Element, das Lighthouse als LCP-Element angibt. Wählen Sie die eine Verbesserung, die Ihrer Meinung nach am meisten bringt, und begründen Sie Ihre Wahl.

Weiterführende Links

• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP): https://web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS): https://web.dev/articles/cls
• web.dev, Time to First Byte (TTFB): https://web.dev/articles/ttfb
• web.dev, Browser-level image lazy loading: https://web.dev/articles/browser-level-image-lazy-loading
• Google Search Central, Understanding page experience in Google Search results: https://developers.google.com/search/docs/appearance/page-experience
• PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
• Search Console-Hilfe, Core Web Vitals-Bericht: https://support.google.com/webmasters/answer/9205520