Core Web Vitals verbessern: LCP, INP und CLS im Shop

Deine Produktseite lädt „eigentlich schnell“, trotzdem meldet die Search Console rote Balken und die Absprünge auf dem Handy sind hoch. Das liegt fast immer daran, dass du auf einem guten Gerät im WLAN testest und Google die Erfahrung echter Besucher misst. Dieser Artikel erklärt, was LCP, INP und CLS wirklich erfassen, woher die Zahlen kommen und in welcher Reihenfolge du die typischen Shop-Bremsen löst.

Die drei Werte in einfachen Worten

Die Core Web Vitals sind drei Messwerte, mit denen Google versucht, das Erlebnis auf einer Seite in Zahlen zu fassen: Wie schnell sehe ich etwas? Wie schnell reagiert die Seite auf mich? Springt das Layout herum?

LCP – Largest Contentful Paint

LCP misst, wann das größte sichtbare Element im ersten Bildschirm fertig gezeichnet ist. In Shops ist das fast immer das Hauptproduktbild, ein Kategorie-Hero oder eine große Überschrift. Gut ist ein Wert von höchstens 2,5 Sekunden, über 4 Sekunden bewertet Google ihn als schlecht.

Wichtig: LCP ist nicht „die Ladezeit“. Es ist der Moment, in dem der Besucher den Eindruck bekommt, die Seite sei da. Ein Skelett-Platzhalter hilft dem Gefühl, verbessert den LCP aber nicht, wenn das echte Bild danach noch drei Sekunden braucht.

INP – Interaction to Next Paint

INP misst, wie lange es von einer Eingabe – Klick, Tipp, Tastendruck – bis zur nächsten sichtbaren Reaktion dauert. Gemessen wird nicht der erste, sondern praktisch die langsamste relevante Interaktion eines Besuchs. Gut sind höchstens 200 Millisekunden, über 500 Millisekunden schlecht. INP hat im März 2024 den früheren Wert FID als Core Web Vital ersetzt; FID wurde abgeschafft und ist auch aus der Search Console verschwunden. INP ist dabei strenger: Es reicht nicht mehr, dass der erste Klick angenommen wird, die Seite muss auch sichtbar antworten.

Typische Shop-Fälle: Variante auswählen, Filter setzen, „In den Warenkorb“, Menü öffnen. Wenn dabei viel JavaScript rechnet, wird der Wert schlecht.

CLS – Cumulative Layout Shift

CLS misst, wie stark sich Inhalte nachträglich verschieben, ohne dass der Besucher es ausgelöst hat. Gut ist höchstens 0,1, über 0,25 schlecht. Der Klassiker: Du willst auf „In den Warenkorb“ tippen, im selben Moment lädt ein Banner über dem Button und du landest auf einem anderen Link.

Felddaten und Labordaten: warum die Zahlen auseinandergehen

Das ist der Punkt, an dem die meisten Diskussionen im Team entstehen. Es gibt zwei Quellen, und sie beantworten verschiedene Fragen.

Drei Konsequenzen daraus:

• Das 75. Perzentil entscheidet. Wenn drei von vier Aufrufen gut sind, bestehst du. Ein sehr schneller Durchschnitt hilft nicht, wenn ein Viertel deiner Besucher auf älteren Handys im Mobilfunknetz unterwegs ist.
• Mobil und Desktop werden getrennt bewertet. Fast alle Probleme in Shops sind Mobilprobleme.
• INP fehlt im Labortest. Lighthouse kann INP nicht messen, weil niemand klickt. Der Labortest zeigt dir stattdessen Hinweise wie lange Aufgaben im Hauptthread – nützlich, aber kein Ersatz.

Deine drei Werkzeuge, alle kostenlos: der Bericht zu den Core Web Vitals in der Google Search Console, PageSpeed Insights für eine einzelne URL mit Feld- und Labordaten gleichzeitig und die Dokumentation auf web.dev für die Definitionen. Für INP im echten Betrieb hilft zusätzlich die Chrome-Erweiterung Web Vitals, die dir beim Klicken live anzeigt, welche Interaktion hängt.

