Core Web Vitals im Shop — jede Station hat ihren eigenen Wert.

Warum Shops es schwerer haben.

• Viele Bilder je Seite — eine Kategorieseite zeigt zwanzig Produktfotos.
• Viel Interaktion — Filter, Varianten, Mengen, jede Aktion wird gemessen.
• Nachgeladene Daten — Preise, Verfügbarkeit, Warenkorbstand.
• Fremde Dienste — Zahlungsanbieter, Bewertungen, Versandrechner.
• Personalisierung — und damit eingeschränktes Caching.
• Mehr Plugins als auf einer Inhaltsseite.

Der fünfte Punkt ist der strukturelle Nachteil: Ausgerechnet die Seiten, auf denen Tempo über Umsatz entscheidet — Warenkorb und Kasse — dürfen nicht aus dem Seitencache kommen. Dort muss die Leistung tatsächlich erbracht werden (Caching).

Die Werte entlang des Kaufwegs.

Diese Tabelle ist der Arbeitsplan: Nicht alle Werte überall jagen, sondern je Seitentyp den kritischen. Eine Kategorieseite mit gutem INP und schlechtem LCP ist an der falschen Stelle optimiert worden.

Kategorieseiten: LCP.

Der häufigste und am leichtesten behobene Fund im ganzen Shop: In der Listenansicht werden die großen Detailbilder ausgeliefert statt kleiner Vorschauen.

Das passiert, wenn das Theme die falsche Bildgröße anfordert oder die Größen nach einem Theme-Wechsel nicht neu erzeugt wurden. Zwanzig Produkte mit je einem Megabyte sind zwanzig Megabyte für eine Seite, auf der die Bilder 300 Pixel breit dargestellt werden.

1. Prüfen, welche Bilddatei tatsächlich geladen wird — tatsächliche gegen dargestellte Größe.
2. Bildgrößen im Shop richtig setzen und neu erzeugen lassen.
3. Mehrere Größen hinterlegen, damit das Handy eine kleinere bekommt.
4. Verzögertes Laden für alles unterhalb des ersten Bildschirms — aber nicht für die erste Reihe.
5. Modernes Format statt JPEG.

Punkt vier ist die häufigste Fehlbedienung: Wenn verzögertes Laden pauschal für alle Produktbilder aktiviert ist, trifft es auch die erste Reihe — und damit das LCP-Element (Bilder optimieren, LCP).

Produktseiten: CLS.

Hier springt es am meisten, und zwar aus einem Shop-typischen Grund: Preis, Verfügbarkeit und Versandhinweis werden oft nachgeladen, weil sie aktuell sein müssen und deshalb nicht im Cache liegen dürfen.

Typische Verursacher:

• Preis erscheint verzögert und schiebt alles darunter.
• Verfügbarkeitshinweis taucht auf, mal einzeilig, mal zweizeilig.
• Rabattbanner, das nur bei manchen Produkten kommt.
• Bewertungssterne aus einem externen Dienst.
• Bildergalerie, die beim Laden ihre Höhe ändert.
• Variantenauswahl, die bei Auswahl zusätzliche Felder einblendet.

Das Gegenmittel ist immer dasselbe: Platz vorher reservieren. Eine Mindesthöhe für den Bereich, in dem Preis und Verfügbarkeit erscheinen, löst die ersten drei Punkte auf einen Schlag — auch wenn der Bereich kurz leer aussieht (CLS).

Bei der Galerie: feste Abmessungen am Bild, damit der Platz steht, bevor das Foto da ist.

Filter und Suche: INP.

Die Stelle, an der Shops am häufigsten durchfallen. Jeder Filterklick löst eine Anfrage aus, danach wird die Liste neu aufgebaut — und das ist genau die Interaktion, die gemessen wird.

Was hilft:

1. Sofort sichtbar reagieren: Der Filter wird direkt als aktiv markiert, bevor die Daten da sind.
2. Ladezustand zeigen, statt die Seite einfrieren zu lassen.
3. Mehrfachauswahl sammeln — nicht bei jedem Haken eine Anfrage starten.
4. Nur die Liste erneuern, nicht die ganze Seite.
5. Bei der Suche entprellen: kurz warten statt bei jedem Buchstaben zu fragen.

Punkt fünf ist ein Klassiker: Eine Suche, die bei jedem Tastendruck eine Anfrage stellt, blockiert das Tippen auf schwächeren Geräten spürbar — und erzeugt nebenbei unnötige Serverlast (INP, Filter).

Warenkorb.

Zwei Werte gleichzeitig. Beim INP geht es um die Mengenänderung: Jedes Plus und Minus löst eine Neuberechnung aus, und wenn die Oberfläche währenddessen einfriert, ist der Wert schlecht.

Beim CLS geht es um die Summenzeile: Wenn sich der Betrag ändert und dabei die Zeilenhöhe springt — etwa weil ein Versandhinweis dazukommt oder wegfällt —, verschiebt sich alles darunter.

Lösung für beides: Menge sofort anzeigen und im Hintergrund rechnen; für den Bereich mit Summen und Hinweisen eine feste Mindesthöhe (Warenkorb).

Kasse.

Der kritischste Teil, weil hier Geld hängt — und zugleich der, bei dem Tempo am wenigsten gemessen wird, weil viele Messwerkzeuge die Kasse gar nicht erreichen.

Typische Probleme:

• Jede Feldänderung löst eine vollständige Neuberechnung aus.
• Adressprüfung bei jedem Tastendruck.
• Zahlungsarten-Skripte laden alle gleichzeitig, auch die nicht gewählten.
• Versandberechnung blockiert die Oberfläche.
• Fehlermeldungen verschieben das Layout.

Der dritte Punkt ist der lohnendste: Wenn ein Shop fünf Zahlungsarten anbietet und beim Laden der Kasse alle fünf ihre Skripte starten, ist das vermeidbar. Laden sollte nur, was ausgewählt wurde (Kasse).

Und ein Hinweis zur Messung: Die Kasse gehört ausdrücklich getestet, auch wenn sie nicht in den Felddaten auftaucht — dort sind oft zu wenige Aufrufe für eine eigene Auswertung.

Das Caching-Problem.

Shops haben hier einen strukturellen Nachteil: Warenkorb, Kasse und Konto dürfen nicht zwischengespeichert werden, weil sonst jemand fremde Daten sieht. Ausgerechnet dort muss die Leistung also echt erbracht werden.

Was trotzdem geht:

1. Öffentliche Seiten cachen — Startseite, Kategorien, Produktseiten, Blog.
2. Warenkorbanzeige im Kopfbereich dynamisch nachladen, statt die ganze Seite auszunehmen.
3. Preise und Verfügbarkeit gezielt nachladen, Rest aus dem Cache.
4. Objekt-Cache einrichten — der wirkt auch dort, wo der Seitencache nicht greift.
5. Mit zwei Browsern testen, einer angemeldet, einer nicht.

Punkt zwei und vier zusammen sind der Kniff: Die Produktseite kommt aus dem Cache, nur die wenigen personalisierten Teile werden nachgeladen — und für die Kasse sorgt der Objekt-Cache dafür, dass wenigstens die Datenbankabfragen nicht jedes Mal neu laufen (WooCommerce langsam).

Zahlungsarten und Dienste.

Ein Shop bindet mehr fremde Dienste ein als eine normale Website: Zahlungsanbieter, Versandrechner, Bewertungen, Produktdatenfeeds, Marketingwerkzeuge.

Besonders zu prüfen: Welche davon laden auf jeder Seite, obwohl sie nur an einer Stelle gebraucht werden? Ein Zahlungsanbieter-Skript gehört in die Kasse, nicht auf die Startseite — und ein Bewertungswidget, das bei jedem Produktaufruf eine fremde Verbindung aufbaut, lässt sich serverseitig lösen (Externe Skripte).

Bei Zahlungsanbietern gibt es eine Besonderheit: Manche verlangen, dass ihr Skript auf allen Seiten eingebunden ist — etwa für Betrugserkennung. Das ist nachvollziehbar und gehört trotzdem geprüft, ob es wirklich so sein muss.

Richtig messen.

1. Felddaten je Seitengruppe ansehen, nicht nur für die Domain.
2. Kategorieseite, Produktseite, Warenkorb getrennt betrachten.
3. Kasse von Hand testen — dort gibt es meist keine Felddaten.
4. Mit gedrosseltem Prozessor bedienen, nicht nur ansehen.
5. Angemeldet und als Gast prüfen.
6. Vollständigen Testkauf auf einem älteren Handy.

Punkt sechs ist der ehrlichste Test überhaupt. Wer den eigenen Shop einmal auf einem drei Jahre alten Handy bei mittelmäßigem Empfang vollständig durchkauft, braucht danach keine Prioritätenliste mehr (Mobil).

Reihenfolge.

1. Produktbilder in Listen auf die richtige Größe bringen — größter Hebel, geringster Aufwand.
2. Platz reservieren für Preis, Verfügbarkeit und Hinweise.
3. Fremde Dienste auf die Seiten beschränken, wo sie gebraucht werden.
4. Caching einrichten mit sauberen Ausnahmen.
5. Objekt-Cache für Warenkorb und Kasse.
6. Filter und Suche entprellen und sofort reagieren lassen.
7. Zahlungsskripte erst bei Auswahl laden.
8. Plugins ausmisten.

Die ersten beiden Punkte sind an einem Tag erledigt und verbessern zwei der drei Werte auf den meistbesuchten Seitentypen. Damit fängt man an (Ladezeit optimieren).

Wenn du nicht weiterkommst.

Wenn dein Shop in der Search Console rot ist und du nicht weißt, welche Seitengruppe zuerst. Ich messe deine Seite mit echten Nutzerdaten statt mit einem einzelnen Test, sortiere die Befunde nach Wirkung und behebe die, die zählen: Ladezeit optimieren. Dauerhaft begleitet die WordPress-Wartung — damit neue Inhalte die Werte nicht wieder kaputt machen.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich mache Websites schneller — und zwar messbar, nicht gefühlt. Das heißt: erst messen, dann die zwei oder drei Stellen beheben, die tatsächlich den Unterschied machen, dann noch einmal messen.

Was ich nicht mache: eine Punktzahl schönrechnen. Es gibt Tricks, mit denen ein Testwerkzeug hundert Punkte zeigt, während die Seite für echte Besucher gleich langsam bleibt. Das ist Selbstbetrug, und ich sage dir, wenn jemand dir so etwas verkauft hat.

Ich arbeite mit dem, was du hast — Theme, Plugins, Hoster. Ein Neubau ist manchmal die ehrlichere Antwort, und dann sage ich das auch, statt monatelang an einer Seite zu optimieren, die grundsätzlich falsch gebaut ist.