Core Web Vitals für Onlineshops: LCP, INP und CLS erklärt

Was LCP, INP und CLS messen, die Grenzwerte im 75. Perzentil, Labor- und Felddaten und die üblichen Lösungen für Shopify- und WooCommerce-Shops.

FixReports Redaktion12 Min. Lesezeit

Core Web Vitals sind drei Messwerte von Google, die beschreiben, wie echte Besucher eine Seite erleben: Largest Contentful Paint (LCP) für das Laden, Interaction to Next Paint (INP) für die Reaktionsfähigkeit und Cumulative Layout Shift (CLS) für die visuelle Stabilität. Eine Seite besteht, wenn mindestens 75 % der Besuche im Bereich „gut“ liegen: LCP innerhalb von 2,5 Sekunden, INP innerhalb von 200 Millisekunden und CLS von höchstens 0,1, jeweils getrennt für Mobilgeräte und Desktop gemessen. In Onlineshops lassen sich schlechte Werte meist auf große oder per Lazy Loading geladene Hero- und Produktbilder, App- und Tracking-Skripte, Webfonts sowie Banner oder Bewertungs-Widgets zurückführen, die Inhalte nach dem Erscheinen der Seite nach unten schieben.

Das Wichtigste in Kürze

Welche Schwellenwerte gelten für die Core Web Vitals?

Eine Seite erfüllt die Core Web Vitals, wenn das 75. Perzentil ihrer Seitenaufrufe bei allen drei Messwerten im guten Bereich liegt.

MesswertWas er misstGutVerbesserungsbedürftigSchlecht
LCPZeit, bis das größte Bild, Video oder der größte Textblock im Viewport dargestellt wird2,5 s oder wenigerÜber 2,5 s bis 4,0 sÜber 4,0 s
INPZeit von einem Klick, Tippen oder Tastendruck bis zur Darstellung des nächsten Frames200 ms oder wenigerÜber 200 ms bis 500 msÜber 500 ms
CLSWie stark sich sichtbare Inhalte unerwartet verschieben0,1 oder wenigerÜber 0,1 bis 0,25Über 0,25

Die Schwellenwerte stammen aus den Leitfäden von web.dev zu LCP (öffnet in einem neuen Tab), INP (öffnet in einem neuen Tab) und CLS (öffnet in einem neuen Tab), Stand Oktober 2026.

Das 75. Perzentil bedeutet, dass das Ergebnis die meisten Besucher widerspiegelt und nicht nur die schnellsten, und Google wertet Mobilgeräte und Desktop getrennt aus (öffnet in einem neuen Tab). PageSpeed Insights bewertet eine Seite als bestanden, wenn alle drei Messwerte gut sind; liegen nicht genug INP-Daten vor, werden nur LCP und CLS beurteilt (Dokumentation zu PageSpeed Insights (öffnet in einem neuen Tab)). Laut Google ändern sich die stabilen Core Web Vitals höchstens einmal pro Jahr.

Im Shop ist das LCP-Element oft das Hero-Banner oder das Hauptproduktbild. Deshalb ist der Umgang mit Bildern so wichtig.

Warum hat INP im März 2024 FID abgelöst?

INP hat FID abgelöst, weil FID nur die erste Interaktion und davon nur einen Teil der Verzögerung gemessen hat, während INP Interaktionen während des gesamten Besuchs betrachtet.

Google kündigte im Mai 2023 an, dass INP zu einem Core Web Vital wird, und die Umstellung trat am 12. März 2024 (öffnet in einem neuen Tab) in Kraft. FID erfasste nur die erste Interaktion und davon nur die Eingabeverzögerung, nicht die Zeit für die Ausführung der Event-Handler oder die Darstellung des Ergebnisses. INP beobachtet Klicks, Tippen und Tastendrücke während des gesamten Besuchs und meldet die längste Interaktion, wobei Ausreißer ignoriert werden; Scrollen und Hovern zählen nicht. Nutzer der CrUX- und PageSpeed-Insights-APIs hatten bis zum 9. September 2024 Zeit für die Umstellung (web.dev (öffnet in einem neuen Tab)).

