Ladezeit und Core Web Vitals im Shop verbessern

Ein Beispiel: Der Labortest zeigt für die Startseite 1,8 Sekunden, im Feld warten Kunden auf dem Mobiltelefon spürbar länger. Der Unterschied entsteht durch Gerät, Netz, Cache und die Fremdskripte eines echten Besuchs. Der folgende Ablauf beginnt deshalb bei den Felddaten und setzt das Labor nur ein, um die Ursache zu finden.

Was Sie vorab brauchen

• eine in der Google Search Console bestätigte Property oder eine öffentlich erreichbare URL für PageSpeed Insights
• Chrome mit DevTools auf einem Testrechner
• eine Liste der eingebundenen Fremdskripte: Analyse, Werbung, Chat, Bewertungen, Karten, Videos, Testwerkzeuge
• Format, Abmessungen und Dateigröße der Bilder auf Start-, Kategorie- und Produktseiten
• Angaben zu Hosting und Auslieferung: Serverstandort, CDN, Cache-Regeln
• ein Messfenster von 28 Tagen, bevor Sie nach einer Änderung neu bewerten

Schritt 1: Feld und Labor trennen

Felddaten stammen von echten Besuchen, Labordaten aus einem festen Testaufbau mit vorgegebenem Gerät und Netz. Maßgeblich sind die Felddaten: Der Chrome UX Report (CrUX) sammelt anonyme Messwerte aus Chrome-Installationen, deren Nutzer die Nutzungsstatistik eingeschaltet und den Verlauf synchronisiert haben; Chrome unter iOS, WebView-Apps und andere Chromium-Browser liefern keine Daten. Eine Seite erscheint nur, wenn sie öffentlich auffindbar und häufig genug besucht ist; die Mindestzahl nennt Google nicht. CrUX-Daten nutzt Google Search für den Page-Experience-Faktor.

Die Feldwerte sind ein Mittel über die vergangenen 28 Tage; CrUX zeigt damit, dass ein Problem besteht, aber nicht, woran es liegt. Das Labor liefert die Ursache, ersetzt die Feldmessung aber nicht: Es prüft einen Besuch auf einem Gerät und einer Verbindung.

Schritt 2: Im Feld messen

Drei Wege führen zu Felddaten, ohne dass Sie selbst Code einbauen.

1. Der Core-Web-Vitals-Bericht der Search Console gruppiert ähnliche Seiten zu URL-Gruppen und trennt Mobil und Desktop. Der Status einer Gruppe richtet sich nach der schlechtesten Kennzahl; für die Aufnahme braucht sie Mindestdaten zu LCP und CLS, und es erscheinen nur indexierte URLs. Für den Status einer einzelnen URL ist der Bericht nicht gedacht.
2. PageSpeed Insights zeigt oben Felddaten, unten einen Labortest. Prüfen Sie, ob die Felddaten für die eine URL oder für die ganze Domain gelten.
3. Die Live-Metriken im Performance-Bereich der DevTools stellen lokale Werte neben die CrUX-Werte derselben Seite.

Erreicht Ihr Shop die Mindestzahl an Besuchen nicht, richten Sie eigenes Real-User-Monitoring ein. Google dokumentiert dafür eine JavaScript-Bibliothek, die die Kennzahlen nach derselben Methodik erhebt; speichern und auswerten müssen Sie die Werte selbst. Für den Vorher-nachher-Vergleich bleiben Quelle, Zeitraum und Gerät unverändert.

Schritt 3: Im Labor reproduzieren

Lighthouse prüft eine URL in einer kontrollierten Umgebung und berichtet LCP, CLS und Total Blocking Time. Im Standard läuft der Test mit simuliert gedrosselter Mobilverbindung: Das Profil entspricht dem unteren Viertel der 4G-Klasse, mit 150 Millisekunden Latenz und 1,6 Mbit/s im Download.

Total Blocking Time steht an der Stelle von INP, weil ein Test ohne Nutzereingaben INP nicht messen kann. Auch CLS kann im Labor niedriger ausfallen: Der Test lädt die Seite nur und erfasst keine Sprünge, die später beim Scrollen oder nach einer Einwilligung entstehen.

Beim LCP hilft die Aufteilung in vier Abschnitte: Antwortzeit des Servers, Verzögerung bis zum Ladestart der Bilddatei, Ladezeit der Datei und Verzögerung bis zur Darstellung. Nach den Richtwerten der Dokumentation entfallen auf einer gut optimierten Seite rund 40 Prozent auf den Server und rund 40 Prozent auf die Übertragung; beide Verzögerungen bleiben nahe null. Suchen Sie zuerst im Bericht das Element, das als LCP gezählt wird.

Schritt 4: LCP beheben

