Ausgangslage und Analyse
Am Anfang stand eine genaue Analyse der beiden Shops von Display Sales. Im Einsatz waren bereits ein Content Delivery Network (CDN) und NitroPack, ein Optimierungsplugin, das in der Cloud arbeitet. Trotzdem schwankten die Ladezeiten stark.
Solche Komplettlösungen erzielten in Tests zwar teils gute PageSpeed Werte. Im Live Betrieb arbeiteten sie aber unzuverlässig und verursachten Darstellungsfehler und Konflikte. Dazu kam als Server ein sehr knapp bemessenes Droplet bei DigitalOcean, das die Leistung zusätzlich begrenzte.
Unser Plan für die Performance Optimierung sah deshalb zwei Dinge vor: den Umzug auf einen aktuellen Hostingtarif bei Hetzner und den Verzicht auf die anfälligen Optimierungen aus der Cloud. Stattdessen setzten wir auf lokale Maßnahmen und gezielte Änderungen am Code. Die größten Bremsen waren neben dem Server viele Skripte und Plugins von Drittanbietern, die das Rendering blockierten und die Core Web Vitals verschlechterten.
Serverumzug und lokales Caching
Der erste große Schritt war der Serverumzug. Beide WooCommerce Shops laufen jetzt auf einem stärkeren Server mit aktueller PHP Version. Allein das senkte die Time to First Byte, beschleunigte das Backend und hielt die Performance auch unter höherer Last stabil.
Parallel haben wir NitroPack durch WP Rocket ersetzt. Den Ausschlag gaben die regelmäßigen Updates zur Kompatibilität: WP Rocket lädt jede Woche aktuelle Ausschlusslisten für CSS und JavaScript nach und umgeht so bekannte Konflikte automatisch. Dadurch blieb mehr Zeit für Optimierungen, die nur diese Shops betreffen.
In WP Rocket haben wir Seiten und Browser Cache eingerichtet und CSS und JavaScript minifiziert und zusammengefasst, soweit das ohne Fehler möglich war. Kritische Shop Skripte und Ressourcen von Drittanbietern nimmt das Regelwerk von WP Rocket automatisch von bestimmten Optimierungen aus. Schon der neue Server und das lokale Caching sorgten zusammen für deutlich gleichmäßigere Ladezeiten als die frühere Lösung mit CDN.
Auf dem Hetzner Server haben wir außerdem die Konfiguration angepasst, etwa den OPcache für mehr PHP Leistung. Den WP-Cron ersetzt ein echter Cronjob auf dem Server.
Lokale Lösungen statt externer Dienste
Externe Dienste haben wir, wo möglich, durch schlanke lokale Lösungen ersetzt. Den Cookie Banner eines fremden Anbieters, der per externem Skript geladen wurde, übernimmt jetzt unser eigenes Plugin WS Cookie Consent. Es verwaltet alle Einwilligungen lokal und ist an das Design von Display Sales angepasst. Auch das Captcha arbeitet jetzt lokal, mit einem schlankeren Plugin.
Jede externe Einbindung weniger bedeutet weniger HTTP Anfragen und kürzere Ladezeiten, was den Core Web Vitals zugutekommt. Zudem behalten wir die volle Kontrolle über Funktion und Design dieser Elemente.
Dashboard für Ladezeiten und Core Web Vitals
Damit Display Sales die Wirkung der Maßnahmen jederzeit nachvollziehen kann, haben wir ein eigenes Dashboard entwickelt. Es bündelt Messwerte aus Google PageSpeed Insights und GTmetrix und lässt sich über DataForSEO erweitern. Ladezeiten, Performance Werte und Core Web Vitals beider Shops sind dort auf einen Blick sichtbar, jeweils im Vergleich zum Ausgangszustand.
Das Dashboard aktualisiert sich regelmäßig. So fallen Verschlechterungen früh auf, und die erreichten Ladezeiten bleiben auch nach künftigen Änderungen im Blick.
Altlasten im Theme entfernt
Parallel haben wir den Code der Shops aufgeräumt. Im Child Theme hatten sich über die Jahre viele Codefragmente und Workarounds angesammelt, von denen einige nicht mehr nötig oder sogar inkompatibel waren. Diese Altlasten haben wir geprüft und auskommentiert, damit der Code schlanker und leichter wartbar wird.
Besonders genau haben wir uns den Slider auf der Startseite angesehen, eine häufige Ursache für lange Ladezeiten. Unnötige Effekte und Skripte sind abgeschaltet, der Slider sieht auch ohne JavaScript beim ersten Laden gut aus, und seine Bilder laden verzögert. So blockieren weniger Elemente das Rendering, und der Browser baut die Seite schneller auf.
JavaScript erst bei Bedarf laden
Der größte Hebel war die Last durch JavaScript. Große Shops binden oft Dutzende externe Skripte ein, von Tracking über Chats und Trusted Shops bis zu Zahlungsanbietern. Laut SpeedCurve lädt eine durchschnittliche Website mehr als 35 Skripte von Drittanbietern. Die zehn beliebtesten davon blockieren den Seitenaufbau im Mittel 1,4 Sekunden. Auch bei Display Sales blockierten viele externe Skripte den Hauptthread und verzögerten den Aufbau der Seiten.
Unsere Lösung: JavaScript läuft erst, wenn es gebraucht wird. Mit der verzögerten Ausführung von JavaScript in WP Rocket warten alle Skripte, die nicht sofort nötig sind, bis Besucher scrollen oder klicken. Das funktioniert wie Lazy Loading, nur für Skripte statt Bilder. Beim ersten Aufruf lädt der Browser nur das Nötigste, schwere Dateien wie Tracking Pixel, Widgets oder Chat folgen später.
Die Wirkung war deutlich. Die Arbeit im Hauptthread und die Ausführungszeit von JavaScript gingen stark zurück, Total Blocking Time (TBT) und First Contentful Paint (FCP) verbesserten sich. Viele Hinweise aus PageSpeed Insights und GTmetrix, etwa „Remove unused JavaScript“ oder „Reduce JavaScript execution time“, waren damit erledigt.
Wichtig war das Feintuning. Kritische Shop Funktionen und Inline Skripte des Themes haben wir von der Verzögerung ausgenommen, damit nichts ausfällt. Dabei half die vorkonfigurierte Ausnahmeliste von WP Rocket für jQuery und zentrale Elemente von WooCommerce. Den Großteil der Skripte von Drittanbietern konnten wir trotzdem nach hinten verschieben, und die Seiten fühlen sich für Besucher spürbar schneller an.
Datenbank und Backend beschleunigt
Auch Datenbank und WordPress Backend haben wir beschleunigt. Ein bekannter Flaschenhals ist die Tabelle wp_options, in der viele Einstellungen und Cache Daten liegen. Dort hatten sich viele Einträge mit Autoload angesammelt, die bei jedem Seitenaufruf mitgeladen werden. Hinzu kommt, dass die Tabelle standardmäßig keinen Index auf dem Feld für Autoload hat. Laut Dokumentation von WooCommerce kann das Abfragen stark verlangsamen.
Wir haben die Tabelle deshalb so weit wie möglich bereinigt und für kritische Abfragen fehlende Indizes ergänzt. Außerdem haben wir die Tabellen von WooCommerce geprüft und verwaiste Sessions sowie abgelaufene Transients gelöscht. Auf häufig abgefragte Spalten haben wir zusätzliche Indizes gesetzt, etwa in wp_postmeta und den Bestelltabellen. Nicht mehr genutzte Tabellen sind ebenfalls entfernt.
Das Ergebnis ist ein spürbar schnelleres Backend. Auch im Frontend wird die erste Anfrage schneller, die bei manchen Elementen von WooCommerce ohne Cache auf die Datenbank zugreift.
Auf persistentes Object Caching haben wir vorerst verzichtet. Bei den vielen eingesetzten Plugins können wir die Kompatibilität noch nicht sicher zusagen. Wir testen das schrittweise auf einer Staging Kopie mit Redis, SQLite und APCu, denn Object Caching bringt nicht in jeder Umgebung einen Vorteil.
Bilder und Videos optimiert
Bei den Medien haben wir mehrere Stellschrauben genutzt. Das Plugin EWWW Image Optimizer komprimiert alle Bilder verlustfrei und erzeugt WebP Versionen, die jeder Browser mit WebP Unterstützung automatisch erhält. Für Lazy Loading nutzen wir dagegen WP Rocket, das in unseren Tests etwas schneller war und besser zum Gesamtkonzept passt. Bilder außerhalb des sichtbaren Bereichs laden erst beim Scrollen, was den Largest Contentful Paint verbessert.
Außerdem haben wir geprüft, welchen Bildern WordPress automatisch fetchpriority="high" gibt. PageSpeed Insights hielt ein anderes Bild für das wichtigste Element als WordPress, deshalb haben wir die Priorisierung angepasst.
YouTube Videos in Produktbeschreibungen laden erst nach einem Klick auf ein lokal gespeichertes Vorschaubild. Erst dann nimmt der Browser Kontakt zu den Servern von YouTube auf, was auch dem Datenschutz hilft. So laden die Seiten trotz vieler Produktbilder schnell.
Unnötige Funktionen abgeschaltet
Mehr als erwartet brachte das Abschalten von Ballast. WordPress und WooCommerce bringen Funktionen mit, die Leistung kosten, aber nicht gebraucht werden. Im Dashboard haben wir Funktionen von WooCommerce Admin wie Status Widget, Empfehlungen aus dem Marktplatz und Benachrichtigungen deaktiviert. Das Backend ist dadurch übersichtlicher und schneller.
In WordPress selbst sind das Laden der Emojis und die Embeds abgeschaltet, und die Heartbeat API meldet sich im Backend seltener. Jede abgeschaltete Funktion bedeutet weniger Code und weniger Anfragen, und damit kürzere Ladezeiten.
