Core Web Vitals: LCP, INP und CLS erklärt, mit Tipps für Shops

Core Web Vitals sind drei Messwerte, mit denen Google die Nutzererfahrung einer Seite bewertet: Largest Contentful Paint (LCP) für das Laden, Interaction to Next Paint (INP) für die Reaktion auf Eingaben und Cumulative Layout Shift (CLS) für ein stabiles Layout. INP hat am 12. März 2024 den alten Messwert First Input Delay (FID) als Core Web Vital abgelöst.

Hier findest du die aktuellen Grenzwerte, die richtigen Messwerkzeuge, eine ehrliche Einordnung zum Ranking und konkrete Tipps für Online-Shops. Zum Schluss zeige ich dir echte Messwerte vom Umbau dieser Seite.

Was sind die Core Web Vitals?

Die Core Web Vitals sind der Kern der Web-Vitals-Initiative von Google. Sie messen drei Dinge, die Besucher direkt spüren: Wann ist der Hauptinhalt da? Reagiert die Seite auf Eingaben? Bleibt das Layout ruhig?

Entscheidend ist das 75. Perzentil: Mindestens drei von vier Seitenaufrufen müssen den Grenzwert schaffen. Ausreißer wie ein altes Handy im Funkloch fallen so kaum ins Gewicht. Mobil und Desktop werden getrennt bewertet, mit denselben Grenzwerten. Eine Seite besteht die Prüfung nur, wenn alle drei Metriken gut sind.

LCP: Wann ist der Hauptinhalt sichtbar?

LCP misst die Zeit vom Start der Navigation, bis das größte Bild, Video oder der größte Textblock im sichtbaren Bereich gerendert ist. Im Shop ist das meist das Hero-Bild, das Kategoriebild oder das Hauptbild der Produktseite. Auf dem Handy kann es auch eine Überschrift sein oder ein Cookie-Hinweis mit viel Text.

INP: Wie schnell reagiert die Seite?

INP erfasst alle Klicks, Tipp-Gesten und Tastatureingaben während des gesamten Besuchs. Gemessen wird die Zeit ab der Eingabe bis zum nächsten gezeichneten Frame, also bis zur sichtbaren Reaktion. Sie setzt sich aus Eingabeverzögerung, Verarbeitung im Event-Handler und Darstellungsverzögerung zusammen. Als Wert gilt meist die langsamste Interaktion. Bei vielen Interaktionen wird pro 50 der höchste Ausreißer ignoriert. Scrollen und Hovern zählen nicht.

CLS: Bleibt das Layout ruhig?

CLS bewertet unerwartete Verschiebungen sichtbarer Elemente, gewichtet nach betroffener Fläche und zurückgelegter Strecke. Verschiebungen mit weniger als einer Sekunde Abstand bilden ein Fenster von höchstens fünf Sekunden. CLS ist der Wert des stärksten Fensters. Verschiebungen bis 500 ms nach einer Eingabe zählen nicht, ein aufklappendes Akkordeon ist also kein Problem. Animationen mit transform lösen keine Layoutverschiebung aus.

INP hat FID abgelöst

FID maß nur die Wartezeit, bis der Browser die erste Eingabe verarbeiten konnte. Die Verarbeitung selbst und jeder weitere Klick blieben außen vor. Seit dem 12. März 2024 ist INP das Core Web Vital für Reaktionsfähigkeit. Die Search Console hat FID am selben Tag entfernt, PageSpeed Insights und CrUX im September 2024 nach sechs Monaten Übergangsfrist. Die web-vitals-Bibliothek hat onFID() mit Version 5 im Mai 2025 gestrichen.

Wie wichtig sind Core Web Vitals für das Ranking?

Laut Google Search Central nutzen die Ranking-Systeme die Core Web Vitals, und Google empfiehlt gute Werte. Ein einzelnes Signal für die Seitenerfahrung gibt es aber nicht. Grundlage sind Felddaten: Laut Chrome-Dokumentation nutzt die Google-Suche die CrUX-Daten für den Rankingfaktor Seitenerfahrung.