Prüfen Sie zuerst das Startbild. Setzt ein Slider-Skript das Bild erst ein, lädt es über data-src nach oder liegt es als CSS-Hintergrund vor, findet der Browser es im HTML nicht und beginnt später mit dem Download. Setzen Sie es als img mit src oder srcset direkt in das HTML, mindestens für den ersten Slide, und geben Sie genau diesem Bild fetchpriority hoch mit. Setzen Sie die hohe Priorität gezielt auf ein bis zwei Bilder; für mehr Bilder hilft sie nicht mehr, das LCP zu senken. loading=“lazy” gehört nicht an das Startbild.

Verkleinern Sie blockierendes CSS und JavaScript im Kopf der Seite: Ein Stylesheet, das länger lädt als die LCP-Datei, blockiert die Darstellung; verkleinern, aufteilen und komprimieren Sie es deshalb, und binden Sie nur ein kleines Stylesheet inline ein. Synchrone Skripte im Kopf sind fast nie nötig: Laden Sie Skripte asynchron oder verzögert, und binden Sie nur sehr kleine Skripte inline ein. Setzt Ihr Shopsystem die Seite erst im Browser zusammen, ist serverseitig erzeugtes HTML der wirksamere Weg. Für die Übertragung zählen passende Bildmaße, ein modernes Format und ein Cache; ein Bild-CDN auf derselben Domain erspart den zweiten Verbindungsaufbau. Gegen eine langsame Serverantwort helfen ein CDN, kurze Weiterleitungsketten und der Verzicht auf Messparameter, die an der Zwischenspeicherung vorbeiführen.

Schritt 5: INP verbessern

INP misst die Zeit von der Eingabe bis zum nächsten gezeichneten Bild, über alle Klicks, Tipps und Tastatureingaben; gemeldet wird die längste Interaktion, wobei pro 50 Interaktionen eine Spitze unberücksichtigt bleibt. Die gemessene Zeitspanne zerfällt in Eingabeverzögerung, Abarbeitung und Darstellungsverzögerung.

Suchen Sie die langsame Interaktion: Filter öffnen, Variante wählen, in den Warenkorb legen, Menge ändern. Diese Zuordnung liefert im Feld nur ein eigenes Monitoring; im Labor können Sie den Ablauf nachspielen und dabei auch während des Ladens klicken.

Long Tasks über 50 Millisekunden blockieren den Hauptthread und damit die Antwort. Teilen Sie solche Aufgaben: Erledigen Sie zuerst, was das nächste Bild zeigen muss, und verschieben Sie den Rest in eine neue Aufgabe. Ein DOM mit vielen Produktkacheln und Filtern kostet zusätzlich Darstellungszeit.

Der zweite Hebel sind Fremdskripte. Laden Sie sie nach den eigenen Inhalten und asynchron und prüfen Sie regelmäßig, welche Bibliothek wie viel Hauptthread-Zeit belegt. Bauen Sie keine sichtbaren Seitenelemente per Tag-Manager: Deren Auslieferung verzögert sich, eingefügte Elemente können das Layout verschieben. Beachten Sie auch die Minute nach einer Einwilligung: Starten mehrere Skripte erst dann, trifft ihre Arbeit auf die ersten Klicks.

Schritt 6: CLS beheben

CLS zählt unerwartete Positionswechsel sichtbarer Elemente. Als häufigste Ursachen nennt die Dokumentation Bilder ohne Maße, Werbeplätze und eingebettete Rahmen ohne Maße, nachträglich eingefügten Inhalt und Webfonts mit abweichenden Maßen.

Geben Sie Bildern und Videos width und height mit oder reservieren Sie den Platz per aspect-ratio; ist die Höhe unbekannt, hilft eine Mindesthöhe. Ein Einwilligungsbanner gehört mit reserviertem Platz in den Aufbau oder als feste Leiste über den Inhalt, sonst schiebt es nach dem ersten Rendern die Seite nach unten. Animieren Sie es über transform statt top oder left, auch bei absoluter Positionierung.

Nachgeladene Inhalte unterhalb des sichtbaren Bereichs bekommen ihren Platz, bevor sie laden. Bei automatisch wechselnden Slidern prüfen Sie die Übergänge: Eine Animation über Eigenschaften, die das Layout neu berechnen, kann dauerhaft Sprünge erzeugen. Webfonts verschieben Text, wenn die Schrift den Systemersatz erst nach dem Laden ersetzt und beide unterschiedlich breit laufen; eine sofort sichtbare Ersatzschrift, passende Zeichensätze und eine komprimierte Datei verringern das.

Sprünge innerhalb von 500 Millisekunden nach einem Klick, Tipp oder Tastendruck zählen nicht; Scrollen, Zeigen mit der Maus und Zoomen gelten nicht als Eingabe.

Messen und beheben im Überblick

Die Tabelle ordnet jeder Kennzahl ihre Grenzwerte, die Ursachen im Shop, den ersten Schritt und die Kontrolle zu. Die Grenzwerte gelten je Kennzahl am 75. Perzentil, getrennt für Mobil und Desktop.

