Eine WooCommerce-Produktseite lädt meist akzeptabel. Die Shop-Seite, die Kategorielisten und die Suchergebnisse tun das oft nicht, und Shop-Betreiber überrascht das regelmäßig, weil sich die einzelnen Produkte gut anfühlen. Der Unterschied ist Arithmetik. Eine Produktseite zeigt ein Hauptbild. Eine Kategorieseite mit vierundzwanzig Produkten zeigt mindestens vierundzwanzig, und häufig das Doppelte, sobald Hover-Effekte und Galerievorschauen mitzählen.

Diese Multiplikation ist der Grund, warum Katalogseiten üblicherweise das Langsamste im Shop sind, und zugleich die Seiten, die kommerziell am meisten zählen. Sie stehen zwischen einem ankommenden Besucher und einem Besucher, der etwas zum Kaufen findet.

Das Muster hinter den meisten langsamen Katalogen: Das Theme fordert eine Thumbnail-Größe an, die WordPress nie erzeugt hat, also lädt der Browser den Upload in voller Größe und skaliert ihn in der Seite herunter. Vierundzwanzig Produkte, die jeweils ein Zwei-Megabyte-Foto ausliefern, um es mit dreihundert Pixeln darzustellen, ergeben eine Kategorieseite von fünfzig Megabyte, die schlecht abschneidet, egal wie viel Caching Sie ergänzen.

Warum Katalogseiten sich anders verhalten

Auf einer Listenseite verstärken sich drei Dinge, die es auf einer Produktseite nicht tun.

Menge. Jedes Produkt im Raster steuert mindestens eine Bildanfrage bei. WooCommerce-Standardeinstellungen zeigen häufig sechzehn oder vierundzwanzig pro Seite, und größere Shops erhöhen das, um Paginierung zu reduzieren.

Hover- und Galeriebilder. Viele Themes laden pro Produkt ein zweites Bild für den Hover-Wechsel vor. Das verdoppelt still die Bildanzahl der Seite, und weil das zweite Bild bis zur Interaktion nie sichtbar ist, trägt es nichts zur ersten Darstellung bei und kostet dieselbe Bandbreite.

Layout-Instabilität. Raster, die keinen Platz für Bilder reservieren, verschieben sich, während jedes Bild eintrifft. Auf einer Produktseite ist eine einzelne Verschiebung verkraftbar. Auf einem Raster aus vierundzwanzig erzeugt die kumulierte Bewegung einen schlechten Cumulative-Layout-Shift-Wert, und man spürt sie als Springen der Seite, während man etwas anklicken will.

Die Folge ist, dass Katalogseiten die Core Web Vitals aus Gründen verfehlen, die eine Produktseite nicht hat, und dass die Optimierung des Produkttemplates nichts für sie bewirkt.

Die Größenabweichung, die das meiste verursacht

WordPress erzeugt beim Upload einen Satz Bildgrößen. WooCommerce registriert darüber hinaus eigene. Themes registrieren dann weitere. Was der Browser tatsächlich erhält, hängt davon ab, welche dieser Größen das Template anfordert und ob diese Größe existiert.

Der Fehlerfall ist leise. Fordert ein Theme eine Größe an, die nach dem Upload Ihrer Produkte registriert wurde, hat WordPress sie nie erzeugt, also fällt es auf das Original in voller Größe zurück. Die Seite sieht weiterhin richtig aus, weil der Browser das Bild passend herunterskaliert. Sie bewegt nur mehrere Megabyte, um ein Thumbnail darzustellen.

Sie können das ohne Werkzeuge erkennen. Öffnen Sie eine Kategorieseite, öffnen Sie das Netzwerkpanel und sortieren Sie Bildanfragen nach Größe. Liegen die übertragenen Größen nahe am Gewicht der Original-Uploads statt bei einem Bruchteil davon, wird die falsche Größe ausgeliefert. Vergleichen Sie die intrinsischen Abmessungen eines geladenen Bildes mit dem Platz, den es am Bildschirm einnimmt. Ein Foto, das mit zweitausend Pixeln Breite ankommt, um eine Kachel von dreihundert Pixeln zu füllen, ist das ganze Problem in einer Beobachtung.

