Core Web Vitals von WooCommerce-Shops 2026 — Leitfaden und Berichtsmethodik

Ein Shop kann in PageSpeed Insights 90 Punkte erhalten und dennoch die Core-Web-Vitals-Bewertung in der Google Search Console nicht bestehen. Er kann auch auf dem Computer des Inhabers schnell laufen, aber auf den Telefonen der Kunden langsam reagieren.

Das Problem liegt in der Regel nicht am Werkzeug selbst. Es entsteht durch die Vermischung zweier Arten von Daten: den Ergebnissen echter Nutzer und Tests, die unter kontrollierten Bedingungen durchgeführt werden.

Ein zuverlässiger Core-Web-Vitals-Bericht sollte nicht mit einem einzigen Wert „72/100" enden. Er muss zeigen, welche Seitentypen langsam sind, auf welchen Geräten das Problem auftritt, was es verursacht und welche Korrekturen für den Shop am wichtigsten sind.

In diesem Leitfaden zeigen wir, wie Sie einen solchen Bericht für WooCommerce erstellen: welche Adressen Sie untersuchen, welche Quellen Sie nutzen, wie Sie LCP, INP und CLS interpretieren und wie Sie echte Probleme von zufälligen Testschwankungen trennen.

Kurz gesagt

Dieser Bericht zeigt, wie WooCommerce-Shops bei den Core Web Vitals wirklich abschneiden — auf Basis von Felddaten (CrUX) — und erläutert die Messmethodik. Die wichtigste Erkenntnis: Ein Wert von 90+ in PageSpeed Insights (ein Labortest) bedeutet nicht, dass die Core Web Vitals in der Search Console bestanden werden (Daten echter Nutzer, überwiegend von Telefonen). Entscheidend ist, was der Kunde auf seinem Gerät sieht, nicht das Ergebnis auf dem Computer des Inhabers. Wie Sie diese Kennzahlen Schritt für Schritt verbessern, erklären wir im Ratgeber Core Web Vitals im WooCommerce-Shop.

Auf einen Blick (TL;DR)

• Die Core Web Vitals umfassen 2026 LCP, INP und CLS. Alle drei müssen im 75. Perzentil ein gutes Ergebnis erreichen, damit eine Seite oder eine Gruppe von Adressen die Bewertung besteht.
• Felddaten stammen von echten Nutzern, Labordaten sind eine Simulation. Sie sollten nicht gemittelt werden.
• WooCommerce muss nach Seitentypen untersucht werden. Startseite, Kategorie, Produkt und Checkout können völlig unterschiedliche Probleme haben.
• Ein Lighthouse-Wert von 90/100 bedeutet nicht automatisch, dass der Shop die Core Web Vitals besteht.
• Ein guter Bericht zeigt das Ergebnis, die Ursache, die Priorität, die verantwortliche Person und die Art, die Korrektur zu überprüfen.
• Felddaten umfassen ein gleitendes Fenster der letzten 28 Tage, deshalb ist ihre Veränderung nicht sofort nach der Bereitstellung sichtbar.

Was ist ein Core-Web-Vitals-Bericht für WooCommerce?

Ein Core-Web-Vitals-Bericht ist eine geordnete Messung von Geschwindigkeit, Reaktionsfähigkeit und Stabilität des Shops, die auf Daten echter Nutzer und auf diagnostischen Tests beruht.

Er ist kein einzelner Screenshot aus PageSpeed Insights. Der Bericht sollte folgende Fragen beantworten: Besteht der Shop die Core Web Vitals; welche Kennzahl verursacht das Problem; betrifft es Telefone, Computer oder beide Gruppen; welche Unterseitentypen schneiden am schlechtesten ab; ist die Quelle der Server, ein Bild, JavaScript, das Theme oder ein externer Dienst; tritt das Problem bei echten Nutzern auf; was sollte zuerst behoben werden; und wie prüfen wir, ob die Korrektur gewirkt hat. Wenn der Bericht nur einen Leistungswert und eine Liste automatischer Empfehlungen zeigt, weiß der Shop-Inhaber immer noch nicht, womit er beginnen soll.

Welche Core-Web-Vitals-Kennzahlen gelten 2026?

Die aktuellen Core Web Vitals sind LCP, INP und CLS. Die Bewertung besteht eine Seite, die für alle drei Kennzahlen im 75. Perzentil der Besuche ein gutes Ergebnis erreicht.

Kennzahl	Gutes Ergebnis	Verbesserungswürdig	Schlechtes Ergebnis
LCP	bis 2,5 s	über 2,5 bis 4 s	über 4 s
INP	bis 200 ms	über 200 bis 500 ms	über 500 ms
CLS	bis 0,1	über 0,1 bis 0,25	über 0,25