Kennzahl	Grenzwerte: gut / verbesserungswürdig / schlecht	Ursache im Shop	Erste Maßnahme	Kontrolle
LCP	bis 2,5 s / bis 4 s / über 4 s	Startbild steht nicht im HTML, der Slider lädt es per Skript nach	Bild als img mit src in das HTML des ersten Slides, fetchpriority hoch, kein lazy	Wasserfall: LCP-Datei startet mit der ersten Ressource
LCP	bis 2,5 s / bis 4 s / über 4 s	Serverantwort langsam, Weiterleitungskette, Messparameter verhindern den Cache	CDN und Cache-Regeln prüfen, Weiterleitungen verkürzen	Antwortzeit des Servers im Bericht
LCP	bis 2,5 s / bis 4 s / über 4 s	Bilddatei zu groß oder falsches Format	Maße passend ausliefern, AVIF oder WebP, Zwischenspeicherung erlauben	Ladezeit der Datei und Darstellungsverzögerung
INP	bis 200 ms / bis 500 ms / über 500 ms	Fremdskripte belegen beim Laden den Hauptthread	Skripte nach den eigenen Inhalten und asynchron laden, Bestand durchsehen	Total Blocking Time im Labor, langsame Interaktion im Feld
INP	bis 200 ms / bis 500 ms / über 500 ms	Klick auf Warenkorb oder Filter läuft in einer langen Aufgabe	Aufgabe teilen, nach der sichtbaren Aktualisierung abgeben	Ablauf im Labor nachspielen und während des Ladens klicken
CLS	bis 0,1 / bis 0,25 / über 0,25	Bilder in Gitter, Slider und Empfehlungen ohne feste Maße	width und height oder aspect-ratio setzen	Layoutsprünge im Performance-Bereich der DevTools
CLS	bis 0,1 / bis 0,25 / über 0,25	Einwilligungsbanner oder Aktion oben wird nach dem Rendern eingefügt	Platz reservieren oder feste Leiste, mit transform animieren	Vergleich der Sprünge vor und nach der Änderung
CLS	bis 0,1 / bis 0,25 / über 0,25	Webfont ersetzt den Systemersatz mit anderen Maßen	Ersatzschrift sofort zeigen, Zeichensatz verkleinern, Datei komprimieren	Sprünge beim ersten Aufbau, auch auf langsamer Verbindung

So prüfen Sie das Ergebnis

• Die URL-Gruppe in der Search Console steht nach etwa vier Wochen auf gut; der Status gilt für den schlechtesten der drei Werte und getrennt für Mobil und Desktop.
• Dieselbe Vorlage hat sich im Lighthouse-Bericht mit unveränderten Einstellungen verbessert, und der Wasserfall zeigt die LCP-Datei jetzt am Anfang.
• Beim Scrollen über die Kategorieseite treten keine Sprünge mehr auf; die Prüfung deckt auch Bereiche unterhalb des ersten Bildschirms ab.
• Sie haben in diesem Zeitraum nur eine Änderung vorgenommen und ihr Datum notiert; beim eigenen Monitoring bleiben Bibliothek, Seitenauswahl und Geräteaufteilung gleich.

Wenn etwas nicht klappt

Symptom	Ursache	Behebung
Die Search Console zeigt keine Daten	zu wenig Besuche für CrUX oder Seiten ohne Mindestdaten	eigenes Real-User-Monitoring einrichten und die Vorlage zusätzlich mit PageSpeed Insights einzeln prüfen
PageSpeed Insights zeigt Fortschritt, die Search Console nicht	unterschiedliche Zeitfenster und Datenebenen	weiter messen, Datum der Änderung notieren, 28 Tage abwarten
LCP bleibt trotz kleiner Bilddatei hoch	das Element wird erst nach dem Laden von Skripten sichtbar	Bild und Text im ausgelieferten HTML, blockierendes Skript verschieben oder entfernen
CLS ist im Labor null und im Feld hoch	der Labortest lädt nur und löst keine Interaktionen aus	Felddaten auswerten und die Seite mit Scrollen und Klicks durchgehen
Die Werte weichen zwischen zwei Werkzeugen ab	verschiedene Seiten, Geräte oder Datenebenen	in allen Werkzeugen dieselbe URL, dasselbe Gerät und dieselbe Quelle verwenden

Wann Sie Hilfe holen sollten

Holen Sie Unterstützung, wenn Ihr Shopsystem Bilder erst per Skript einsetzt, Ihnen den Zugriff auf Vorlagen verwehrt oder die Startseite nur im Browser zusammensetzt. Bei einem geplanten Wechsel von Hosting oder System messen Sie vor und nach dem Umzug mit derselben Quelle; die Anforderungen an die Auslieferung stehen in Hosting für den Onlineshop.

Ein einzelner guter Wert einer Vorlage sagt nichts über Produkt- und Kategorieseiten. Für die wiederkehrende Kontrolle eignet sich Technisches SEO für Shops. Wie Sie eigene Messdaten erheben und datenschutzgerecht aufbewahren, steht in Webanalyse im Shop einrichten.