Core Web Vitals im Onlineshop: LCP, INP und CLS verstehen und verbessern

Die Core Web Vitals sind drei Messwerte, mit denen Google die Nutzererfahrung einer Seite bewertet: LCP für die Ladezeit, INP für die Reaktion auf Klicks und CLS für die Stabilität des Layouts. Als gut gelten laut Google ein LCP bis 2,5 Sekunden, ein INP bis 200 Millisekunden und ein CLS bis 0,1 — jeweils am 75. Perzentil echter Seitenaufrufe.

Zur Einordnung: Alle Schwellenwerte, Daten und Zitate in diesem Beitrag stammen aus der Dokumentation von Google (Google Search Central, web.dev, Chrome for Developers) und Shopify und wurden am 25. September 2026 geprüft. Wir nennen bewusst keine Prozentzahlen, um die bessere Werte Umsatz oder Conversion-Rate steigern — eine übertragbare Zahl dafür gibt es nicht. Wo wir aus eigenen Projekten berichten, steht das dabei.

1. Die drei Werte und ihre Schwellen

Google fasst drei Fragen zusammen, die jeder Besucher stellt: Ist die Seite da? Reagiert sie, wenn ich klicke? Bleibt sie ruhig, während ich lese? Für jede Frage gibt es einen Messwert und eine Grenze (Quelle: Google Search Central, Core Web Vitals, abgerufen am 25. September 2026).

Zwischen „gut" und „schlecht" liegt ein mittlerer Bereich, den die Search Console „Optimierung erforderlich" nennt. Die Grenzen für „schlecht" stammen aus der Herleitung auf web.dev (Quelle: web.dev, Defining the Core Web Vitals metrics thresholds, abgerufen am 25. September 2026).

Entscheidend ist, wessen Erlebnis zählt. Google bewertet das 75. Perzentil aller Aufrufe, getrennt nach Mobil und Desktop. Mindestens drei von vier Aufrufen müssen die Grenze also einhalten, und zwar bei allen drei Werten (Quelle: web.dev, Web Vitals, abgerufen am 25. September 2026).

Die Grenzen sind für Smartphone und Desktop identisch. Google hat sie an dem ausgerichtet, was mobil erreichbar ist. Einen Rabatt für Mobilgeräte gibt es also nicht — und dort kaufen viele Ihrer Kunden.

2. INP statt FID: was sich im März 2024 geändert hat

Bis Anfang 2024 hieß der dritte Wert First Input Delay (FID). Am 12. März 2024 hat Interaction to Next Paint (INP) ihn abgelöst (Quelle: web.dev, Interaction to Next Paint is officially a Core Web Vital, abgerufen am 25. September 2026). Ein Bericht, der heute noch FID zeigt, ist veraltet.

FID maß nur die Wartezeit bei der ersten Interaktion. INP beobachtet alle Klicks, Tipps und Tastendrücke eines Besuchs und misst bis zur nächsten sichtbaren Reaktion. Gemeldet wird die langsamste Interaktion; bei sehr vielen ignoriert Google je 50 die langsamste (Quelle: web.dev, Interaction to Next Paint, abgerufen am 25. September 2026). Hovern und Scrollen zählen nicht.

Für Shops ist das ein großer Schritt. Wer beim ersten Klick flott war und beim fünften Filterklick hängt, sah unter FID gut aus — unter INP nicht mehr. Der neue Wert schaut genau dorthin, wo Kunden arbeiten: Filter, Varianten, Warenkorb.

Lighthouse kann INP nicht messen, weil im Labor niemand klickt. Dort dient die Total Blocking Time als Ersatz. Belegen lässt sich INP nur mit echten Interaktionen.

3. Wie stark zählen die Core Web Vitals im Ranking?

Zwei Extreme kursieren: „Ohne grüne Werte kein Ranking" und „Das interessiert Google nicht". Beides stimmt nicht. Google antwortet in der eigenen Dokumentation klar (Quelle: Google Search Central, Nutzerfreundlichkeit von Seiten, Seitenstand 24. September 2026, abgerufen am 25. September 2026):