Jede Interaktion besteht aus drei Teilen: Eingabeverzögerung (Input Delay, das Warten auf ausgelastete Skripte), Verarbeitungsdauer (Processing Duration, das Ausführen der Handler) und Darstellungsverzögerung (Presentation Delay, das Zeichnen des nächsten Frames) (web.dev (öffnet in einem neuen Tab)).

Im Shop sind diese Interaktionen die Variantenauswahl, die Mengen-Buttons, „In den Warenkorb“, der Warenkorb-Drawer, Filter und Menüs. Eine Seite konnte FID mit einem schnellen ersten Tippen bestehen und sich trotzdem langsam anfühlen, wenn jemand später die Filter öffnete.

Was ist der Unterschied zwischen Labordaten und Felddaten?

Labordaten stammen aus einem einzelnen Test unter festen Bedingungen, Felddaten werden über einen Zeitraum bei echten Besuchern erhoben, und Google empfiehlt, anhand der Felddaten zu entscheiden, was Sie zuerst beheben (web.dev (öffnet in einem neuen Tab)).

LabordatenFelddaten
QuelleEin simulierter Seitenaufruf (Lighthouse, Chrome DevTools, der Laborbereich von PageSpeed Insights)Echte Chrome-Besucher (Chrome UX Report) oder Ihr eigenes Real User Monitoring
BedingungenFestes Gerät und festes Netzwerk. Der standardmäßige Mobiltest von Lighthouse (öffnet in einem neuen Tab) nutzt „Slow 4G“ (150 ms Round Trip, 1,6 Mbit/s Download) und eine 4-fache CPU-VerlangsamungDie Geräte, Netzwerke und Standorte, die Ihre Besucher eben haben
INPBei einem reinen Seitenaufruf nicht gemessen. Total Blocking Time (TBT) ist ein grober NäherungswertAus echten Interaktionen gemessen
Am besten geeignet fürFehlersuche und die Prüfung einer Änderung vor der VeröffentlichungZu wissen, was Besucher tatsächlich erleben

TBT summiert den Teil jeder Aufgabe im Main Thread, der über 50 ms hinausgeht. web.dev empfiehlt weniger als 200 ms auf durchschnittlicher mobiler Hardware, betont aber, dass TBT kein Ersatz für INP ist (web.dev (öffnet in einem neuen Tab)).

Drei Details des Chrome UX Report (CrUX) sind für Shops wichtig:

  • Er ist ein gleitender Durchschnitt über 28 Tage (öffnet in einem neuen Tab) und wird täglich aktualisiert.
  • Er erfasst Chrome auf Desktop und Android bei Nutzern, die die Meldebedingungen von Chrome erfüllen. Chrome unter iOS ist ausgeschlossen, daher sieht ein Shop, dessen Kunden überwiegend iPhones nutzen, Felddaten nur von einem Teil seines Publikums (Methodik (öffnet in einem neuen Tab)).
  • Seiten und Origins erscheinen nur, wenn sie öffentlich auffindbar sind und genug Besucher haben. Ein Shop mit wenig Traffic hat daher möglicherweise nur Daten auf Origin-Ebene oder gar keine.

Das Web-Performance-Dashboard (öffnet in einem neuen Tab) von Shopify meldet ebenfalls LCP, INP und CLS echter Nutzer im 75. Perzentil, allerdings über 30 statt 28 Tage. Rechnen Sie deshalb mit gewissen Abweichungen von CrUX.

Was bremst den LCP auf Shopseiten?