Warum ein Durchschnitt nicht ausreicht. Ein Durchschnitt kann ein Problem verbergen: Wenn die Hälfte der Kunden das Produkt nach 1,5 s sieht und die andere Hälfte 5 s wartet, beträgt der Durchschnitt 3,25 s — er zeigt jedoch nicht, dass eine sehr große Gruppe von Nutzern ein deutlich schlechteres Erlebnis hat. Stellen Sie im Bericht das 75. Perzentil dar, den Anteil guter, verbesserungswürdiger und schlechter Ergebnisse sowie die Veränderung gegenüber dem vorherigen Zeitraum.

Was messen LCP, INP und CLS in einem WooCommerce-Shop?

LCP misst die Zeit bis zur Anzeige des größten Elements im anfänglichen Bereich der Seite. In WooCommerce kann dies ein Banner auf der Startseite, ein Kategoriebild, das Hauptproduktbild, eine große Überschrift oder eine Kampagnengrafik sein. Ein schlechtes Ergebnis kann von einem langsamen Server, einem schweren Bild, dem zu späten Abruf der Ressource oder von blockierendem Code herrühren. Lazy Loading (das Verschieben des Bildabrufs, bis es benötigt wird) ist für Bilder weiter unten auf der Seite nützlich, sollte aber nicht unkontrolliert das Hauptbild umfassen, das das LCP-Element ist. Allein das Verkleinern des Bildes behebt das Ergebnis nicht immer — wenn das Bild erst nach der Ausführung von JavaScript erkannt wird, beginnt sein Abruf trotzdem zu spät.

INP misst die Verzögerung zwischen einer Aktion des Nutzers und der Anzeige der nächsten Änderung auf dem Bildschirm. In einem Shop sind wichtig: das Öffnen des Menüs, Filter, die Auswahl einer Variante, das Hinzufügen zum Warenkorb, das Öffnen des Mini-Warenkorbs, die Wahl der Lieferung, die Änderung der Zahlung und die Formularvalidierung. Ein schlechtes INP hängt häufig mit einer großen Menge an JavaScript, langen Aufgaben, einem schweren Page-Builder oder einer umfangreichen Seitenstruktur zusammen. Das DOM ist die Struktur der HTML-Elemente, die die Seite aufbauen — wenn Theme und Builder Tausende verschachtelter Elemente erzeugen, kann jede Interaktion mehr Berechnungen erfordern.

CLS misst unerwartete Verschiebungen von Elementen während der Nutzung der Seite. Das Problem tritt auf, wenn der Kunde auf „In den Warenkorb" klicken möchte, aber im letzten Moment über der Schaltfläche eine Meldung, ein Banner oder eine neue Information erscheint. In WooCommerce verursachen die Verschiebungen häufig Bilder ohne festgelegte Abmessungen, ein dynamischer Variantenpreis, ein Cookie-Banner, eine Aktionsleiste, ein Bewertungsbereich, ein Chat-Widget, eine spät geladene Schriftart und eine WooCommerce-Meldung.

Ist TTFB Teil der Core Web Vitals?

TTFB ist kein Core Web Vital, aber es ist eine wichtige diagnostische Kennzahl bei der Untersuchung von WooCommerce.

TTFB (Time to First Byte) misst die Zeit vom Beginn der Anfrage bis zum Empfang des ersten Bytes der Antwort vom Server. Als Richtwert sollten die meisten Websites etwa 0,8 Sekunden oder weniger anstreben — dies ist jedoch kein offizieller Schwellenwert zum Bestehen der Core Web Vitals. Wenn der Server nach 2 Sekunden antwortet, kann der Browser erst dann mit dem Abruf des Dokuments, der Stile, der Skripte und der Bilder beginnen.

Was TTFB in WooCommerce erhöhen kann: überlastetes Hosting, zu wenige PHP-Prozesse, eine langsame Datenbank, schwere Plugin-Abfragen, eine große Menge an Autoload-Daten, fehlender Object Cache, Aufrufe einer externen API, Geolokalisierung, Preispersonalisierung und eine große Anzahl von Varianten. Autoload sind Daten aus der Tabelle wp_options, die WordPress bei jeder Anfrage automatisch lädt — wenn es davon zu viele gibt, können sie die Datenbank und den Speicher unnötig belasten. Object Cache ist ein Zwischenspeicher für die Ergebnisse von Abfragen und Berechnungen von WordPress (z. B. Redis), der die Anzahl wiederholter Lesevorgänge aus der Datenbank verringert. Nicht jede WooCommerce-Seite lässt sich mit vollem Cache ausliefern — Warenkorb, Checkout und Kundenkonto enthalten Daten eines bestimmten Nutzers und erfordern deshalb ein leistungsfähiges Backend und eine korrekte Sitzungskonfiguration.

Feld- und Labordaten — worin besteht der Unterschied?

Felddaten zeigen die Erfahrungen echter Nutzer, während Labordaten helfen, das Problem zu reproduzieren und seine Ursache zu finden.

Datenart	Was sie zeigt	Vorteil	Einschränkung
Feld / CrUX	Echte Besuche von Chrome-Nutzern	Zeigt reale Erfahrungen	Erfordert ausreichenden Traffic
Eigenes RUM	Direkt im Shop erfasste Daten	Mehr Details und Segmente	Erfordert eine Implementierung
Labor / Lighthouse	Simulierter Seitenaufruf	Wiederholbare Diagnostik	Bildet nicht alle Kunden ab
Test in DevTools	Konkrete Interaktionen	Hilft, INP zu diagnostizieren	Hängt vom Szenario und Gerät ab