• Sie zählen: „Core Web Vitals werden von unseren Rankingsystemen genutzt."
• Sie sind nicht alles: „Es gibt kein einzelnes Signal."
• Sie garantieren nichts: Gute Werte „können nicht garantieren, dass deine Seiten ganz oben in den Google-Suchergebnissen angezeigt werden".
• Relevanz geht vor: Google zeigt die relevantesten Inhalte, auch bei schwacher Nutzerfreundlichkeit. Gibt es viele hilfreiche Treffer, kann eine gute Nutzerfreundlichkeit zum Erfolg beitragen.

Bewertet wird „in der Regel seitenspezifisch". Welche Daten zählen, sagt die Chrome-Dokumentation: Der Chrome User Experience Report, kurz CrUX, fließt in den Rankingfaktor Nutzerfreundlichkeit ein (Quelle: Chrome for Developers, Overview of CrUX, abgerufen am 25. September 2026). Das sind Felddaten echter Besucher, nicht die Punktzahl eines Testtools.

Unsere Einordnung: Die Werte entscheiden selten allein über eine Position. Sie zählen dort, wo mehrere Shops mit ähnlichem Sortiment um dieselben Suchen konkurrieren. Das stärkere Argument ist der Kunde: Ein Button, der beim Tippen wegspringt, kostet Vertrauen. Google selbst rät, nicht der SEO wegen einem perfekten Wert hinterherzulaufen.

Prozentzahlen aus Fallstudien anderer Unternehmen übertragen wir nicht auf Ihren Shop. Wie Ladezeit ins Shopify-SEO passt, zeigt unser Beitrag zu Shopify SEO mit Onpage, Technik und Schema. Im Relaunch gehört der Check in den Staging-Test, den der Leitfaden zum SEO-sicheren Website-Relaunch beschreibt.

4. Feld und Labor: warum PageSpeed und Search Console abweichen

Eine Frage hören wir in Shop-Projekten immer wieder: „PageSpeed zeigt über 90 Punkte, die Search Console meldet ‚Optimierung erforderlich'. Was stimmt?" Beides — es wird Verschiedenes gemessen.

Felddaten stammen von echten Chrome-Nutzern mit ihren Geräten, Netzen und Klicks, gesammelt über 28 Tage. Labordaten entstehen in einem einzigen simulierten Aufruf; mobil simuliert PageSpeed Insights ein Mittelklasse-Gerät im Mobilfunknetz (Quelle: PageSpeed Insights, About, abgerufen am 25. September 2026). Die Punktzahl von 0 bis 100 ist ein Laborwert. Ab 90 gilt sie als gut, ein Core Web Vital ist sie nicht.

Warum die Werte abweichen, erklärt web.dev: Das LCP-Element hängt im Feld von Bildschirm und Personalisierung ab. Der Labor-CLS sieht nur die Ladephase, der Feld-CLS auch das Scrollen. Und im Feld liegt vieles schon im Cache (Quelle: web.dev, Why lab and field data can be different, abgerufen am 25. September 2026). Die Regel lautet: nach Felddaten priorisieren, mit Labordaten die Ursache suchen.

Wie ernst diese Trennung ist, haben wir beim Relaunch von yagemi.de selbst erlebt. Lighthouse meldete mobil einen CLS von 0,231, klar im schlechten Bereich. Die Gegenmessung der echten Verschiebungen im Browser, auch mit gedrosselter CPU und beim Scrollen, ergab 0,000. Seither prüfen wir auffällige Laborwerte gegen die echte Messung, bevor wir etwas umbauen.

Zwei Lücken treffen Shops besonders. Im Chrome-Bericht stehen nur öffentlich auffindbare Seiten mit genug Besuchern; die Mindestzahl nennt Google nicht. Stehen etwa Warenkorb oder Checkout bei Ihnen auf noindex, fehlen sie auf Seitenebene, zählen aber zum Wert der ganzen Website (Quelle: Chrome for Developers, CrUX methodology, abgerufen am 25. September 2026). Kleine Shops haben oft gar keine Felddaten. Wie Sie den Bericht einrichten und lesen, steht im Beitrag zur Google Search Console.