Die Lösung ist entweder das Neugenerieren der Thumbnails, damit die angeforderten Größen existieren, oder das Ausliefern der richtigen Größe, sodass sich die Frage gar nicht stellt.

Lazy Loading und wo es schiefgeht

WordPress lädt Bilder standardmäßig verzögert, was Katalogseiten mehr hilft als fast jedem anderen Seitentyp, weil der Großteil eines langen Rasters unter dem sichtbaren Bereich liegt.

Zwei Fehler machen das zunichte.

Die erste Reihe verzögert laden. Die beim Ankommen sichtbaren Bilder sollten sofort geladen werden. Wird das größte davon verzögert geladen, entdeckt der Browser es spät, und da es meist das Largest-Contentful-Paint-Element ist, leidet die Messung direkt. Die meisten Themes machen das falsch, indem sie Lazy Loading einheitlich auf jede Produktkachel anwenden.

Lazy-Loading-Erweiterungen, die gegen die native Implementierung arbeiten. Eine Erweiterung, die ihr eigenes Lazy Loading über das des Browsers legt, erzeugt Bilder, die nie laden, doppelt laden oder flackern. Haben Sie eine Performance-Erweiterung installiert, prüfen Sie, ob sie etwas dupliziert, das der Browser bereits erledigt.

Auslieferung: der Teil, der skaliert

Das Neugenerieren von Thumbnails repariert den heutigen Katalog. Es repariert nicht den nächsten Monat, wenn ein neuer Lieferant Fotos in anderem Seitenverhältnis schickt oder Sie das Theme wechseln und sich die benötigten Größen erneut ändern.

Bilder bei der Auslieferung zu transformieren vermeidet diese Tretmühle. Das Original bleibt wie hochgeladen, und die ausgelieferte Größe entscheidet die URL statt dessen, was vor Monaten erzeugt wurde. Ändern Sie das Raster, ändern Sie den Parameter. Es gibt keinen Neugenerierungslauf und kein Risiko, dass eine fehlende Größe auf das volle Original zurückfällt.

Das passt zu Katalogen besonders gut, weil dasselbe Produktfoto typischerweise in drei Größen erscheint: als Rasterkachel, als Produktseitenbild und als Zoom- oder Lightbox-Ansicht. Unter einem Abrechnungsmodell pro Bild sind das drei Positionen je Produkt. Unter Cloudflares Modell sind es drei eigenständige Varianten, unabhängig davon, wie viele Produkte Sie haben, und Wiederholungsanfragen innerhalb des Monats kosten nichts.

Unser Vergleich von Cloudflare Image Transformations und den WordPress-Bilderweiterungen behandelt die Unterschiede der Abrechnungsmodelle und welches zu welcher Form von Mediathek passt.

Was Sie ändern sollten, der Reihe nach

Arbeiten Sie diese Punkte nacheinander ab. Jeder ist für sich messbar, und in falscher Reihenfolge lässt sich schwer sagen, was geholfen hat.

Finden Sie zuerst heraus, ob Sie die Größenabweichung haben, denn wenn ja, ist nichts anderes wichtig, bis sie behoben ist. Prüfen Sie die übertragene Größe der Rasterbilder gegen den Platz, den sie einnehmen.

Reduzieren Sie dann, wie viele Bilder die Seite anfordert. Schalten Sie Hover-Bilder ab, wenn das Theme sie vorlädt und Sie auf den Effekt verzichten können. Überlegen Sie, ob vierundzwanzig Produkte pro Seite jemandem dienen oder ob sechzehn mit schnellerem Laden besser konvertieren.

Korrigieren Sie dann die Lazy-Loading-Grenze, damit die erste sichtbare Reihe sofort lädt und alles darunter nicht.