Felddaten stammen aus echten Besuchen. Die öffentliche Quelle von Google ist CrUX (Chrome User Experience Report) — sie umfasst qualifizierende Besuche von Chrome-Nutzern und kann Daten für eine bestimmte Adresse oder die gesamte Domain bereitstellen. In PageSpeed Insights umfassen die CrUX-Daten ein gleitendes Fenster der letzten 28 Tage. Das Feld beantwortet die Frage: Wie hat der Shop für echte Nutzer funktioniert?

Labordaten entstehen während eines simulierten Tests. Lighthouse analysiert die Seite unter bestimmten Bedingungen von Gerät, Prozessor und Netzwerk — es kann die Reihenfolge des Ressourcenabrufs, blockierende Dateien, das LCP-Element, lange Aufgaben, ungenutztes JavaScript, Layoutverschiebungen, die Anzahl der Anfragen und die Seitengröße zeigen. Das Labor beantwortet die Frage: Was kann das Problem verursachen und verbessert eine bereitgestellte Änderung das Ergebnis unter denselben Testbedingungen?

Warum ist Lighthouse keine Core-Web-Vitals-Bewertung?

Der Lighthouse-Wert von 0 bis 100 ist eine synthetische Bewertung eines Labortests und kein Core-Web-Vitals-Ergebnis aus realen Besuchen.

Im Laborteil finden Sie unter anderem First Contentful Paint, Largest Contentful Paint, Speed Index, Total Blocking Time und Cumulative Layout Shift. INP wird durch ein gewöhnliches automatisches Öffnen der Seite standardmäßig nicht gemessen, da es eine Nutzerinteraktion erfordert. In Lighthouse erfüllt unter anderem TBT (Total Blocking Time) eine diagnostische Funktion — es zeigt die Zeit, in der der Hauptthread während des Ladens blockiert ist.

Welche Werkzeuge sollten Sie für den Core-Web-Vitals-Bericht verwenden?

Die Google Search Console zeigt Core-Web-Vitals-Probleme auf der Ebene von Gruppen ähnlicher Adressen — sie trennt Mobil/Desktop sowie gute, verbesserungswürdige und schlechte Adressen und kann Produktkarten aus derselben Vorlage gruppieren. Der Bericht zeigt nicht alle Adressen, erfordert eine ausreichende Datenmenge, beruht auf echten Besuchen und kann ein Problem für eine Gruppe statt für eine einzelne URL anzeigen.

PageSpeed Insights (PSI) verbindet CrUX-Felddaten mit einer Lighthouse-Laboranalyse. Prüfen Sie vor dem Speichern des Ergebnisses, ob sich die Felddaten auf eine bestimmte URL oder die gesamte Domain (Origin) beziehen, ob sie überhaupt verfügbar sind, welchen Zeitraum sie zeigen und ob Sie Mobil oder Desktop ansehen. Wenn ein Produkt nicht genügend Traffic hat, kann PSI Daten der gesamten Domain anzeigen — diese dürfen dann nicht als Ergebnis eines bestimmten Produkts dargestellt werden.

CrUX Vis hilft, den historischen Trend der realen Ergebnisse zu beobachten: wann sich die Kennzahl zu verschlechtern begann, ob das Problem dauerhaft auftritt, wie der Zeitraum vor und nach der Bereitstellung aussieht und welche Unterschiede zwischen Mobil und Desktop bestehen.

Ein eigenes RUM (Real User Monitoring) erlaubt es, detaillierte Daten zu erfassen, ohne sich auf das öffentliche CrUX zu beschränken — Sie können die Bibliothek web-vitals verwenden und die Ergebnisse an eine eigene Datenbank, ein Analysesystem oder GA4 senden und dabei zusätzlich den Seitentyp, das Gerät, die Vorlagenversion, das LCP-Element, die Interaktion mit schlechtem INP, den Anmeldestatus, das aktive Experiment sowie die Liefer-/Zahlungsmethode festhalten. Die Ergebnisse des eigenen RUM und von CrUX müssen nicht identisch sein — sie können eine andere Nutzergruppe und andere Regeln der Datenerfassung umfassen.

Chrome DevTools (das Panel Performance) dient der technischen Analyse von Laden und Interaktionen — es hilft, das LCP-Element, lange Aufgaben, blockierendes JavaScript, die Kosten der Neuberechnung von Stilen, ein großes DOM, Layoutverschiebungen und langsame Interaktionen zu finden. Es ist besonders nützlich bei der Diagnose von INP, weil es erlaubt, eine konkrete Handlung auszuführen (z. B. einen Filter zu verwenden oder eine Variante zu wählen).

Wie erstellen Sie einen Core-Web-Vitals-Bericht Schritt für Schritt?