5. Das Consent-Paradox: was das Labor im Shop nicht sieht

In Deutschland dürfen Marketing- und Analyse-Skripte in aller Regel erst nach Einwilligung laden. Die Pflichten dahinter erklärt unser Beitrag zum rechtssicheren Cookie-Banner. Für die Messung hat das eine Nebenwirkung.

Laut web.dev messen die meisten synthetischen Tools ohne eigene Einstellung nur einen Erstbesucher, der auf den Consent-Hinweis noch nicht reagiert hat (Quelle: web.dev, Best practices for cookie notices, abgerufen am 25. September 2026). Alles, was nach „Akzeptieren" lädt, fehlt im Labortest. Das Labor misst die leichteste Version Ihres Shops, die Felddaten die schwere.

Das erklärt einen Widerspruch, den viele Händler kennen: gute Punktzahl in PageSpeed, gelbe Gruppen in der Search Console. Der Banner selbst wirkt zusätzlich auf alle drei Werte:

• INP: Laut web.dev ist der Button „Akzeptieren" oft eine besondere Ursache für schlechte INP-Werte, weil der Klick viele Skripte auf einmal startet.
• CLS: Ein Banner, der oben eingefügt wird, schiebt alles darunter nach unten. Consent-Hinweise sind laut web.dev eine sehr häufige Quelle für Verschiebungen.
• LCP: Auf dem Smartphone nimmt der Hinweis viel Fläche ein. Mit einem großen Textblock kann er selbst zum LCP-Element werden.

Was hilft: das Consent-Skript direkt im HTML und asynchron laden, nicht über einen Tag Manager; den Hinweis als Overlay unten oder als Dialog zeigen; beim Anbieter fragen, ob er die Arbeit nach „Akzeptieren" aufteilt; im Labor beide Zustände testen. Weniger Skripte im Browser bringt auch Server-Side-Tracking — eine Einwilligung ersetzt es nicht.

6. Seitentyp für Seitentyp: wo Shops Zeit verlieren

Die Search Console sortiert URLs in Gruppen mit ähnlicher Nutzererfahrung. Google nimmt an, dass diese Seiten „ein gemeinsames Framework haben" und dieselbe Ursache teilen (Quelle: Search-Console-Hilfe, Core Web Vitals-Bericht, abgerufen am 25. September 2026). Im Shop heißt das: Vorlagen. Eine Korrektur an der Produktvorlage wirkt auf jede Produkt-URL.

Die Übersicht zeigt, wo die Werte je Seitentyp typischerweise hängen. Sie beruht auf unseren Shop-Analysen und ist eine Suchhilfe, keine Messung.

Das gilt für JTL-Shop, Shopify und Shopware gleichermaßen: Die Bremsen sitzen seltener im System selbst als in dem, was darauf läuft — Vorlage, Erweiterungen, Tracking. Shopify zeigt die Werte im Admin sogar nach Seitentyp und markiert, wann eine App installiert oder das Theme geändert wurde (Quelle: Shopify Help Center, Web performance reports, abgerufen am 25. September 2026).

7. LCP im Shop: erst das Produktbild, dann der Server

Auf Produkt- und Kategorieseiten ist das LCP-Element meist ein Bild. web.dev zerlegt den LCP in vier Teilzeiten, die zusammen genau den LCP ergeben (Quelle: web.dev, Optimize Largest Contentful Paint, abgerufen am 25. September 2026). Die beiden Verzögerungen sollten nahe null liegen.

Die Anteile sind Richtwerte. Sie zeigen aber, warum ein kleineres Bild allein manchmal nichts bringt: Blendet ein Skript das Bild erst ein, wandert die gesparte Zeit nur in die Renderverzögerung. Galerie-Slider auf Produktseiten sind dafür ein klassisches Beispiel. Für das Produktbild gelten vier Regeln aus der Google-Dokumentation:

• Im HTML auffindbar. Das erste Galeriebild muss im ausgelieferten HTML stehen, nicht erst im Skript des Sliders.
• Nie verzögert laden. web.dev warnt, das LCP-Bild nie mit loading="lazy" zu versehen. Erweiterungen, die alle Bilder verzögern, treffen auch das erste.
• Hohe Priorität, aber sparsam. fetchpriority="high" gehört an das eine wahrscheinliche LCP-Bild. Bei mehr als ein oder zwei Bildern hilft die Angabe laut web.dev nicht mehr.
• Passende Größe, modernes Format. Mit srcset und sizes lädt das Smartphone eine kleinere Datei; WebP oder AVIF verkürzen die Übertragung.

Bleibt der Server. Die Time to First Byte ist kein Core Web Vital, steckt aber in jedem LCP. web.dev nennt als groben Richtwert höchstens 0,8 Sekunden (Quelle: web.dev, Time to First Byte, abgerufen am 25. September 2026). Zwei Ursachen aus dem LCP-Leitfaden treffen Shops mit Werbetraffic: Weiterleitungsketten aus Anzeigen oder Kurzlinks und Seiten, die ein CDN nicht aus dem Cache liefert, weil Analyse-Parameter jede URL einzigartig machen. Mehr dazu in CDN erklärt und im Webhosting-Vergleich für Unternehmen. Bei Shopify liegt das Hosting beim Anbieter; dort sind Theme und Apps die Hebel.

8. INP im Shop: Filter, Varianten und der Warenkorb-Button

Eine Interaktion hat drei Phasen: die Eingabeverzögerung, bis der Browser reagieren kann, die Verarbeitung durch Skripte und die Darstellung des Ergebnisses (Quelle: web.dev, Optimize Interaction to Next Paint, abgerufen am 25. September 2026).

Im Shop hat jede Phase einen Gegenspieler. Beim Laden blockieren viele Skripte den Hauptthread; jede Aufgabe über 50 Millisekunden gilt als lang. Am Warenkorb-Button hängen mehrere Tracking-Ereignisse. Und nach einem Filterklick wird eine lange Liste neu aufgebaut. Diese Hebel wirken:

• Ballast entfernen. Jede App, jedes Plugin und jeder Tag bringt Skripte mit. Laut Shopify kann jede zusätzliche Funktion die Performance beeinflussen. Löschen Sie, was niemand mehr nutzt, auch Testreste und doppelte Pixel.
• Fremde Skripte asynchron laden. Skripte von Drittanbietern gehören mit async oder defer eingebunden, damit sie den Aufbau der Seite nicht anhalten. So empfiehlt es web.dev.
• Widgets erst bei Bedarf laden. Chat, Video oder Bewertungsmodul müssen nicht beim Seitenaufruf starten. Ein leichter Platzhalter reicht, bis jemand darauf klickt.
• Erst reagieren, dann messen. Beim Klick auf „In den Warenkorb" zählt zuerst die sichtbare Antwort. Tracking-Ereignisse können in einer späteren Aufgabe folgen. web.dev nennt das yielding, also die Rückgabe an den Hauptthread.
• Produktlisten klein halten. Nach einem Filterklick baut der Browser die Liste neu auf. Je mehr Kacheln, desto länger dauert das. Seitenweise Listen oder ein Button „Mehr laden" halten die Seite leicht.

Welche Erweiterungen ein Shopify-Shop in Deutschland wirklich braucht, ordnet unser Beitrag zu Shopify-Apps für deutsche Shops ein. Für den Tag Manager gilt dasselbe: Jeder Tag im Browser konkurriert mit dem Klick Ihres Kunden. Wie Sie Tags an Einwilligungen koppeln, zeigt der Beitrag Google Tag Manager einrichten.

9. CLS im Shop: Banner, Sterne und nachladende Listen

CLS misst Verschiebungen, mit denen niemand rechnet. Verschiebungen bis 500 Millisekunden nach einer Eingabe zählen nicht. Mehrere kurz hintereinander bündelt Google zu einem Fenster von höchstens fünf Sekunden; gewertet wird das schlechteste (Quelle: web.dev, Cumulative Layout Shift, abgerufen am 25. September 2026).