Der LCP ist in Shops meist langsam, weil das Hauptbild zu groß ist, zu spät entdeckt wird oder absichtlich durch Lazy Loading oder eine Animation verzögert wird.

  • Lazy Loading für das LCP-Bild. web.dev rät, das nie zu tun (web.dev (öffnet in einem neuen Tab)). Eine Analyse von WordPress-Seiten ergab einen langsameren LCP im 75. Perzentil auf Websites mit nativem Lazy Loading, und der Verzicht auf Lazy Loading für Bilder im sichtbaren Bereich (above the fold) beseitigte die Verschlechterung (web.dev (öffnet in einem neuen Tab)).
  • Ein spät gefundenes Bild. Ein Hero, der als CSS-background-image gesetzt oder von einem Slider-Skript eingefügt wird, steht nicht im HTML, das der Browser zuerst durchsucht. Shopify rät von CSS-Hintergründen für Hero-Inhalte und von Einblendeffekten auf dem LCP-Bild ab (Shopify (öffnet in einem neuen Tab)).
  • Niedrige Priorität. Bilder laden mit niedriger Priorität, bis das Layout fertig ist. Deshalb empfiehlt Shopify fetchpriority="high" für das LCP-Bild (Shopify (öffnet in einem neuen Tab)). web.dev merkt an, dass das Attribut an Nutzen verliert, wenn man es bei mehr als ein oder zwei Bildern setzt (web.dev (öffnet in einem neuen Tab)).
  • Render-blockierendes CSS und Skripte. Große Stylesheets und synchrone Skripte im <head> verzögern das Rendern, selbst wenn das Bild bereits geladen ist (web.dev (öffnet in einem neuen Tab)).
  • Dateigröße und Schriften. Nutzen Sie moderne Formate, srcset und sizes sowie ein CDN. Verwenden Sie für Webfonts einen font-display-Wert außer auto oder block.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

Was macht INP auf Shopseiten langsam?

Ein langsamer INP bedeutet in Shops meist zu viel JavaScript im Main Thread, vieles davon aus Apps, Tracking-Tags und Theme-Funktionen, sodass Eingaben warten müssen.

Tippt jemand auf „In den Warenkorb“, während Bewertungs-, Chat- und Analytics-Skripte noch laufen, wartet die Eingabe. Eine Variantenauswahl, die das gesamte Produktformular neu rendert, verlängert die Verarbeitungsdauer. Riesige Mega-Menüs und Kollektionsraster mit vielen Farbfeldern erhöhen die Darstellungsverzögerung.

web.dev empfiehlt, lange Aufgaben (Long Tasks) aufzuteilen und die Kontrolle regelmäßig an den Main Thread zurückzugeben (Yielding), zuerst den Bildschirm zu aktualisieren und den Rest aufzuschieben sowie das DOM kleiner zu halten (web.dev (öffnet in einem neuen Tab)). Shopify ergänzt shopspezifische Schritte: jede App, jedes Pixel und jedes Theme-Skript prüfen, Unkritisches verzögert laden, Funktionen erst bei einer Interaktion laden und Anti-Flicker-Snippets für A/B-Tests abschalten, wenn gerade kein Test läuft (Shopify (öffnet in einem neuen Tab)).

Was verursacht Layoutverschiebungen auf Produkt- und Kollektionsseiten?

Layoutverschiebungen entstehen in Shops meist durch Inhalte, die nach dem ersten Rendern erscheinen oder ihre Größe ändern: Bilder ohne Abmessungen, Ankündigungs- und Cookie-Leisten, Bewertungs-Widgets, App-Blöcke und Schriftwechsel.

web.dev nennt als häufige Ursachen Medien mit unbekannten Abmessungen, Inhalte, die oberhalb bestehender Inhalte eingefügt werden, Widgets von Drittanbietern, die ihre Größe selbst ändern, und Webfonts, deren Größe von der Fallback-Schrift abweicht (web.dev (öffnet in einem neuen Tab)). In Shops sind das etwa eine oben eingefügte Leiste für kostenlosen Versand, Sternebewertungen, die nach dem Titel laden, Hinweise zur Ratenzahlung unter dem Preis und Empfehlungskarussells. Shopify weist darauf hin, dass auch Pop-up-Inhalte Verschiebungen verursachen können (Shopify (öffnet in einem neuen Tab)).