Kümmern Sie sich dann um die Auslieferung, damit die ausgelieferten Größen den dargestellten entsprechen und korrekt bleiben, wenn sich der Katalog ändert.

Erst danach hilft Caching nennenswert. Eine langsame Seite zu cachen macht sie gleichmäßig langsam statt schnell, und es ist der Schritt, zu dem Leute zuerst greifen, weil er am einfachsten zu installieren ist.

Für das größere Bild jenseits der Bilder behandelt WooCommerce-Performance die Datenbankabfragen, den Erweiterungs-Overhead und die ungecachten Fragmente, die Shops ebenfalls langsam machen.

Es richtig messen lassen

Shop-Betreiber wissen meist, dass sich der Shop langsam anfühlt, und nicht, welche von einem Dutzend möglicher Ursachen verantwortlich ist. Raten ist teuer, denn die naheliegenden Lösungen sind genau die, die schon versucht wurden.

Mecanik führt WordPress-Performance-Audits durch, die gezielt Katalogseiten messen, statt eine Startseite zu testen und die Sache für erledigt zu erklären, und übernimmt die Umsetzung im Rahmen von WordPress-Entwicklung , wo die Lösung über Konfiguration hinausgeht. Wenn Ihre Kategorieseiten die Besucher verlieren, sollte dort die Messung beginnen.

Siehe auch: WooCommerce Performance: Warum Ihr Shop langsam ist , Website-Migration ohne Traffic-Verlust: Guide 2026 , Cloudflare Image Transformations vs WordPress-Plugins , E-Commerce-Entwicklung: Shopify vs. individuelle Lösung ., GEO für Onlineshops: Produktdaten in KI-Antworten

Häufig gestellte Fragen

Warum sind WooCommerce-Kategorieseiten langsamer als Produktseiten? Eine Produktseite lädt ein Hauptbild. Eine Kategorieseite lädt eines pro Produkt, oft verdoppelt durch Hover-Bilder, sodass vierundzwanzig Produkte achtundvierzig Bildanfragen bedeuten können. Dieselbe Bildbehandlung, die auf einer Produktseite unproblematisch ist, verstärkt sich auf einem Raster stark.

Woran erkenne ich, ob WooCommerce die falsche Bildgröße ausliefert? Öffnen Sie eine Kategorieseite und das Netzwerkpanel und vergleichen Sie die übertragene Größe der Rasterbilder mit den Original-Uploads. Sind sie ähnlich statt ein Bruchteil, fordert das Theme eine Größe an, die WordPress nie erzeugt hat, und das volle Original wird im Browser herunterskaliert.

Soll ich Thumbnails neu generieren oder bei der Auslieferung transformieren? Neugenerieren repariert den aktuellen Katalog, muss aber bei jeder Größen- oder Theme-Änderung wiederholt werden. Transformation bei der Auslieferung bestimmt die Größe über die URL und bleibt daher bei Theme-Wechseln und neuen Uploads korrekt, ohne Neugenerierungslauf.

Hilft oder schadet Lazy Loading bei WooCommerce-Katalogseiten? Es hilft, weil der Großteil eines langen Rasters unter dem sichtbaren Bereich liegt, aber die erste sichtbare Reihe sollte sofort laden. Das größte sichtbare Bild verzögert zu laden verschiebt die Largest-Contentful-Paint-Messung direkt, und das ist eine verbreitete Theme-Voreinstellung.

Wie viele Produkte pro Seite sind für die Performance am besten? Weniger Bilder bedeuten eine schnellere Seite, mehr Paginierung bedeutet mehr Klicks beim Stöbern. Sechzehn bis vierundzwanzig ist üblich. Die Zahl zählt weit weniger als die Frage, ob jedes Bild korrekt dimensioniert ist, denn ein richtig dimensioniertes Raster aus vierundzwanzig schlägt ein überdimensioniertes aus zwölf.