Im Shop sind die Verursacher fast immer Inhalte, die später kommen als der Rest. Die Hebel stammen aus dem CLS-Leitfaden von web.dev (Quelle: web.dev, Optimize Cumulative Layout Shift, abgerufen am 25. September 2026):

• Jedes Bild mit Breite und Höhe. Mit width und height reserviert der Browser den Platz, bevor das Bild da ist. Das gilt für Produktkacheln wie für Logos von Zahlarten.
• Platz für Nachzügler reservieren. Bewertungssterne, Ratenkauf-Hinweise und Lieferzeiten erscheinen oft später. Geben Sie ihrem Container eine Mindesthöhe, auch wenn das Modul einmal leer bleibt.
• Banner als Overlay. Eine Aktionsleiste, die oben nachträglich erscheint, schiebt die ganze Seite nach unten. Ein Overlay am unteren Rand verschiebt nichts.
• Nachladen per Klick. Verschiebungen bis 500 Millisekunden nach einer Eingabe zählen nicht. Ein Button „Mehr laden" ist daher stabiler als Kacheln, die beim Scrollen einfließen.
• Schriften und Animationen. Laden Sie die wichtigste Schrift früh vor und nennen Sie eine passende Ersatzschrift. Bewegen Sie Elemente mit transform, nicht mit top oder left.

Oft übersehen wird der Back/Forward-Cache. Er hält eine Seite kurz im Speicher, sodass sie beim Zurückspringen ohne Verschiebung erscheint. web.dev nennt die Rückkehr zur Kategorieseite als typischen Fall — im Shop der Weg vom Produkt zurück in die Liste. Ob Ihre Seiten dafür taugen, testen die Chrome-Entwicklertools.

Und: Der Labor-CLS sieht nur die Ladephase. Kacheln ohne Maße, die beim Scrollen nachladen, fallen nur in den Felddaten auf.

10. So setzen wir es auf yagemi.de um

Diese Seite ist kein Shop. Die Muster lassen sich aber auf jede Shop-Vorlage übertragen. So gehen wir auf yagemi.de vor:

• Das LCP-Bild steht im HTML. Das Titelbild jedes Blogbeitrags trägt loading="eager" und fetchpriority="high". Kein Skript muss es einsetzen, und kein anderes Bild der Seite hat diese Priorität.
• Der Preload nennt dieselben Größen. Im Kopf der Seite wird das Bild mit imagesrcset und imagesizes vorgeladen, exakt wie am Bild selbst. So lädt der Browser früh genau die Datei, die er anzeigt.
• Zwei Bildbreiten, feste Maße. Jedes Titelbild eines Blogbeitrags liegt als WebP in 1.024 und 640 Pixel Breite vor, mit Breite und Höhe im HTML.
• Variable Schriften vom eigenen Server. Beide Schriften liegen als variable WOFF2-Dateien vor. Eine Datei deckt alle Stärken ab. Die zwei Dateien für den lateinischen Grundzeichensatz werden vorgeladen, mit font-display: swap.
• Drittanbieter erst bei Bedarf. Der Livechat lädt erst beim Klick. Der Buchungskalender lädt, sobald jemand einen Buchungs-Button mit Maus, Finger oder Tastatur ansteuert.
• Budgets vor der Freigabe. Neue Seiten müssen feste Grenzen einhalten: LCP unter 2,5 Sekunden, CLS unter 0,1, INP unter 200 Millisekunden. Sonst gehen sie erst live, wenn die Ursache geklärt ist.

Eine ehrliche Anmerkung: Selbst gehostete Schriften sind laut web.dev nicht automatisch schneller; der Vorteil stellt sich nur mit CDN und HTTP/2 zuverlässig ein (Quelle: web.dev, Best practices for fonts, abgerufen am 25. September 2026). Und unsere Werte gelten für unsere Seite. Ein Shop mit Tausenden Produktbildern hat andere Engpässe, die Reihenfolge der Arbeit bleibt dieselbe.