Die Gewichtung beschreibt Google selbst. Die Suche zeigt immer den relevantesten Inhalt, auch bei schwacher Seitenerfahrung. Gibt es viele hilfreiche Seiten zu einer Anfrage, kann eine gute Seitenerfahrung zum Erfolg beitragen. Heißt: Guter Inhalt schlägt schnelle Ladezeit. Bei ähnlicher Relevanz kann die Ladezeit entscheiden.

Im E-Commerce ist dieser Fall häufig, weil viele Händler dieselben Produkte anbieten. Gute Werte sind trotzdem keine Garantie für Top-Platzierungen, und Google hält es für wenig lohnend, nur für SEO einen perfekten Wert zu jagen. Core Web Vitals sind ein Baustein von SEO für Online-Shops, nicht das Fundament. Relevante Kategorien, gute Produkttexte und eine saubere Indexierung kommen zuerst.

Messen: Felddaten gegen Labordaten

Felddaten stammen von echten Besuchern. Die wichtigste Quelle ist der Chrome User Experience Report (CrUX) mit anonymisierten Messwerten von Chrome-Nutzern auf Desktop und Android. Chrome auf dem iPhone und Safari fehlen. CrUX fasst die letzten 28 Tage zusammen und wird täglich aktualisiert. Seiten erscheinen nur, wenn sie öffentlich sind und genug Besucher haben.

Labordaten entstehen in einer Simulation. Lighthouse lädt die Seite einmal auf einem simulierten Mittelklasse-Handy mit gedrosselter Verbindung. Aber Lighthouse klickt nicht wie ein Kunde: INP misst es beim Laden nicht und zeigt stattdessen die Total Blocking Time (TBT) als Näherung. CLS erfasst es nur während des Ladens.

Liegen beide vor, priorisierst du nach den Felddaten und suchst die Ursache mit den Labordaten.

PageSpeed Insights

PageSpeed Insights zeigt oben die CrUX-Felddaten der URL. Reichen die Daten nicht, weicht es auf die ganze Domain aus. Bestanden ist die Prüfung, wenn LCP, INP und CLS am 75. Perzentil gut sind. Fehlen nur INP-Daten, reichen gute Werte für LCP und CLS. Darunter folgen die Lighthouse-Labordaten mit Hinweisen zur Ursache.

Google Search Console

Der Core-Web-Vitals-Bericht nutzt ebenfalls CrUX. Er fasst ähnliche URLs zu Gruppen zusammen, etwa alle Produktseiten einer Vorlage. Jede Gruppe erhält den Status ihrer schlechtesten Metrik, getrennt für Mobil und Desktop. Es erscheinen nur indexierte URLs mit genug Daten. Nach einer Korrektur startest du eine Prüfung, dann beobachtet die Search Console 28 Tage lang die Felddaten.

Chrome DevTools

Im Performance-Bereich der DevTools siehst du LCP, CLS und INP live, während du die Seite bedienst, samt Liste aller Interaktionen und Layoutverschiebungen. CrUX-Daten kannst du direkt daneben einblenden. Aktiviere die Drosselung, sonst misst du deinen schnellen Rechner. So testest du INP: Filter anklicken, Variante wählen, in den Warenkorb legen.

Eigene Felddaten mit der web-vitals-Bibliothek

Viele kleinere Shops haben zu wenig Besucher für CrUX. Dann sammelst du Felddaten selbst, etwa mit der web-vitals-Bibliothek vom Chrome-Team. Sie misst LCP und INP in Chromium, Firefox und Safari, CLS nur in Chromium-Browsern.

import {onCLS, onINP, onLCP} from 'web-vitals';

function senden(metrik) {
  navigator.sendBeacon('/vitals', JSON.stringify({
    name: metrik.name,
    wert: metrik.value,
    seite: location.pathname
  }));
}

onCLS(senden);
onINP(senden);
onLCP(senden);

LCP verbessern: Tipps für Shops

Hero- und Produktbilder mit fetchpriority="high" statt lazy

Das LCP-Bild muss so früh wie möglich laden. Gib dem Hero-Bild der Startseite und dem ersten Produktbild fetchpriority="high". loading="lazy" ist dort tabu, denn es verzögert genau das wichtigste Bild. Manche Themes setzen lazy pauschal auf alle Bilder. Prüfe das im Quelltext.

<!-- LCP-Bild: hohe Priorität, kein Lazy Loading -->
<img src="/bilder/sneaker-800.webp" fetchpriority="high"
     width="800" height="800" alt="Sneaker Nordlicht in Weiß">