Verschiebungen innerhalb von 500 ms nach einer Nutzereingabe zählen nicht, Verschiebungen beim Scrollen dagegen schon, und Labortools übersehen sie oft (web.dev (öffnet in einem neuen Tab)). Geben Sie Bildern width und height oder ein CSS-aspect-ratio, reservieren Sie Platz für Widgets, zeigen Sie Banner als Overlays an, reduzieren Sie Verschiebungen durch Schriftwechsel mit size-adjust und animieren Sie mit transform statt mit top oder left.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Wie verbessern Sie die Core Web Vitals bei Shopify?

Bei Shopify bringt es am meisten, das erste Bild sofort und mit hoher Priorität zu laden, App-Skripte zu reduzieren und das Ergebnis in den Web-Performance-Berichten des Adminbereichs zu prüfen.

Prüfen Sie die Daten in Ihrem Adminbereich

Eine Zusammenfassung erscheint auf der Seite Onlineshop > Themes (Online Store > Themes), vollständige Berichte zu LCP, INP und CLS finden Sie unter Analysen > Berichte (Analytics > Reports). Die Daten können bis zu 36 Stunden verzögert sein, und der Privatmodus muss deaktiviert sein (Shopify Help Center (öffnet in einem neuen Tab)).

Steuern Sie das Laden von Bildern in Liquid

Der Filter image_tag lädt Bilder in weiter unten liegenden Sections per Lazy Loading, sofern Sie nicht preload setzen (image_tag-Referenz (öffnet in einem neuen Tab)): sofort (eager) für die Sections 1 bis 3, lazy ab Section 4. Da section.index im Theme-Editor nil ist, prüfen Sie mit > 3 statt mit <= 3:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

In Produktrastern empfiehlt Shopify, nur die ersten paar Karten sofort zu laden (zum Beispiel forloop.index <= 4) (Shopify (öffnet in einem neuen Tab)). Setzen Sie preload: true sparsam ein; Shopify empfiehlt, nur ein oder zwei spät entdeckte Ressourcen vorzuladen.

Entfernen Sie, was Apps zurücklassen

Deaktivieren Sie ungenutzte App-Einbettungen unter Onlineshop > Theme bearbeiten > App-Einbettungen (Online Store > Edit theme > App embeds) (Shopify Help Center (öffnet in einem neuen Tab)). Beim Deinstallieren einer App werden ihre App-Blöcke entfernt, doch Apps, die Theme-Dateien direkt bearbeitet haben, können „Ghost Code“ hinterlassen, der laut Shopify Qualitäts- und Performance-Probleme verursachen kann (Shopify (öffnet in einem neuen Tab)). Shopify gibt außerdem an, dass Script-Tags ab dem 1. März 2027 nicht mehr ausgeführt werden. Bei Schriften empfiehlt Shopify das eigene CDN oder Systemschriften statt externer Schriftdienste (Shopify (öffnet in einem neuen Tab)).

Wie verbessern Sie die Core Web Vitals bei WooCommerce?