11. In fünf Schritten zu besseren Werten

Viele Shops drehen an einzelnen URLs oder jagen einer Laborpunktzahl hinterher. Diese Reihenfolge kommt schneller in den Felddaten an:

1. Felddaten holen, mobil zuerst: Notieren Sie im Core-Web-Vitals-Bericht der Search Console, welcher Wert bei welcher URL-Gruppe auffällt. Bei Shopify kommen die Berichte nach Seitentyp dazu.
2. Vorlage statt Einzel-URL: Beginnen Sie mit der Gruppe, die den meisten Umsatz trägt. Öffnen Sie eine typische URL daraus in PageSpeed Insights und in den Chrome-Entwicklertools.
3. Beide Consent-Zustände testen: Messen Sie einmal ohne Reaktion auf den Banner und einmal nach „Akzeptieren". Erst der zweite Lauf zeigt, was Ihre Skripte kosten.
4. Ursache in der Vorlage beheben: Zerlegen Sie den LCP in seine Teilzeiten, suchen Sie lange Aufgaben und lassen Sie sich die Verschiebungen anzeigen. Ändern Sie die Vorlage, nicht die einzelne Seite.
5. Validieren und abwarten: Starten Sie in der Search Console die Prüfung. Sie läuft 28 Tage. Tritt das Problem dann auch nur bei einer URL auf, gilt es als nicht behoben.

Alle Schwellen und Aussagen zum Ranking wurden am 25. September 2026 an der Google-Dokumentation geprüft (Google Search Central, web.dev, öffnen in neuem Tab). Stabile Core Web Vitals ändert Google höchstens einmal im Jahr. Alle Quellen stehen am Ende des Beitrags.

12. Fazit: Felddaten lesen, Vorlagen reparieren

Die Core Web Vitals sind drei Werte mit drei Grenzen, bewertet am 75. Perzentil echter Besuche. Schwierig wird es im Shop an zwei Stellen: Welche Messung stimmt, und wo fängt man an?

Google empfiehlt, nach Felddaten zu priorisieren; das Labor dient der Diagnose. In Deutschland sieht der Labortest zudem die Skripte nach der Einwilligung nicht. Die Search Console gruppiert nach Vorlagen, also arbeiten Sie nach Vorlagen — zuerst dort, wo der Umsatz entsteht.

Beim Ranking hilft Nüchternheit: Google nutzt die Werte, stellt Relevanz aber darüber. Ein Shop, der schnell lädt, beim Tippen reagiert und nicht springt, gewinnt vor allem bei seinen Kunden.

13. Häufige Fragen zu Core Web Vitals

Was sind Core Web Vitals einfach erklärt?

Core Web Vitals sind drei Messwerte von Google für die Nutzererfahrung einer Seite. LCP misst, wann der größte sichtbare Inhalt geladen ist. INP misst, wie schnell die Seite auf Klicks und Eingaben reagiert. CLS misst, wie stark Inhalte unerwartet verrutschen. Bewertet wird am 75. Perzentil echter Besuche, getrennt nach Mobil und Desktop.

Welche Werte gelten bei den Core Web Vitals als gut?

Als gut gelten laut Google ein LCP bis 2,5 Sekunden, ein INP bis 200 Millisekunden und ein CLS bis 0,1. Schlecht ist ein LCP über 4 Sekunden, ein INP über 500 Millisekunden und ein CLS über 0,25. Eine Seite besteht die Prüfung, wenn alle drei Werte beim 75. Perzentil im guten Bereich liegen.

Wie kann man Core Web Vitals messen?

Echte Nutzerdaten zeigen der Core-Web-Vitals-Bericht der Google Search Console und der obere Teil von PageSpeed Insights, jeweils für die letzten 28 Tage. Für die Ursachensuche nutzen Sie Labordaten aus Lighthouse und den Chrome-Entwicklertools. Shopify-Händler finden zusätzlich eigene Web-Performance-Berichte im Admin, getrennt nach Seitentyp.

Sind Core Web Vitals ein Rankingfaktor?

