Analyse der Ausgangslage und Planungsphase
Zu Beginn des Projekts stand eine umfassende Analyse der Performance-Engpässe der beiden Display-Sales-Shops. Obwohl bereits ein Content Delivery Network (CDN) und ein cloudbasiertes Optimierungs-Plugin (NitroPack) im Einsatz waren, blieben die Ladezeiten und die Seitengeschwindigkeit unbeständig. Insbesondere externe All-in-One-Lösungen brachten zwar in Tests teilweise gute PageSpeed-Scores, jedoch erwiesen sie sich im Live-Betrieb als unzuverlässig und führten mitunter zu Darstellungs- und Kompatibilitätsproblemen. Gleichzeitig lief die Website auf einer veralteten Serverinfrastruktur eines sehr limitierten Digital-Ocean-Droplets, was weitere Performance-Limits setzte.
Auf Basis dieser Erkenntnisse entwickelten wir einen Optimierungsplan, der einen Umzug auf einen modernen Hetzner-Hostingtarif sowie den Verzicht auf fragil arbeitende cloudbasierte Optimierungen vorsah. Stattdessen setzten wir auf ein Maßnahmepaket mit lokal gesteuerten Optimierungen und gezielten Codeanpassungen, um eine nachhaltige Beschleunigung der Shops zu erreichen. Zunächst identifizierten wir die größten Bremsen: Neben der Serverleistung waren das vor allem eine Vielzahl eingebundener Drittanbieter-Skripte und Plugins, die das Rendering blockierten und wichtige Kennzahlen wie die Core Web Vitals beeinträchtigten. Hier galt es anzusetzen, um die Nutzererfahrung spürbar zu verbessern.
Serverumzug und lokale Performance-Optimierung
Ein erster entscheidender Schritt war der geplante Serverumzug. Wir migrierten beide WooCommerce-Shops auf eine leistungsfähigere Serverinstanz mit aktueller PHP-Version und ausreichenden Ressourcen. Dies allein senkte die Time to First Byte und schuf die Grundlage für schnellere Reaktionszeiten des Backends. Zudem sorgte es für stabilere Performance unter größerer Ladung. Parallel dazu ersetzten wir das bisherige NitroPack-Setup durch das Caching- und Optimierungs-Plugin WP Rocket. WP Rocket wurde letztendlich vor allem gewählt, weil es über regelmäßige Kompatibilitätsaktualisierungen verfügt. Das Plugin lädt z.B. wöchentlich aktuelle Ausschlusslisten für CSS- und JavaScript-Dateien aus der eigenen Cloud nach, um bekannte Konflikte automatisch zu umgehen – so entfielen viele manuelle Feinabstimmungen und wir konnten uns auf projektspezifische Optimierungen konzentrieren.
Nach der Umstellung auf WP Rocket konfigurierten wir ein umfassendes Caching (Seiten-Cache, Browser-Cache) und aktivierten die Code-Minifizierung sowie Zusammenfassung von CSS und JS, soweit kompatibel. Wichtig war uns hierbei, bewährte Ausschlussregeln zu nutzen: Durch WP Rockets aktuelles Regelwerk wurden z.B. kritische Shop-Skripte oder Third-Party-Ressourcen automatisch von bestimmten Optimierungen ausgenommen, um die Funktionalität nicht zu beeinträchtigen. Insgesamt führte die neue Serverumgebung in Kombination mit lokalem Caching bereits zu deutlich konstanteren Ladezeiten und besserer Stabilität gegenüber der früheren, CDN-gestützten Lösung.
Weiterhin passten wir die Hetzner-Serverkonfiguration sowie kleinere Dinge wie OPCaching speziell an, damit auch mehr direkte PHP-Performance entsteht. Auch kleinere Dinge wie einen Servercron als Ersatz für den WP-Cron zu verwenden haben wir erledigt.
Lokale Alternativen statt externer Tools
Ein weiterer Fokus lag auf dem Ersatz externer Dienste durch lokale, schlanke Alternativen. So wurde den ursprünglich eingebundenen extern per Skript geladenen Cookiebanner eines fremden Anbieters entfernt und durch unser eigenes Plugin WS Cookie Consent ersetzt, das alle Funktionen für die Einwilligungsverwaltung lokal bereitstellt. Auch das Captcha-Plugin wurde mit einem schlankeren lokal arbeitenden ausgetauscht. Diese Umstellungen reduzierten die Abhängigkeiten von Fremdanbietern erheblich – jede externe Einbindung weniger bedeutet weniger HTTP-Requests und schnellere Ladezeiten, was letztlich auch den Core Web Vitals zugutekommt. Zudem behalten wir so die volle Kontrolle über Funktion und Design dieser Elemente (der Cookiebanner wurde an das Branding von Display Sales angepasst).
Performance-Monitoring und kontinuierliche Messung
Um die Auswirkungen unserer Maßnahmen transparent zu machen und langfristig im Blick zu behalten, entwickelten wir ein Performance-Score-Dashboard. Dieses Dashboard aggregiert die Kennzahlen verschiedener Mess-Tools (Google PageSpeed Insights und GTmetrix, ist aber über DataForSEO erweiterbar) und stellt sie dem Kunden übersichtlich dar. So kann Display Sales jederzeit die aktuellen Ladezeiten, Performance-Scores und Core-Web-Vitals-Werte beider Shops einsehen und die Verbesserung gegenüber dem Ausgangszustand nachvollziehen. Das Dashboard aktualisiert sich regelmäßig und dient auch künftig als Monitoring-Werkzeug, um etwaige Performance-Regressionen frühzeitig zu erkennen. Die Einrichtung eines solchen Monitoring-Systems stellt sicher, dass die Performance-Optimierungen nicht nur einmalig erreicht, sondern dauerhaft gehalten und weiter optimiert werden können.
Entfernung von Altlasten
Parallel zu den infrastrukturellen Änderungen haben wir den Code der Websites gezielt bereinigt. Im Child-Theme haben wir zahlreiche kleinere Optimierung geprüft und getätigt. Über die Jahre hatten sich diverse Code-Fragmente und Workarounds angesammelt, von denen einige mittlerweile inkompatibel oder unnötig geworden waren. Wir haben diese Altlasten identifiziert und auskommentiert, um den Code schlanker und wartungsfreundlicher zu gestalten.
Besondere Aufmerksamkeit galt performanzkritischen Theme-Komponenten. So wurde beispielsweise der Startseiten-Slider – eine bekannte Quelle von Ladezeitproblemen – genau analysiert und optimiert. Unnötige Slider-Effekte und Skripte wurden abgeschaltet, die Darstellung wurde so angepasst, dass sie auch ohne initiales JavaScript ansprechend ist, und sämtliche Slider-Bilder werden jetzt verzögert geladen. Insgesamt führte das Theme-Tuning dazu, dass weniger render-blockierende Elemente vorhanden sind und der Browser die Seite schneller aufbauen kann.
JavaScript-Kontrolle und verzögerte Skriptausführung
Der wohl wichtigste Hebel für die Performanceverbesserung war das in den Griff bekommen der Skriptlast. Moderne Websites – insbesondere umfangreiche Shops – binden häufig Dutzende externe Skripte ein (von Tracking über Chatbots über TrustedShops bis zu Payment), was die Ladezeit massiv beeinflusst. Studien zeigen, dass eine durchschnittliche Webseite heute über 35 Third-Party-Skripte lädt und die populärsten davon im Mittel 1,4 Sekunden Blockierzeit verursachen. Bei Display Sales war dies deutlich spürbar: Viele externe Skripte und Bibliotheken blockierten den Hauptthread und verzögerten die visuelle Fertigstellung der Seiten.
Unsere Lösung bestand darin JavaScript erst dann auszuführen, wenn es wirklich benötigt wird. Konkret nutzen wir WP Rockets JS-Verzögerungsfunktion, um die Ausführung aller nicht-kritischen Skripte solange aufzuschieben, bis der Nutzer mit der Seite interagiert (z.B. durch Scrollen oder einen Klick). Dieses Verfahren funktioniert ähnlich wie Lazy Loading, nur eben für Skripte statt Bilder. Direkt beim initialen Seitenaufruf wird somit nur das Nötigste geladen und gerendert; sämtliche heavy JavaScript-Dateien (wie Tracking-Pixel, Widgets, Chat, etc.) bleiben zunächst im Leerlauf. Erst wenn der User anfängt zu scrollen oder zu navigieren, werden diese Skripte nachträglich geladen.
Die Verzögerung der Skripte brachte durchschlagende Verbesserungen: Die Hauptthread-Arbeit und JavaScript-Executionszeit gingen stark zurück, was zu geringerer Total Blocking Time (TBT) und schnellerer First Contentful Paint (FCP) führte. Viele der ehemals in PageSpeed Insights und GTMetrix bemängelten Punkte („Remove unused JavaScript“ oder „Reduce JavaScript execution time“) waren damit gelöst. Wichtig war dabei ein sorgfältiges Feintuning: Einige essenzielle Skripte (z.B. kritische Shop-Funktionen und Inline-Skripte für das Theme) haben wir von der Verzögerung ausgenommen, damit es zu keinerlei Funktionsverlust kommt. WP Rocket erleichtert dies mit seiner One-Click-Exclusion-Liste, die gängige Ausnahmen wie jQuery oder WooCommerce-Kernelemente bereits vorkonfiguriert. Insgesamt jedoch konnten wir den Großteil der Third-Party- und nichtessenziellen Skripte in den Hintergrund verbannen. Das Resultat: Die Seite rendert wesentlich früher und fühlt sich für den Benutzer deutlich schneller und reaktionsfreudiger an, da erst einmal keine unnötigen Skripte stören.
Datenbank-Tuning und Backend-Beschleunigung
Nicht nur an der Frontend-Front haben wir optimiert – auch die Datenbank und das WordPress-Backend wurden von uns beschleunigt. Ein bekannter Flaschenhals bei WordPress ist die wp_options-Tabelle, in der viele Einstellungen und Cache-Daten gespeichert sind. Wir stellten fest, dass sich dort über die Zeit etliche als autoload markierte Einträge angesammelt hatten, die bei jedem Seitenaufruf automatisch geladen wurden. Noch problematischer: Standardmäßig besitzt diese Tabelle keinen Index auf dem Autoload-Feld, was Datenbankabfragen bei vielen Einträgen drastisch verlangsamen kann.
Unsere Maßnahmen bestanden daher darin, die wp_options-Tabelle so gut wie möglich zu säubern (nicht mehr benötigte oder veraltete Options-Einträge zu löschen) und für kritische Abfragen fehlende Indexe hinzuzufügen.
Darüber hinaus wurden gezielt WooCommerce-spezifische Tabellen analysiert und optimiert. Beispielsweise haben wir die Transient-Einträge und Sitzungsdaten bereinigt (verwaiste WooCommerce Sessions und abgelaufene Transients gelöscht), um die Tabellen klein zu halten. Wo sinnvoll, wurden zusätzliche Indexe auf häufig abgefragte Spalten (z.B. in der wp_postmeta oder WooCommerce-Bestelltabellen) gesetzt. All diese Eingriffe resultieren in einem merklich flinkeren Backend – Admin-Seiten laden schneller, und auch im Frontend profitiert insbesondere die erste Anfrage (die ja bei manchen WC-Elementen uncached auf die DB zugreift) von der optimierten Datenbank.
Das waren die größten Änderungen, aber auch Klassiker der DB-Bereinigung wie das Entfernen nicht mehr genutzter Tabellen und WC-Transients haben wir erledigt.
Wir haben uns dabei fürs Erste in diesem Shop gegen persistentes Object Caching entschieden, da die Pluginverwendung etc. hier sehr divers ist, weshalb die vollständige Kompatibilität nicht ganz gewährleistet werden kann. Es ist ein offener Punkt, den wir nach und nach auf Staging dann testen werden. Object Caching kann einen netten, wenn auch manchmal kleinen Boost bringen (da der DB-Server schnell genug ist), aber es ist nicht einfach so universell einsetzbar. Wir testen es dabei über Redis, SQLite und APCu.
Bild- und Medienoptimierung
Im Bereich der Medien haben wir mehrere Stellschrauben genutzt, um die Seiten schlanker zu machen. Zunächst kam das Plugin EWWW Image Optimizer zum Einsatz, um sämtliche Bilder verlustfrei zu komprimieren und parallel WebP-Versionen zu generieren. So werden Grafiken je nach Browser automatisch im modernen WebP-Format ausgeliefert, was die Dateigrößen deutlich reduziert. Beim Lazy-Loading der Bilder setzten wir allerdings nicht auf EWWWs eigenes Skript, sondern nutzten die Lazy-Load-Funktion von WP Rocket – diese erwies sich in unseren Tests als etwas performanter und fügt sich besser in das Gesamtoptimierungskonzept ein. Das bedeutet, alle nicht im Viewport befindlichen Bilder werden erst nach und nach beim Scrollen geladen, was den Largest Contentful Paint verbessert und unnötige Bandbreite spart.
Weiterhin haben wir die von WordPress 6.x eingeführte automatische Zuweisung von fetchpriority="high" bei bestimmten Bildern kritisch geprüft. Google PageSpeed Insights war nämlich anderer Meinung als der WP-Algorithmus, welches Bild als wichtigstes Element zuerst geladen werden sollte. Daher haben wir die Priorisierungslogik etwas angepasst.
Da hier und da YouTube-Videos als Produktbeschreibungen eingebunden sind, werden diese nun erst nach Klick aufs lokal gecachte Thumbnail geladen. Das bedeutet natürlich auch, dass YouTubes Server erst dann geladen werden, was auch DSGVO-optimierungstechnisch eine sauberere Lösung darstellt.
Durch diesen Mix an Medien-Optimierungen laden die Seiten von Display Sales nun trotz der bildreichen Produktpräsentation sehr effizient.
Entfernen unnötiger Funktionen und Skripte
Ein nicht so kleiner Erfolgsfaktor war auch die Reduktion von Ballast – wir haben die nicht zwingend erforderlichen Funktionen so viel wie möglich deaktiviert, die WordPress und WooCommerce von Haus aus mitbringen und die Performance kosten. Ebenfalls abgeschaltet haben wir die WooCommerce-Admin-Features im Dashboard (wie Status-Widget, Marktplatz-Empfehlungen, Benachrichtigungen etc.), was die Admin-Oberfläche übersichtlicher und schneller macht.
Auf WordPress-Ebene haben wir ähnliche Aufräumarbeiten vorgenommen: Die standardmäßige Emoji-Ladefunktion und Embeds wurden deaktiviert, um unnötige HTTP-Anfragen zu sparen. Zudem wurde die Heartbeat-API-Frequenz im Backend reduziert, damit Hintergrund-Anfragen den Server weniger belasten. Jede entfernte Plugin- oder Core-Funktion bedeutete weniger Code, der geladen oder verarbeitet werden muss – was sich unmittelbar in besseren Ladezeiten äußert.
powered by 