Schritt 1. Legen Sie das Ziel des Berichts fest. Stellen Sie zuerst fest, ob der Bericht einen einzelnen Shop, einen Wettbewerbsvergleich oder eine größere Branchenstichprobe betrifft — das sind drei verschiedene Projekte. Ein Audit eines einzelnen Shops nutzt die Search Console, GA4, ein eigenes RUM, Serverprotokolle, Bestelldaten, eine Testumgebung und Informationen über Plugins — das Ziel ist, das Problem zu finden und zu beheben. Ein Wettbewerbsvergleich hat hauptsächlich Zugriff auf öffentliche CrUX-Daten, Labortests und öffentliche Unterseiten (Sie sehen weder die Serverkonfiguration noch die Verkaufsdaten oder den privaten Teil des Checkouts). Ein Branchenbericht erfordert die Beschreibung der Domainauswahl, der Ein-/Ausschlusskriterien, der Methode zur Bestätigung von WooCommerce, des Stichprobenumfangs, des Messdatums, der fehlenden Daten, der Aggregationsmethode und der Anonymisierungsregeln — ohne dies ist der Bericht eine Ergebnissammlung und keine wiederholbare Studie.

Schritt 2. Bauen Sie eine repräsentative Stichprobe von Seiten auf. Ein Shop lässt sich nicht allein anhand der Startseite bewerten.

Seitentyp	Beispiel
Startseite	Die Haupt-Landingpage des Shops
Kategorie	Eine beliebte Produktliste
Kategorie mit Filtern	Liste nach Anwendung eines wichtigen Filters
Einfaches Produkt	Ein Produkt ohne Varianten
Variables Produkt	Größen, Farben oder Konfiguration
Aktionsprodukt	Regulärer und reduzierter Preis
Suche	Suchergebnisse innerhalb des Shops
Warenkorb	Ein zum Warenkorb hinzugefügtes Produkt
Checkout	Formular, Lieferung und Zahlung
Kundenkonto	Anmeldung und Bestellverlauf

Warenkorb, Checkout und Konto sind in der Regel nicht indexiert, personalisiert und werden von weniger Personen besucht — für sie benötigen Sie oft ein eigenes RUM oder manuelle Tests. Berücksichtigen Sie bei der Produktauswahl ein beliebtes Produkt, eines mit vielen Bildern, ein variables, eines mit Bewertungen, eines mit Video oder Konfiguration sowie dasjenige, das den meisten Traffic aus Anzeigen erhält.

Schritt 3. Halten Sie die Testbedingungen fest. Der Bericht sollte erlauben, die Messung zu wiederholen — halten Sie Datum und Uhrzeit, die untersuchte URL, den Seitentyp, das Gerät, die Datenquelle, den Zeitraum der Felddaten, die Werkzeugversion, den Teststandort, die Netzwerkbedingungen, den Cache-Zustand, die Anzahl der Durchläufe, den Anmeldestatus, die erteilte oder fehlende Cookie-Zustimmung sowie die aktive A/B-Test-Variante fest. Beim Vergleich von Zeiträumen halten Sie dieselben Bedingungen ein.

Schritt 4. Erheben Sie die Felddaten. Felddaten sollten die Hauptquelle der Information darüber sein, wie der Shop für echte Nutzer funktioniert. Reihenfolge: Öffnen Sie den CWV-Bericht in der Search Console → prüfen Sie Mobil und Desktop getrennt → halten Sie die Anzahl der guten/verbesserungswürdigen/schlechten Gruppen fest → öffnen Sie die einzelnen Probleme → notieren Sie repräsentative Adressen → prüfen Sie sie in PSI → stellen Sie fest, ob PSI URL- oder Origin-Daten zeigt → prüfen Sie den Verlauf in CrUX Vis → wenn Sie ein eigenes RUM haben, teilen Sie die Ergebnisse nach Vorlage und Gerät auf. Wenn eine öffentliche Quelle keine Stichprobe hat, schreiben Sie: „Unzureichende Felddaten für diese Adresse. Es wurde ein Labortest durchgeführt, der nicht als Ergebnis echter Nutzer behandelt werden sollte." Das Fehlen von CrUX-Daten bedeutet nicht, dass die Seite schnell oder langsam ist.

Schritt 5. Führen Sie die Labortests durch. Führen Sie Labortests mehrmals unter denselben Bedingungen durch und berichten Sie den Median: mindestens 3 Durchläufe für eine wichtige Adresse (5 bei einer größeren Studie), getrennte Mobil-/Desktop-Tests, ein sauberes Browserprofil, deaktivierte Erweiterungen, derselbe Standort und dasselbe Netzwerk, keine Bereitstellungen und keine schweren Backups während des Tests. Der Median ist das mittlere Ergebnis nach dem Ordnen der Messungen — weniger anfällig für einen einzelnen extremen Durchlauf. Beispiel: 2,3 s / 2,5 s / 2,6 s / 2,9 s / 5,8 s → Median LCP = 2,6 s. Wählen Sie nicht 2,3 s, nur weil es das beste ist; auch ein einzelnes 5,8 s sollte die Analyse der gesamten Stichprobe nicht automatisch ersetzen.