Ein Detail, das Zeit spart: Die Search Console gruppiert URLs mit ähnlichem Aufbau. Wenn dort „Produktseiten“ rot sind, musst du nicht 4.000 Seiten anfassen, sondern ein Template.

Die typischen Bremsen im Online-Shop

Bilder

Produktbilder sind in Shops fast immer das LCP-Element und der größte einzelne Hebel. Häufige Fehler: ein 2.400 Pixel breites Bild wird auf dem Handy in 380 Pixel Breite angezeigt, das Format ist noch JPEG statt WebP oder AVIF, und das wichtigste Bild hängt im Lazy Loading, obwohl es sofort sichtbar ist.

Was hilft: passende Größen ausliefern (srcset/sizes), moderne Formate, width und height immer setzen – das allein beseitigt einen großen Teil des CLS –, und für das erste sichtbare Bild loading="lazy" entfernen und stattdessen fetchpriority="high" setzen. Alles Weitere dazu steht in unserem Leitfaden zu Bilder-SEO und Alt-Texten.

Schriften

Zwei getrennte Probleme: Wenn Text erst erscheint, sobald die Schrift geladen ist, verschiebt sich der LCP nach hinten. Wenn zuerst eine Systemschrift angezeigt und dann getauscht wird, springt das Layout und der CLS steigt. Beides lässt sich entschärfen, indem du Schriftdateien selbst hostest, sie vorlädst, font-display: swap verwendest und die Ersatzschrift mit size-adjust an die Metriken der Webfont anpasst. Und: zwei Schnitte reichen fast immer, nicht sechs.

Apps, Skripte und Widgets

Hier liegt die häufigste Ursache für schlechten INP. Jede App, die im Shop Skripte einbindet – Bewertungen, Chat, Cookie-Banner, Popups für Newsletter, A/B-Tests, mehrere Tracking-Tools –, belegt den Hauptthread. Das Ergebnis: Der Klick auf „In den Warenkorb“ wird angenommen, aber die Reaktion kommt spät.

Mach eine Inventur: Welche App bringt messbar Umsatz, welche ist historisch gewachsen? Skripte, die nicht sofort gebraucht werden, gehören mit defer oder nach dem ersten Rendern geladen. Ein Chat-Widget kann auch erst beim Klick auf ein leichtes Platzhalter-Symbol nachgeladen werden.

Slider, Banner und Cookie-Hinweise

Ein Slider im ersten Bildschirm ist dreifach schlecht: Er lädt mehrere große Bilder, bringt eigenes JavaScript mit und verschiebt oft Inhalte. Cookie-Banner und Rabatt-Leisten, die per JavaScript oben eingefügt werden, drücken den restlichen Inhalt nach unten – ein sicherer CLS-Treffer. Lösung: Platz im Layout reservieren oder als Overlay einblenden, statt den Fluss zu verändern.

Server und Cache

Wenn schon die erste Antwort des Servers lange braucht (TTFB), sind alle anderen Optimierungen gedeckelt. Ursachen sind meist ungecachte Kategorieseiten mit vielen Filtern, langsame Datenbankabfragen oder ein Hosting ohne CDN. Bei gehosteten Systemen wie Shopify hast du hier weniger Einfluss, dafür mehr beim Theme und bei den Apps – dazu passt unser Artikel zu Shopify SEO. Welche Stellschrauben im Theme, bei Apps und Bildern am meisten bringen, steht im Artikel zur Ladezeit in Shopify.

Schritt für Schritt: Vorgehen in zwei Wochen