<!-- Bilder weiter unten: hier ist Lazy Loading richtig -->
<img src="/bilder/schnuersenkel-400.webp" loading="lazy"
     width="400" height="400" alt="Schnürsenkel in Grau">

Vergib die hohe Priorität nur an das Bild, das sehr wahrscheinlich das LCP-Element ist. Steckt das Hero-Bild als CSS-Hintergrund im Stylesheet, findet der Browser es spät. Dann hilft ein Preload mit hoher Priorität oder besser ein echtes <img>.

Richtige Bildgrößen mit srcset

Ein Handy braucht kein 2.000 Pixel breites Produktfoto. Mit srcset bietest du mehrere Größen an, mit sizes nennst du die Breite im Layout. Der Browser wählt die passende Datei.

<img src="/bilder/sneaker-800.webp"
     srcset="/bilder/sneaker-400.webp 400w,
             /bilder/sneaker-800.webp 800w,
             /bilder/sneaker-1200.webp 1200w"
     sizes="(max-width: 768px) 100vw, 50vw"
     width="800" height="800" fetchpriority="high"
     alt="Sneaker Nordlicht in Weiß">

Alle Varianten brauchen dasselbe Seitenverhältnis, sonst passen width und height nicht mehr.

WebP oder AVIF

WebP und AVIF sind bei vergleichbarer Qualität meist kleiner als JPEG oder PNG. Mit <picture> und <source type="image/avif"> bekommen Browser mit AVIF-Unterstützung AVIF, alle anderen WebP. Shopify liefert Bilder über ein eigenes Bild-CDN aus und nutzt dabei oft schon WebP. Dort liegt der Hebel eher bei passenden Bildgrößen im Theme.

Server-Antwortzeit

Vor jedem Bild steht das HTML. web.dev empfiehlt eine Time to First Byte (TTFB) von höchstens 0,8 Sekunden. Hebel sind Seiten-Cache, CDN, schnelle Datenbankabfragen und wenige Weiterleitungen. Bei Shopware lohnt ein Blick auf den HTTP-Cache: Laut Dokumentation liefert Shopware standardmäßig keine komplett gecachten Seiten mehr aus, sobald ein Kunde eingeloggt ist oder etwas im Warenkorb liegt. Ausgerechnet kaufbereite Besucher bekommen dann langsamere Seiten.

Schriften vorladen

Ist eine Überschrift das LCP-Element, wartet sie oft auf die Webschrift. Lade die wichtigste Schrift vor, mit <link rel="preload" href="/fonts/marke.woff2" as="font" type="font/woff2" crossorigin>. Ohne crossorigin lädt der Browser die Datei doppelt. Lade höchstens ein oder zwei Schnitte vor, denn jede Datei konkurriert mit dem LCP-Bild um Bandbreite. WOFF2 auf dem eigenen Server spart eine fremde Verbindung.

INP verbessern: Tipps für Shops

Der Browser arbeitet JavaScript auf einem einzigen Hauptthread ab. Läuft gerade ein Tracking-Skript, wartet dein Klick auf „In den Warenkorb“. Shopify schreibt in seiner Hilfe: Schlechte INP-Werte deuten meist auf zu viel JavaScript aus Theme, Apps oder Tag Manager hin.

Drittanbieter-Skripte: Chat, Tracking, Cookie-Banner

Chat-Widgets, Tracking-Pixel, Bewertungs-Widgets und Consent-Tools laden große Skripte. Räum den Tag Manager auf und entferne, was niemand auswertet. Für Chat-Widgets eignet sich eine Fassade: Die Seite zeigt nur einen statischen Button, das echte Widget lädt beim ersten Klick. Beim Cookie-Banner startet „Alle akzeptieren“ oft alle Tracking-Skripte auf einmal und kann genau diesen Klick langsam machen. Frag deinen Anbieter, ob er die Arbeit danach aufteilt. Und bei Shopify gilt: Eine deinstallierte App entfernt ihren Code nicht automatisch aus dem Theme.

Große JavaScript-Bundles bei Filtern und Varianten

Oft rendert ein Klick auf „Größe 42“ die komplette Produktsektion neu, oder ein Filter baut ein Raster mit 100 Produkten auf einmal auf. Besser ist:

• nur Preis, Verfügbarkeit und Bild aktualisieren statt der ganzen Sektion
• Code für Filter und Varianten erst laden, wenn er gebraucht wird
• paginieren, denn ein großer DOM bremst jedes Neuzeichnen
• bei Suchfeldern und Preisschiebern erst rechnen, wenn die Eingabe kurz ruht

Lange Aufgaben aufteilen, Event-Handler schlank halten

Aufgaben über 50 Millisekunden gelten als lang. Solange sie laufen, reagiert der Browser nicht. Teile die Arbeit deshalb auf und gib zwischendurch an den Browser ab. Dafür gibt es scheduler.yield() in Chrome und Edge ab Version 129 und Firefox ab 142. Safari fehlt noch, deshalb braucht es einen Rückfall mit setTimeout.

function anBrowserAbgeben() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

button.addEventListener('click', async () => {
  button.disabled = true;              // 1. sofort sichtbares Feedback
  button.textContent = 'Wird hinzugefügt';
  await anBrowserAbgeben();            // 2. Browser zeichnen lassen
  await legeInWarenkorb(produktId);    // 3. der Rest danach
  await anBrowserAbgeben();
  sendeTracking('add_to_cart', produktId);
});

Das Prinzip: Ein Handler erledigt zuerst nur, was der Besucher sofort sehen muss. Anfrage, Tracking und Empfehlungen folgen in eigenen Aufgaben. Vermeide außerdem, Styles zu ändern und direkt danach Maße wie offsetHeight auszulesen. Das erzwingt eine sofortige Layout-Berechnung.

CLS verbessern: Tipps für Shops

width und height an Bildern

Ohne Größenangaben kennt der Browser den Platzbedarf eines Bildes nicht. Der Text rutscht nach unten, sobald das Bild da ist. Mit width und height reserviert der Browser den Platz vorab, height: auto hält das Bild responsiv.

<img src="/bilder/sommer-800.webp" width="800" height="450"
     alt="Sommerkollektion mit Leinenhemden">

/* im Stylesheet */
img { max-width: 100%; height: auto; }

Das gilt auch für Logos, Siegel, Zahlungs-Icons und Videos. Wo feste Maße fehlen, hilft aspect-ratio im CSS.

Platz für Banner und Cookie-Hinweise reservieren

Eine Aktionsleiste „Gratis Versand ab 50 Euro“, die per JavaScript über dem Header erscheint, schiebt die ganze Seite nach unten. Reserviere ihren Platz mit min-height oder gib sie direkt im HTML aus. Cookie-Hinweise gehören nicht oben in den Seitenfluss. Als Overlay mit position: fixed am unteren Rand oder als Dialog verschieben sie nichts.

Schriften mit font-display und passenden Fallbacks

Lädt die Webschrift nach dem Text, tauscht der Browser die Schrift. Hat die Ersatzschrift andere Maße, springen die Zeilen. font-display: swap zeigt sofort die Ersatzschrift und tauscht später. font-display: optional wartet höchstens etwa 100 ms und verzichtet sonst auf den Tausch. Mit size-adjust gleichst du die Ersatzschrift an die Webschrift an.

@font-face {
  font-family: "Marke";
  src: url("/fonts/marke.woff2") format("woff2");
  font-display: swap;
}
@font-face {
  font-family: "Marke Fallback";
  src: local("Arial");
  size-adjust: 104%;     /* Beispielwert, für deine Schrift berechnen */
  ascent-override: 92%;
}
body { font-family: "Marke", "Marke Fallback", sans-serif; }

Nachladende Produktempfehlungen

„Das könnte dir auch gefallen“, Bewertungssterne oder Cross-Selling im Warenkorb kommen oft per JavaScript nach. Landen sie im sichtbaren Bereich, schieben sie Beschreibung und Kaufbutton weg. Gib dem Container eine passende Mindesthöhe oder einen Platzhalter in Endgröße. Was unterhalb des sichtbaren Bereichs dazukommt, verschiebt nichts. Platziere solche Blöcke deshalb möglichst weiter unten.

Shopify und Shopware: Themes, Apps und Plugins