Schritt 6. Testen Sie die für den Verkauf wichtigen Interaktionen. INP erfordert echte Nutzerhandlungen, nicht nur ein automatisches Öffnen der Seite. Bereiten Sie ein festes Szenario vor. Kategorie: Filter öffnen → eine Marke wählen → einen Preisbereich festlegen → die Sortierung ändern → die Filter löschen → zur nächsten Seite wechseln. Variables Produkt: die Farbe ändern → die Größe wählen → die Stückzahl ändern → die Galerie öffnen → zum Warenkorb hinzufügen → den Mini-Warenkorb öffnen. Warenkorb und Checkout: die Produktanzahl ändern → einen Rabattcode anwenden → die Lieferung berechnen → einen Abholpunkt wählen → die Zahlungsmethode ändern → einen Formularfehler auslösen und beheben. AJAX erlaubt es, ein Fragment der Seite nachzuladen, ohne das gesamte Dokument neu zu laden — WooCommerce verwendet es unter anderem zur Aktualisierung des Warenkorbs, von Checkout-Fragmenten und eines Teils der Filter; eine große Anzahl aufeinanderfolgender AJAX-Anfragen kann Verzögerungen verursachen, besonders wenn jede schwere Datenbankabfragen oder eine externe API auslöst. Halten Sie fest, welche Interaktion langsam war, ob sie während des Ladens auftrat, welches Skript sie bediente, wie lange der Hauptthread blockiert war, wie viele Layoutelemente neu berechnet wurden und ob das Problem ein einzelnes Plugin betraf.

Schritt 7. Finden Sie die Ursache, nicht nur das Symptom. Jedes schlechte Ergebnis sollte mit einer technischen Hypothese und einem Beweis verbunden sein.

Problem	Beweis	Wahrscheinliche Ursache
LCP 4,2 s bei einem Produkt	Das LCP-Element ist ein 1,8-MB-Bild	Zu große Datei und später Abruf
LCP 4,5 s bei TTFB 2,1 s	Das HTML-Dokument beginnt spät	Server, Datenbank oder ein schweres Plugin
INP 620 ms nach Anwendung eines Filters	Eine lange JavaScript-Aufgabe	Filter oder ein umfangreiches DOM
CLS 0,24	Verschiebung nach dem Erscheinen eines Banners	Kein reservierter Platz
Langsamer Checkout	Eine Reihe aufeinanderfolgender AJAX-Anfragen	Lieferung, Steuern oder Zahlung

Schreiben Sie nicht nur „JavaScript sollte reduziert werden". Eine bessere Notiz: „Nach der Auswahl einer Variante blockiert das Skript von Plugin X den Hauptthread für etwa 480 ms. Das Problem tritt bei variablen Produkten auf und betrifft die wichtigste Kaufinteraktion. Priorität: hoch."

Schritt 8. Priorisieren Sie die Korrekturen. Die Priorität sollte sich aus der Auswirkung auf den Nutzer und den Verkauf ergeben, nicht aus der Reihenfolge der Empfehlungen in Lighthouse.

Priorität	Bedeutung	Beispiel
P0 — kritisch	Blockiert oder erschwert den Kauf erheblich	Eine nicht funktionierende Schaltfläche oder Checkout
P1 — hoch	Betrifft hohen Traffic oder die Hauptvorlage	Schlechtes LCP aller Produkte
P2 — mittel	Verschlechtert das Erlebnis, blockiert aber den Kauf nicht	Eine Verschiebung des Bewertungsbereichs
P3 — niedrig	Eine ordnende Änderung mit geringer Auswirkung	Eine kleine Menge überflüssiges CSS

Bewerten Sie zusätzlich die Anzahl der betroffenen Adressen, den Traffic-Anteil, die Auswirkung auf Mobil, die Trichterstufe, die Schwierigkeit der Umsetzung, das Risiko, den Shop zu beschädigen, und die Möglichkeit, die Änderung zu testen. Das Verkleinern des Logos um 15 KB kann einfach sein, muss aber die wahrgenommene Geschwindigkeit nicht verändern; die Behebung eines Skripts, das die Variantenauswahl blockiert, erfordert mehr Arbeit, betrifft aber direkt den Kauf — sie sollte eine höhere Priorität haben.

Schritt 9. Testen Sie die Korrekturen vor der Bereitstellung. Prüfen Sie Leistungsänderungen auf Staging und im vollständigen Kaufprozess. Testen Sie nach einer Änderung von Cache, JavaScript oder Theme die Anmeldung, Preise, Varianten, Rabattcodes, den Warenkorb, Lieferungen, Zahlungen, E-Mails, Lagerbestände und die Analytik.