1. Bestand aufnehmen. Öffne den Core-Web-Vitals-Bericht in der Search Console, Reiter Mobil. Notiere die URL-Gruppen mit Status „schlecht“ oder „Verbesserung nötig“ und wie viele URLs betroffen sind.
2. Vorlagen statt Seiten. Wähle je Gruppe eine repräsentative URL: Startseite, eine Kategorieseite, eine Produktseite, eine Ratgeberseite. Mehr brauchst du nicht.
3. Je URL einmal PageSpeed Insights. Lies zuerst die Felddaten oben, dann die Diagnose unten. Schreibe für jede URL auf: Welches Element ist das LCP-Element? Welche Ressourcen blockieren? Welche Elemente verschieben sich?
4. Sortieren nach Aufwand. Trage die Befunde in zwei Spalten ein: „schnell und sicher“ (Bildgrößen, width/height, fetchpriority, Lazy Loading korrigieren, unnötige App entfernen) und „braucht Entwicklung“ (Theme-Umbau, Caching, JavaScript aufteilen).
5. Die schnellen Punkte umsetzen. Alles aus Spalte 1 in einem Durchgang. Erfahrungsgemäß erledigt das den Großteil von LCP und CLS.
6. Vorher/nachher im Labortest prüfen. Gleiche URL, gleiche Bedingungen, Lighthouse im Mobil-Modus. Der Labortest bestätigt, dass die Änderung technisch wirkt.
7. INP von Hand testen. Auf einem echten, eher langsamen Handy: Variante wechseln, filtern, in den Warenkorb legen, Menü öffnen. Wo es hängt, notieren und die verantwortlichen Skripte suchen.
8. Nach zwei Wochen Felddaten nachsehen. Erst dann bewegt sich der 28-Tage-Wert erkennbar. Wenn du in der Search Console eine Gruppe reparierst, kannst du die Validierung starten.

Checkliste für die Produktseite

• Das Hauptbild ist nicht per Lazy Loading verzögert und hat fetchpriority="high".
• Alle Bilder haben width und height oder ein festes Seitenverhältnis im CSS.
• Bilder werden in WebP oder AVIF und in mehreren Größen ausgeliefert.
• Maximal zwei Schriftschnitte, selbst gehostet, vorgeladen, mit font-display: swap.
• Cookie-Banner und Aktionsleisten verschieben keine Inhalte.
• Kein Slider im ersten Bildschirm; ein statisches Bild genügt.
• Skripte von Apps sind mit defer geladen oder werden erst bei Bedarf geholt.
• Nur ein Tracking-Setup, keine doppelten Tags aus alten Installationen.
• Auf dem Handy getestet, nicht nur im Desktop-Browser mit schmalem Fenster.
• Nach dem Umbau: Suche und interne Links noch intakt (siehe technisches SEO).

Was du realistisch erwarten darfst

Core Web Vitals sind ein Signal unter vielen. Eine schnelle Seite ohne passenden Inhalt rankt nicht, und der Sprung von „gut“ auf „sehr gut“ bringt für die Suche wenig. Der Nutzen liegt woanders: Besucher, die nicht abwarten müssen, brechen seltener ab. Wenn du bei einer Gruppe von Seiten von rot auf grün kommst, sieh dir parallel an, wie sich Absprünge und Conversion auf dem Handy entwickeln – die Zusammenhänge dazu stehen im Artikel über das Senken der Absprungrate.

Und nicht zuletzt: Wiederhole die Messung regelmäßig, nicht einmalig. Jede neue App, jedes neue Banner und jedes Theme-Update kann den Stand zurückdrehen. In ecomando landen die Werte aus dem SEO-Audit neben den Kennzahlen, damit du eine Verschlechterung siehst, bevor sie in der Search Console auffällt. Wer lieber ohne zusätzliches Werkzeug arbeitet, setzt sich einen monatlichen Termin und prüft die vier Vorlagen-URLs von Hand.

Wenn du bei technischem SEO gerade anfängst, lies davor den Überblick zu SEO für Online-Shops. Core Web Vitals sind der letzte Feinschliff, nicht der Anfang.