Die kurze Antwort: Ladezeit ist keine technische Kennzahl, sondern ein Multiplikator für den ganzen Funnel. Sie wirkt gleichzeitig auf Conversion, Suchposition und den Preis des bezahlten Klicks. Es ist die einzige Verbesserung, die sich nicht „nur für einen Kanal“ umsetzen lässt – sie wirkt überall auf einmal.
Was Google genau misst
Seit 2020 gibt es drei Kennzahlen, die Google von echten Nutzern Ihrer Seite erhebt und nicht im Labor. Sie heißen Core Web Vitals, und die Schwellen sehen so aus:
| Kennzahl | Was sie in Alltagssprache heißt | Schwelle „gut“ |
|---|---|---|
| LCP | Wann der Hauptblock der Seite erscheint – Produktfoto, Überschrift | bis 2,5 s |
| INP | Wie schnell die Seite auf Klicks reagiert | bis 200 ms |
| CLS | Wie stark der Inhalt beim Laden springt | bis 0,1 |
Ein Detail, das regelmäßig untergeht: Es zählt das 75. Perzentil. Es genügt nicht, dass die Seite „bei mir am Laptop schnell aufgeht“ – drei Viertel der echten Besuche, einschließlich alter Android-Geräte im Mobilfunknetz, müssen innerhalb der Schwelle liegen.
In WordPress-Shops fällt meist INP durch: Die Seite wird gezeichnet, reagiert aber noch eine Sekunde lang nicht auf Klicks, weil im Hintergrund weiter Skripte von Plugins, Chat, Pixeln und Warenkorb laufen. Der Nutzer liest das nicht als „langsame Seite“, sondern als „die Seite ist kaputt“ – und geht.
Was das in Geld kostet
Die ehrlichste öffentliche Illustration ist die Vodafone-Fallstudie auf web.dev: Ein A/B-Test mit zwei optisch identischen Seitenversionen zeigte, dass eine um 31 % verbesserte LCP 8 % mehr Umsatz brachte. Ohne Redesign, ohne neue Aktion – allein durch Geschwindigkeit.
Rechnen Sie das wie im ersten Thema auf Ihre eigenen Zahlen um: Macht der Shop 40 000 € im Monat, sind 8 % jeden Monat 3200 €. Die Arbeit an der Ladezeit ist einmalig.
Es gibt noch einen zweiten Effekt, der selten gerechnet wird: Ladezeit verändert die Werbekosten. Eine langsame Landingpage verschlechtert den Qualitätsfaktor in Werbesystemen und erhöht den Klickpreis. Sie zahlen doppelt – weniger Menschen kommen an, und jede Ankunft hat mehr gekostet.
Warum ausgerechnet WooCommerce langsamer wird
WooCommerce selbst ist nicht langsam. Langsam macht es die typische Konstruktion drumherum. Aus meinen Audits ist die Reihenfolge der Verdächtigen fast immer diese:
- Theme mit Page Builder. Ein Mehrzweck-Theme mit visuellem Builder zieht Dutzende CSS- und JS-Dateien auf jede Seite – darunter solche, die nur auf der Startseite gebraucht werden. Das ist die häufigste und am meisten unterschätzte Ursache.
- Plugins, die überall laden. Plugins für Slider, Formular, Bewertungen und Versandrechner registrieren ihre Skripte im ganzen Shop und nicht nur dort, wo sie benutzt werden.
- Kein Seiten-Cache. Jeder Aufruf einer Kategorie ist ein voller PHP-Zyklus plus Datenbankabfragen. Auf Shared Hosting für 5 € im Monat sind das 1,5–3 Sekunden bis zum ersten Byte.
- Warenkorb-Fragmente. WooCommerce ruft standardmäßig auf jeder Seite
wc-ajax=get_refreshed_fragmentsauf, um den Warenkorbzähler zu aktualisieren. Auf einer sonst gecachten Seite ist das die einzige nicht cachebare Anfrage, die den Rest blockiert. - Bilder in Originalgröße. Der Fotograf lieferte JPEGs mit 4000 px und je 3 MB, und sie wurden unverändert hochgeladen. Der Browser lädt 3 MB, um ein Bild mit 600 px Breite zu zeigen.
- Externe Skripte. Chat, Pixel, Karten, Bewertungs-Widgets. Jedes wirkt harmlos, zusammen fressen sie INP.
Was Sie in der Reihenfolge des Nutzens beheben
Die Reihenfolge ist wichtig – das Günstigste und Wirksamste zuerst:
- Bilder – Umwandlung in WebP/AVIF, passende Größen ausliefern, alles unterhalb des ersten Bildschirms lazy laden, aber nicht das Hauptfoto des Produkts (das verschlechtert die LCP)
- Seiten-Cache + Object-Cache – statisches Caching von Kategorien und Produktseiten, Redis oder Memcached für Datenbankabfragen
- Warenkorb-Fragmente abschalten, wo sie nicht nötig sind, oder durch eine leichte Aktualisierung des Zählers ersetzen
- Plugin-Durchsicht – Ungenutztes entfernen, das Laden von Skripten auf Seiten beschränken, die sie wirklich brauchen
- Externe Skripte verzögern – Chat und Pixel nach einer Interaktion laden und nicht im
<head> - Schriften – eigenes Hosting,
font-display: swap, nur die genutzten Schnitte - Hosting – wenn TTFB nach alledem immer noch über 600 ms liegt, liegt das Problem in der Hardware, nicht im Code
Die ersten drei Punkte bringen meist 70 % des Effekts und dauern wenige Tage. Die technischen Details zu jedem davon stehen im Nachbarleitfaden: Core Web Vitals, Bilder, Schriften und Skripte sowie Caching.
Einschub für Entwickler
- Aktivieren Sie HPOS. High-Performance Order Storage verlagert Bestellungen von
wp_posts/wp_postmetain eigene Tabellen. In einem Shop mit Zehntausenden Bestellungen verändert das sowohl das Backend als auch jede Bestellabfrage. - Messen Sie Felddaten, nicht Labordaten. Der Labormodus von PageSpeed Insights ist zum Debuggen praktisch, die Bewertung stammt aber aus den CrUX-Felddaten. Der Core-Web-Vitals-Bericht in der Search Console sagt die Wahrheit.
- Suchen Sie Long Tasks, nicht das „Seitengewicht“. INP töten konkrete Handler: das Neuzeichnen des Warenkorbs, das Slider-Skript, synchroner Analytics-Code. Profilieren Sie im Performance-Tab, statt Kilobytes zu zählen.
- Prüfen Sie die Autoload-Optionen.
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes'– sind das Megabytes, schleppt jede Anfrage diesen Ballast mit. Meist sind es Überreste gelöschter Plugins. - Verifizieren Sie mit mobilem Profil und gedrosseltem Netz und CPU. Auf Ihrem MacBook ist es immer schnell.
Wann die Theme-Optimierung nicht mehr hilft
Es gibt eine Grenze, ab der nichts mehr zu verbessern ist: Theme und Plugins erzwingen ein Mindestmaß an Arbeit, das sich nicht entfernen lässt, ohne den Shop zu beschädigen. Anzeichen, dass Sie sie erreicht haben:
- Die mobile LCP hängt bei 3–4 Sekunden, obwohl Bilder und Cache schon erledigt sind
- Jedes neue Plugin verschlechtert die Kennzahlen deutlich
- Sie müssen zwischen „schnell“ und „hat die nötigen Funktionen“ wählen
An diesem Punkt bleiben zwei Wege. Der erste ist, die Funktionalität zu beschneiden: den Builder aufgeben, Templates neu schreiben, einen Teil der Plugins entfernen. Der zweite ist, Website und Backend zu trennen: WooCommerce für Produkte, Bestellungen und das Backend zu behalten und das Frontend separat auf einem schnellen Stack zu bauen. Wie das funktioniert und wann es sich lohnt, beschreibt die Seite WooCommerce und Headless – einschließlich einer ehrlichen Darstellung der Fälle, in denen es sich nicht lohnt. Eine fertige Lösung dieser Art ist NextWoo, eine Next.js-Website auf einem bestehenden WooCommerce.
Praktischer Test
- Ich habe den Core-Web-Vitals-Bericht in der Google Search Console geöffnet und die mobilen Adressen angesehen
- Ich kenne LCP, INP und CLS aus Felddaten und nicht nur aus dem Labortest
- Ich habe das Gewicht des Hauptproduktfotos geprüft – unter 150–200 KB
- Ich habe TTFB auf einer Kategorieseite geprüft – unter 600 ms
- Ich habe die Warenkorb-Fragmente abgeschaltet oder eingeschränkt
- Ich habe die Plugin-Liste durchgesehen: Jedes ist entweder nötig oder entfernt
- Ich habe berechnet, was 8 % mehr Umsatz in meinem Geld wert sind
Wie es weitergeht
Ein schneller Shop ist eine Voraussetzung, kein Kaufgrund. Als Nächstes landet der Besucher auf der Produktseite und entscheidet, ob er Ihnen genug vertraut, um Geld zu zahlen: die Produktseite, die verkauft.
Wenn Sie das jemandem übergeben möchten: Website beschleunigen – Audit, nach Priorität sortierte Arbeitsliste und ein Festpreis für die Umsetzung.