Ja, aber kein dominanter. Google schreibt, dass die Rankingsysteme Core Web Vitals nutzen. Zugleich stellt Google klar, dass gute Werte keine Spitzenplätze garantieren und die Relevanz eines Inhalts Vorrang hat. Bessere Werte helfen vor allem dort, wo viele ähnlich hilfreiche Seiten konkurrieren. Den größeren Nutzen haben sie für Ihre Besucher.

Was ist der Unterschied zwischen INP und FID?

FID maß nur die Wartezeit bis zur Verarbeitung der ersten Interaktion auf einer Seite. INP beobachtet alle Klicks, Tipps und Tastendrücke eines Besuchs und misst bis zur nächsten sichtbaren Reaktion. Am 12. März 2024 hat INP den FID als Core Web Vital abgelöst. Berichte, die noch FID zeigen, sind veraltet.

Warum zeigt PageSpeed Insights andere Werte als die Search Console?

Weil zwei verschiedene Dinge gemessen werden. Die Punktzahl von PageSpeed Insights stammt aus einem einzigen simulierten Ladevorgang im Labor. Die Search Console zeigt Felddaten echter Chrome-Nutzer über 28 Tage und fasst ähnliche Seiten zu Gruppen zusammen. Im Shop kommt hinzu: Das Labor misst meist einen Besucher, der dem Cookie-Banner noch nicht zugestimmt hat.

Warum zeigt die Search Console keine Daten für meinen Shop?

Die Daten stammen aus dem Chrome User Experience Report. Dort erscheinen nur öffentlich auffindbare Seiten mit genügend Besuchern, die Mindestzahl legt Google nicht offen. Bei wenig Traffic fasst die Search Console Seiten zu einer Ursprungsgruppe zusammen oder zeigt gar nichts. Dann helfen eigene Messungen mit echten Nutzern oder bei Shopify die Berichte im Admin.

Wie lange dauert es, bis Verbesserungen sichtbar werden?

Felddaten beruhen auf den letzten 28 Tagen. Eine Verbesserung wirkt deshalb schrittweise, weil alte Aufrufe erst nach und nach aus dem Zeitraum fallen. Die Search Console überwacht nach einem Klick auf „Tracking starten" 28 Tage lang, ob ein Problem behoben ist. Im Labor sehen Sie die Wirkung sofort, in den Felddaten erst nach Wochen.

Bremst ein Cookie-Banner die Core Web Vitals?

Er kann alle drei Werte belasten. Ein Banner, das oben eingefügt wird, schiebt Inhalte nach unten und erhöht den CLS. Auf dem Smartphone kann ein textreicher Banner selbst zum LCP-Element werden. Und der Klick auf „Akzeptieren" startet oft viele Skripte auf einmal, was den INP verschlechtert. Ein Overlay am unteren Rand verschiebt nichts.

14. Quellen & offizielle Informationen

Alle Quellen wurden am 25. September 2026 abgerufen; die zitierten Aussagen wurden im abgerufenen Text gegengelesen. Externe Quellen öffnen in einem neuen Tab.