Schritt 10. Überprüfen Sie die Ergebnisse nach der Bereitstellung. Das Laborergebnis lässt sich sofort prüfen, aber die Felddaten ändern sich schrittweise im 28-Tage-Fenster von CrUX. Nach der Bereitstellung: wiederholen Sie die Labortests unter denselben Bedingungen → prüfen Sie den Kaufprozess → vergleichen Sie die Mediane vorher und nachher → beobachten Sie Ihr eigenes RUM → prüfen Sie den Trend in CrUX Vis → starten Sie die Problemvalidierung in der Search Console → überwachen Sie das Ergebnis über die folgenden Wochen. Erwarten Sie nicht, dass der gesamte Search-Console-Bericht am nächsten Tag grün wird — neue Besuche ersetzen schrittweise ältere Daten, und eine dauerhafte Verbesserung wird mit der Zeit in den Feldergebnissen sichtbar.

Wie sollte die Struktur des Berichts aussehen?

Der Bericht sollte von der geschäftlichen Zusammenfassung zu den technischen Beweisen und dem Umsetzungsplan führen.

1. Zusammenfassung für den Inhaber (eine Seite): der allgemeine Zustand, das wichtigste Problem, die betroffenen Vorlagen, die mögliche Auswirkung, die ersten drei Maßnahmen, die Art der Überprüfung. 2. Umfang und Methodik: untersuchte Adressen, Geräte, Datenzeitraum, Quellen, Anzahl der Durchläufe, Einschränkungen, fehlende Daten. 3. Felddaten: LCP/INP/CLS p75, Anteil guter Besuche, Trend, Mobil/Desktop, URL vs. Origin. 4. Laborergebnisse: Median LCP, TBT, CLS, TTFB, Seitengröße, Anzahl der Anfragen, LCP-Element, lange Aufgaben. 5. Analyse nach Vorlage: getrennt Startseite, Kategorien, Produkte, Warenkorb, Checkout. 6. Liste der Probleme: für jedes eine Beschreibung, ein Beweis, betroffene Adressen, Auswirkung, Priorität, Empfehlung, verantwortliche Person, Art des Tests. 7. Umsetzungsplan: schnelle Korrekturen, Entwicklungsarbeiten, Serveränderungen, Theme-Änderungen, Plugin-Änderungen, Monitoring.

Eine beispielhafte Ergebnistabelle

Die folgenden Daten zeigen, wie die Tabelle aufgebaut wird — sie sind nicht das Ergebnis eines bestimmten Shops.

Seitentyp	Quelle	LCP	INP/TBT	CLS	TTFB	Status	Hauptproblem
Startseite	CrUX URL	2,3 s	180 ms	0,05	0,7 s	Gut	Keines
Kategorie	RUM	3,2 s	240 ms	0,08	0,9 s	Verbesserungswürdig	Banner und Filter
Produkt	CrUX-Gruppe	4,1 s	310 ms	0,12	1,4 s	Schlecht	Bild und Server
Warenkorb	Labor	2,8 s	TBT 390 ms	0,04	1,1 s	Diagnostik	Warenkorb-Skripte
Checkout	Manueller Test	—	Langsame Validierung	0,03	1,6 s	Kritisch	Zahlung und Lieferung

Das Zeichen „—" bedeutet kein Ergebnis von 0 — es bedeutet, dass die Kennzahl in der jeweiligen Quelle nicht zuverlässig gemessen wurde.

Wie berichten Sie das Ergebnis des gesamten Shops?

Reduzieren Sie das gesamte WooCommerce nicht auf eine einzige Durchschnittszahl.

Bessere Sammelindikatoren sind der Prozentsatz der Gruppen mit gutem Ergebnis, der Prozentsatz der Besuche, die alle drei Kennzahlen bestehen, die Ergebnisse der wichtigsten Vorlagen, Mobil vs. Desktop, der Trend gegenüber dem vorherigen Zeitraum, die Anzahl der Probleme P0 und P1 sowie der Anteil des vom Problem betroffenen Traffics. Mischen Sie nicht in einem Durchschnitt LCP in Sekunden, INP in Millisekunden, CLS ohne Einheit und den Lighthouse-Wert 0–100.

Methodik eines öffentlichen WooCommerce-Branchenberichts

Ein öffentlicher Bericht erfordert eine klar beschriebene Stichprobe, Qualifikationskriterien und Aggregationsregeln.

Auswahl der Shops. Legen Sie die Anzahl der Domains, das Land und die Sprache, die Methode zur Erkennung von WooCommerce, die Anforderung eines aktiven Shops, die Mindestelemente des Angebots, den Datenerfassungszeitraum sowie die Art des Umgangs mit Subdomains und Sprachversionen fest.

WooCommerce-Verifizierung. Die automatische Technologieerkennung kann sich irren — bestätigen Sie die Stichprobe anhand des Quellcodes, charakteristischer WooCommerce-Ressourcen, von Endpunkten, der Warenkorbstruktur und einer manuellen Kontrolle eines Teils der Domains. Ein Endpunkt ist eine konkrete Adresse oder ein Kommunikationspunkt, über den eine Anwendung Daten bereitstellt oder Anfragen annimmt. Wenn der Bericht Headless-Shops umfasst, kennzeichnen Sie sie gesondert — Headless bedeutet, dass WooCommerce als Backend arbeitet, während die für den Kunden sichtbare Schicht in einer anderen Technologie gebaut wurde.