Achten Sie bei WooCommerce darauf, dass Plugins die Bildpriorisierung von WordPress nicht überschreiben, cachen Sie alles außer Warenkorb und Checkout und entfernen Sie Skripte, die ohne Bedarf überall geladen werden.

  • Behalten Sie die Bildverarbeitung des Core bei. Seit WordPress 6.3 (veröffentlicht am 8. August 2023) fügt der Core dem wahrscheinlichen LCP-Bild fetchpriority="high" hinzu (standardmäßig mindestens 50.000 Quadratpixel) und verzichtet bei den ersten drei Inhaltsbildern auf Lazy Loading (Make WordPress Core (öffnet in einem neuen Tab)). Wenn ein Optimierungs-Plugin eigenes Lazy Loading hinzufügt, prüfen Sie, ob es das Hero-Bild und das Hauptproduktbild ausnimmt.
  • Cachen Sie Seiten, nicht Warenkörbe. Der Leitfaden von WooCommerce empfiehlt Seiten-Caching auf dem Server oder per Plugin und ein CDN, wobei Warenkorb- und Checkout-Seiten nicht gecacht werden (WooCommerce-Entwicklerdokumentation (öffnet in einem neuen Tab)).
  • Prüfen Sie die Cart Fragments. Seit WooCommerce 7.8 lädt das Cart-Fragments-Skript nur dort, wo ein Warenkorb-Widget vorhanden ist, manche Themes binden dieses Widget aber fest ein. Der Mini-Cart-Block nutzt keine Cart Fragments (WooCommerce-Entwicklerblog (öffnet in einem neuen Tab)).
  • Finden Sie schwere Plugins. WooCommerce empfiehlt Query Monitor, um langsame Plugins zu finden, und rät, nicht kritisches JavaScript verzögert zu laden.

Wenn Ihr Layout mehr als drei Bilder im sichtbaren Bereich (above the fold) zeigt, können Sie den Schwellenwert von WordPress erhöhen:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

Wie lange dauert es, bis Korrekturen sichtbar werden?

Labortests zeigen die Wirkung einer Korrektur sofort, Felddaten brauchen dagegen bis zu etwa vier Wochen, um sie vollständig widerzuspiegeln, weil CrUX die vorangegangenen 28 Tage mittelt.

Führen Sie den Labortest vor und nach einer Änderung mehrmals aus, weil einzelne Durchläufe schwanken, und beobachten Sie dann die Felddaten in PageSpeed Insights, im Core-Web-Vitals-Bericht der Search Console oder in den Berichten von Shopify. Ein kostenloser Scan liefert in etwa einer Minute eine erste Einschätzung. Der Performance-Report führt einen gedrosselten mobilen Labortest aus (langsames 4G, 4-fache CPU-Verlangsamung) und ergänzt Felddaten aus dem Chrome UX Report, einschließlich INP, wenn Google genug Daten zu Ihrem Shop hat.

Häufig gestellte Fragen

Beeinflussen die Core Web Vitals das Google-Ranking?

Laut Google werden die Core Web Vitals von seinen Ranking-Systemen verwendet. Gute Werte garantieren aber keine Top-Rankings, und Google zeigt weiterhin die relevantesten Inhalte, auch wenn die Nutzererfahrung auf der Seite schlecht ist (Google Search Central (öffnet in einem neuen Tab)).

Warum zeigt PageSpeed Insights keine Felddaten für meinen Shop an?

CrUX enthält nur Seiten und Origins, die öffentlich auffindbar sind und genug berücksichtigte Chrome-Besucher haben. Ein Shop mit wenig Traffic hat möglicherweise nur Daten auf Origin-Ebene oder gar keine. Verlassen Sie sich dann auf Labortests und die eigenen Berichte Ihrer Plattform.

Brauche ich einen Lighthouse-Score von 90 oder mehr, um zu bestehen?

Nein. Der Lighthouse-Performance-Score ist ein Laborergebnis, während die Bewertung der Core Web Vitals Felddaten im 75. Perzentil verwendet. Eine Seite kann also mit einem mäßigen Lighthouse-Score bestehen und mit einem hohen durchfallen.

Sollte ich alle Produktbilder per Lazy Loading laden?

Nein. Laden Sie Bilder unterhalb des ersten Bildschirms per Lazy Loading, das Hero-Bild und das Hauptproduktbild aber sofort, mit fetchpriority="high" bei einem der beiden.

Warum sind meine Ergebnisse auf Mobilgeräten schlechter als auf dem Desktop?

Google misst Mobilgeräte und Desktop getrennt, und Smartphones haben langsamere Prozessoren und Netzwerke. Der Mobiltest von Lighthouse simuliert das mit einem Slow-4G-Profil und einer 4-fachen CPU-Verlangsamung.

Quellen

Alle Ratgeber