• Google Search Central — Core Web Vitals und Google-Suchergebnisse — Definition der drei Messwerte und Zielwerte für LCP, INP und CLS; Bezug zu den Ranking-Systemen (Google-Dokumentation, Seitenstand 18. Dezember 2025).
• Google Search Central — Nutzerfreundlichkeit von Seiten in den Google-Suchergebnissen — FAQ zur Rolle der Core Web Vitals im Ranking: genutzt, kein einzelnes Signal, keine Garantie, Relevanz geht vor (Google-Dokumentation, Seitenstand 24. September 2026).
• web.dev — Web Vitals — 75. Perzentil, Trennung nach Mobil und Desktop, Lebenszyklus der Messwerte, Werkzeuge für Feld- und Labormessung (Entwickler-Doku von Google).
• web.dev — Defining the Core Web Vitals metrics thresholds — Grenzen für „schlecht" und die Begründung, warum Mobil und Desktop dieselben Schwellen haben (Entwickler-Doku von Google).
• web.dev — Interaction to Next Paint is officially a Core Web Vital — Ablösung von FID durch INP am 12. März 2024 und Übergangsfrist bis 9. September 2024 (Ankündigung des Chrome-Teams).
• web.dev — Interaction to Next Paint (INP) — gemessene Interaktionen, Berechnung, drei Phasen einer Interaktion und Unterschied zu FID (Entwickler-Doku von Google).
• web.dev — Cumulative Layout Shift (CLS) — Sitzungsfenster, Ausnahme für Verschiebungen nach einer Eingabe, Schwellenwerte (Entwickler-Doku von Google).
• Search-Console-Hilfe — Core Web Vitals-Bericht — Felddaten aus CrUX, URL-Gruppen, Status nach dem schlechtesten Wert, 28-Tage-Überprüfung (Google-Hilfe).
• PageSpeed Insights — About — Feld- und Labordaten, 28-Tage-Zeitraum, Rückfall auf die gesamte Website, simulierte Gerätebedingungen, Bedeutung der Punktzahl (Google-Dokumentation).
• Chrome for Developers — Overview of CrUX — CrUX als Datengrundlage für den Rankingfaktor Nutzerfreundlichkeit (Chrome-Dokumentation).
• Chrome for Developers — CrUX methodology — Aufnahmekriterien: öffentlich auffindbar, ausreichend besucht; Umgang mit noindex-Seiten (Chrome-Dokumentation).
• web.dev — Why lab and field data can be different — Gründe für Abweichungen zwischen Labor und Feld und die Empfehlung, nach Felddaten zu priorisieren (Entwickler-Doku von Google).
• web.dev — Best practices for cookie notices — Wirkung von Consent-Hinweisen auf LCP, INP und CLS, Ladeempfehlungen und die Grenze synthetischer Messungen (Entwickler-Doku von Google).
• web.dev — Optimize Largest Contentful Paint — vier Teilzeiten mit Richtwerten, kein Lazy Loading für das LCP-Bild, fetchpriority, Weiterleitungen und CDN-Cache (Entwickler-Doku von Google).
• web.dev — Optimize Interaction to Next Paint — Eingabeverzögerung, Verarbeitung, Darstellung, Zurückgeben an den Hauptthread, DOM-Größe (Entwickler-Doku von Google).
• web.dev — Optimize long tasks — Definition einer langen Aufgabe ab 50 Millisekunden (Entwickler-Doku von Google).
• web.dev — Optimize Cumulative Layout Shift — Bildmaße, reservierter Platz, Overlays, Nachladen per Nutzeraktion, Animationen, Schriften, Back/Forward-Cache (Entwickler-Doku von Google).
• web.dev — Efficiently load third-party JavaScript — async und defer, verzögertes Laden, vorsichtiger Umgang mit Tag Managern (Entwickler-Doku von Google).
• web.dev — Best practices for fonts — Selbst-Hosting, WOFF2, Preload von Schriften (Entwickler-Doku von Google).
• web.dev — Time to First Byte (TTFB) — Richtwert von höchstens 0,8 Sekunden und Einordnung als Diagnosewert (Entwickler-Doku von Google).
• Shopify Help Center — Web performance reports — Berichte mit Echtnutzerdaten nach Seitentyp und URL, Ereignismarken, Verzug und Aufbewahrungsdauer (Hersteller-Doku).
• Shopify Help Center — Online store web performance — Hinweis, dass jede hinzugefügte Funktion wie Apps oder Analytics die Web-Performance beeinflussen kann (Hersteller-Doku).

Die Übersicht der Seitentypen in Abschnitt 6 beruht auf Erfahrungen aus unseren Shop-Analysen und ist eine Suchhilfe, keine Messung. Der CLS-Wert von 0,231 in Abschnitt 4 stammt aus einer Lighthouse-Messung unserer eigenen Seite während des Relaunchs; die Gegenmessung erfolgte mit der Layout-Shift-Schnittstelle des Browsers. Umsatz- oder Conversion-Effekte beziffern wir bewusst nicht.