Fehlende Daten. Entfernen Sie nicht ohne Erklärung alle Shops ohne CrUX. Zeigen Sie, wie viele Domains vollständige Daten hatten, wie viele nur Origin-Daten, wie viele keine Daten hatten und wie viele aus welchem Grund ausgeschlossen wurden. Das Fehlen von CrUX-Daten ist kein Leistungsergebnis.

Anonymisierung. Wenn das Ziel ist, den Zustand des Marktes zu beschreiben, veröffentlichen Sie vor allem Sammelergebnisse. Eine Liste der „langsamsten Shops" kann zu irreführenden Schlussfolgerungen führen, weil Sie die während der Studie umgesetzten Änderungen, die Experimente, die Standorte der Nutzer, die Traffic-Struktur, die Serverbedingungen und die technischen Ursachen nicht kennen. Veröffentlichen Sie die Namen konkreter Shops nur dann, wenn die Methodik und der Kontext dies rechtfertigen.

Die häufigsten WooCommerce-Probleme nach Kennzahl

LCP-Probleme verursachen am häufigsten: ein langsamer Server, ein schweres Hauptbild, ein Slider, Lazy Loading des LCP-Elements, eine späte Erkennung der Ressource, blockierendes CSS, eine schwere Schriftart und ein durch JavaScript ausgelöster Banner. Prüfen Sie zuerst: welches Element das LCP ist, wie hoch der TTFB ist, wann der Browser die Ressource erkennt, wie schwer die Datei ist, ob sie korrekte Abmessungen hat, ob sie priorisiert geladen wird und was ihre Darstellung verzögert. Preload ist eine Anweisung, dass der Browser eine bestimmte Ressource früher und mit hoher Priorität abrufen sollte — setzen Sie es nicht für alle Bilder; die Priorität sollte das tatsächliche Element erhalten, das zu Beginn des Ladens benötigt wird.

INP-Probleme verursachen am häufigsten: schwere Filter, eine große Anzahl von Varianten, ein umfangreiches DOM, ein Page-Builder, Werbeskripte, Chat, ein Empfehlungssystem, der Mini-Warenkorb, Bewertungsskripte und lange JavaScript-Aufgaben. Prüfen Sie zuerst die langsamsten Interaktionen, die langen Aufgaben, das für das Ereignis verantwortliche Skript, die Anzahl der neu berechneten Elemente, das Verhalten während des Ladens und das Ergebnis nach dem Deaktivieren des verdächtigen Plugins auf Staging.

CLS-Probleme verursachen am häufigsten: fehlende Bildabmessungen, eine Änderung der Galeriehöhe, dynamische Variantenpreise, eine Aktionsleiste, ein Cookie-Banner, eine Schriftart, die die Textbreite ändert, ein Bewertungs-Widget, WooCommerce-Meldungen und ein Sticky-Menü. Prüfen Sie zuerst das Element, das die größte Verschiebung verursacht, ob sein Platz reserviert ist, ob die Änderung nach der Cookie-Zustimmung erfolgt, ob das Problem nach der Auswahl einer Variante auftritt und ob es während des Scrollens auftritt.

TTFB-Probleme verursachen am häufigsten: ein nicht zum Shop passendes Hosting, langsames PHP, eine schwere Datenbank, Abfragen ohne Indizes, übermäßiges Autoload, fehlender Object Cache, externe APIs, eine große Anzahl von Plugins, die Last durch Bots und Cron-Aufgaben, die während eines Besuchs ausgeführt werden. Cron ist ein Mechanismus, der geplante Aufgaben ausführt (Produktsynchronisation, Versand von Nachrichten, Datenbereinigung). Redis oder ein anderer Object Cache kann die Anzahl wiederholter Abfragen verringern, behebt aber kein schlecht geschriebenes Plugin und keine langsame Antwort einer externen API. Mehr Maßnahmen im Ratgeber wie Sie einen WooCommerce-Shop beschleunigen und im Artikel Hosting für WooCommerce — wie wählen.

Die häufigsten Fehler in Core-Web-Vitals-Berichten

Die am häufigsten wiederholten Fehler verfälschen das Bild der Leistung und führen zu schlechten Entscheidungen.

Das Berichten eines einzelnen Tests — ein Durchlauf kann extrem ausfallen; berichten Sie den Median mehrerer Messungen. Das Testen nur der Startseite — sie kann schnell sein, während Produkt, Filter und Checkout schwerwiegende Probleme haben. Das Vermischen von Feld- und Labordaten — mitteln Sie LCP aus CrUX nicht mit LCP aus Lighthouse. Das Behandeln eines Werts von 90 als Bestehen der CWV — Lighthouse ersetzt nicht die realen Daten für LCP, INP, CLS. Das Angeben von TBT als INP — TBT unterstützt die Diagnose, ist aber eine andere Messung. Fehlende Information URL vs. Origin — Daten der gesamten Domain sind nicht das Ergebnis einer bestimmten Produktkarte. Fehlende Tests des Kaufprozesses — der Bericht kann die Startseite verbessern und Filter, Warenkorb und Zahlung langsam lassen. Das Installieren eines weiteren „Geschwindigkeits"-Plugins — mehrere Cache-Werkzeuge können dieselben Ressourcen verändern und schwer reproduzierbare Fehler verursachen. Fehlender Test nach der Bereitstellung — ein besseres Ergebnis hat keinen Wert, wenn Varianten, Warenkorb oder Zahlungen nicht mehr funktionieren.