Oft liegt die Ursache nicht im Shopsystem, sondern in dem, was darauf läuft. Shopify nennt drei Hauptfaktoren: das Theme, die installierten Apps und zusätzlichen Code von Drittanbietern wie Tag Manager. Halte das Theme aktuell, begrenze die Zahl der Sektionen pro Vorlage und paginiere große Kollektionen. Prüfe jede App: Bringt sie mehr, als sie an Ladezeit kostet?

Für Shopware beschreibt die Dokumentation ein klares Vorgehen auf einem Testsystem: alle Erweiterungen von Drittanbietern deaktivieren, das Standard-Theme zuweisen, Cache leeren und aufwärmen, messen. Wird es schneller, schaltest du Plugins und Theme Schritt für Schritt wieder zu.

Praxisbeispiel: seorado.de von WordPress auf statisch

Im September 2026 habe ich seorado.de von WordPress mit Seitenbaukasten auf eine statische Seite umgebaut. Vorher liefen Skripte von WonderPush für Push-Nachrichten und Brevo für den Newsletter mit. Gemessen habe ich mit Lighthouse, mobil, alte gegen neue Startseite.

Der LCP lag vorher mit 3,3 Sekunden im Bereich „verbesserungswürdig“ und liegt jetzt klar unter 2,5 Sekunden. Der Speed Index zeigt, wie schnell Inhalte beim Laden sichtbar werden. Er fiel von 6,2 auf 1,7 Sekunden.

Der CLS-Fehler mit dem Titelbild

Auch die neue Seite war nicht sofort fehlerfrei. Ein Titelbild ohne Höhenangabe verursachte einen CLS von 0,198, also „verbesserungswürdig“. Mit width und height am Bild und einer kleineren Bildvariante für Handys fiel der CLS auf 0. Nebenbei sank das Seitengewicht eines Beitrags auf dem Handy von 238 KB auf 102 KB.

Zur Einordnung: Das sind Labordaten aus Lighthouse. Felddaten aus CrUX gibt es für die neue Seite noch nicht, sie erscheinen erst mit genug Besuchen. Die ganze Geschichte steht in der Referenz zu seorado.de. Wenn du einen Umbau planst, lies vorher den Beitrag zum SEO-Website-Relaunch. Dieselbe Technik steckt im Angebot für Websites und Landingpages.

So gehst du in deinem Shop vor

1. In der Search Console mit Mobil starten und schwache URL-Gruppen samt bremsender Metrik notieren.
2. Je Gruppe eine Beispiel-URL in PageSpeed Insights prüfen und INP-Probleme in den DevTools nachstellen.
3. Die Vorlage korrigieren, auf einer Staging-Umgebung testen und in der Search Console die Prüfung starten.

Wenn du wissen willst, wo dein Shop steht: Der kostenlose Shop-Check prüft neben Rankings und KI-Sichtbarkeit auch die Technik, darunter die Core Web Vitals.

Häufige Fragen

Ist FID noch relevant?

Nein. INP hat FID am 12. März 2024 als Core Web Vital abgelöst. Search Console, PageSpeed Insights und CrUX zeigen FID nicht mehr. Optimiere auf INP.

Warum weichen PageSpeed Insights und Search Console voneinander ab?

PageSpeed Insights zeigt Felddaten einer URL oder der ganzen Domain, die Search Console Werte für Gruppen ähnlicher URLs. Die Labordaten stammen aus einem einzigen simulierten Ladevorgang und weichen fast immer ab.

Wie lange dauert es, bis Verbesserungen sichtbar sind?

Lighthouse zeigt sie sofort. CrUX fasst 28 Tage zusammen. Der Effekt wächst deshalb Tag für Tag und ist nach etwa vier Wochen vollständig in den Felddaten enthalten.

Sind 100 Punkte in Lighthouse nötig?

Nein. Ziel sind gute Felddaten am 75. Perzentil: LCP bis 2,5 s, INP bis 200 ms, CLS bis 0,1. Google hält es für wenig lohnend, nur für SEO einen perfekten Wert zu jagen.

Was tun, wenn die Search Console keine Daten zeigt?

Dann hat deine Seite zu wenige Besuche in CrUX, oder die Property ist neu. Teste mit PageSpeed Insights und Lighthouse und sammle eigene Felddaten mit der web-vitals-Bibliothek. Bei Shopify helfen die Web-Performance-Berichte im Admin.