Was können Sie selbst prüfen?

Eine grundlegende Diagnose führen Sie durch, indem Sie die folgende Liste für mehrere Seitentypen durchgehen.

1. Öffnen Sie den Core-Web-Vitals-Bericht in der Google Search Console.
2. Prüfen Sie Mobil und Desktop getrennt.
3. Testen Sie die Startseite, eine Kategorie und ein Produkt.
4. Stellen Sie fest, ob sich die PSI-Daten auf eine URL oder einen Origin beziehen.
5. Halten Sie das LCP-Element jeder untersuchten Seite fest.
6. Vergleichen Sie den TTFB der einzelnen Vorlagen.
7. Führen Sie mindestens drei Durchläufe durch.
8. Öffnen Sie den Shop auf einem Telefon im privaten Modus.
9. Verwenden Sie Filter und Varianten.
10. Fügen Sie ein Produkt zum Warenkorb hinzu.
11. Gehen Sie durch Lieferung und Zahlung.
12. Achten Sie auf Verschiebungen der Kaufschaltfläche.
13. Vergleichen Sie das Verhalten vor und nach der Cookie-Zustimmung.
14. Halten Sie Datum, Gerät und Messbedingungen fest.

Sie können auch den Rechner für Umsatzverluste verwenden, um zu schätzen, wie viel ein langsamer Shop kostet.

Wann lohnt es sich, einen Spezialisten zu beauftragen?

Technische Hilfe ist nötig, wenn das Ergebnis ein Problem anzeigt, aber unklar ist, welche Schicht von WooCommerce es verursacht oder wie man sie sicher ändert.

Es lohnt sich, eine Analyse zu beauftragen, wenn die Search Console schlechte Adressgruppen zeigt, sich die Labor- und Feldergebnisse erheblich unterscheiden, der Shop keine öffentlichen CrUX-Daten hat, Sie nicht wissen, welches Element das LCP ist, sich INP nach der Verwendung von Filtern verschlechtert, der Checkout trotz einer schnellen Startseite langsam arbeitet, eine Cache-Änderung Warenkorbfehler verursacht, der Shop viele Plugins hat, Probleme nach einem Umbau auftraten, der TTFB bei höherem Traffic steigt, Sie einen Bericht für den Vorstand oder einen Kunden benötigen, Sie die Ergebnisse vor und nach einer Migration vergleichen möchten, Sie ein eigenes RUM benötigen oder die Umsetzung Änderungen am Theme, einem Plugin oder dem Server erfordert. In einem solchen Fall benötigen Sie nicht nur einen Geschwindigkeitstest, sondern ein technisches SEO-Audit, das Felddaten, Labortests, eine Analyse des Codes, des Servers und der wichtigsten WooCommerce-Vorlagen verbindet. Wenn das Hauptproblem die Infrastruktur ist, prüfen Sie auch den Server für WordPress und WooCommerce.

---

Das Ziel sind nicht 100 Punkte, sondern ein leistungsfähiger Shop

Ein zuverlässiger Core-Web-Vitals-Bericht für WooCommerce beschränkt sich nicht auf den PageSpeed-Wert. Er sollte Feld und Labor trennen, das 75. Perzentil zeigen, Mobil und Desktop untersuchen, verschiedene Unterseitentypen umfassen, Kaufinteraktionen testen, TTFB diagnostisch berücksichtigen, eine konkrete Ursache benennen, den Korrekturen Prioritäten zuweisen, die Methodik beschreiben und das Ergebnis vor und nach der Bereitstellung vergleichen.

Das Ziel ist nicht, 100 Punkte zu erreichen, sondern ein Shop, der das Produkt schnell anzeigt, auf die Handlungen des Kunden reagiert, keine Schaltflächen verschiebt und einen problemlosen Übergang zur Zahlung ermöglicht. Wenn Sie die Core Web Vitals Ihres WooCommerce prüfen möchten, können wir einen Bericht erstellen, der CrUX, die Search Console, Lighthouse, die wichtigsten Vorlagen, Filter, Produkte und den Checkout umfasst:

• Technisches SEO — Ergebnisse, Ursachen, Umsetzungsprioritäten und die Art, die Effekte zu prüfen.
• WordPress- und WooCommerce-Server — wenn die Quelle des Problems die Infrastruktur und der TTFB ist.
• Core Web Vitals — die Grundlagen und wie Sie einen WooCommerce-Shop beschleunigen — verwandte Ratgeber.