Meine Adobe-Commerce-Performance-Checkliste

Jedes Performance-Projekt beginnt gleich. Bevor ich Code anfasse, gehe ich die folgende Liste auf einer Staging-Kopie und im Produktions-Monitoring durch. Sie erklärt meist den Großteil der Langsamkeit und zeigt mir, wohin die erste Arbeitswoche gehen sollte.

Die Reihenfolge ist wichtig. Infrastrukturprobleme verdecken alles, was darüber liegt: Wenn der Full-Page-Cache nicht trifft, macht keine Frontend-Arbeit die Kategorieseiten gefühlt schnell. Deshalb beginne ich unten im Stack und arbeite mich nach oben.

Die Schwellenwerte unten sind meine Faustregeln, keine offiziellen Zahlen. Sie markieren, wo ich anfange, Fragen zu stellen, keine harten Grenzen.

Infrastruktur

1. Trefferquote des Full-Page-Cache. Varnish oder der integrierte Full-Page-Cache. Ich prüfe die Trefferquote je Seitentyp und nicht eine globale Zahl, denn eine gesunde Startseite kann eine Kategorieseite verdecken, die bei jedem Request verfehlt. Liegt sie auf Kategorieseiten unter 80 %, beheben Sie das zuerst. Die üblichen Ursachen sind Cookies oder Query-Parameter, die den Cache-Key verändern, Blöcke, die das Caching für die ganze Seite abschalten, und Cache-Tags, die beim Speichern eines Produkts weit mehr leeren als nötig.

2. Redis für Sessions und Cache. Sessions und Cache gehören in getrennte Redis-Instanzen, damit ein voller Cache keine Kunden-Sessions verdrängt. Ich prüfe Speicherverbrauch, Evictions und die Eviction-Policy. Evictions in der Session-Instanz bedeuten verlorene Warenkörbe; Evictions in der Cache-Instanz bedeuten, dass der Shop dieselben Daten immer wieder neu aufbaut.

3. Zustand der Suchmaschine. Heap von OpenSearch oder Elasticsearch, Anzahl der Shards und das Slow-Log. Ein zu kleiner Heap zeigt sich unter Last in langsamer Filternavigation und langsamen Suchergebnissen, lange bevor Fehler auftauchen. Außerdem prüfe ich, dass der Suchindex nicht mehrmals am Tag für den gesamten Katalog neu aufgebaut wird.

4. PHP-FPM und OPcache. Genug Worker für Lastspitzen, aber nicht so viele, dass der Server zu swappen beginnt. OPcache muss groß genug für die gesamte Codebasis sein, einschließlich des generierten Codes. Läuft er voll, kompiliert PHP Dateien bei jedem Request neu, und die Antwortzeiten steigen ohne erkennbaren Grund. Ich prüfe opcache.memory_consumption, opcache.max_accelerated_files und die Trefferquote.

Backend

5. Indexer. Alles auf „Update by Schedule“, Cron läuft jede Minute, kein Indexer hängt in „processing“ und keine Changelog-Tabelle wächst ohne Grenze. „Update on Save“ verlangsamt jedes Speichern im Admin und kann zu Stoßzeiten Tabellen sperren. Ein hängender Indexer erklärt außerdem viele Fälle, in denen Preise oder Bestände im Shop falsch aussehen.

6. Slow-Query-Log. Ich aktiviere es auf Staging mit Daten in Produktionsgröße oder lese es aus dem Datenbank-Monitoring in Produktion. Eigene Tabellen ohne Indizes sind der übliche Verursacher, gefolgt von Collections, die in Schleifen geladen werden, und eigenen Attributen, die in jede Produktliste gejoint werden. Ein einziger fehlender Index auf einer viel genutzten eigenen Tabelle kann einer Seite Sekunden hinzufügen.

7. Drittanbieter-Module im kritischen Pfad. Plugins und Observer auf Produktladen, Preisdarstellung, Warenkorb und Checkout laufen bei fast jedem Request. Ich liste sie auf, deaktiviere jedes einzeln in einer Staging-Kopie und messe den Unterschied. Meist bleibt eine kurze Liste von zwei oder drei Modulen, die den Großteil der Backend-Zeit kosten, und für jedes eine Entscheidung: konfigurieren, ersetzen oder entfernen.

8. Layout- und Block-Cache. Ein einziger Block mit cacheable="false" in einer Layout-Datei macht die ganze Seite für den Full-Page-Cache uncachebar. Ich suche danach in der Codebasis und in jedem installierten Modul. Personalisierte Inhalte gehören in private Content-Sections, die per JavaScript geladen werden, nicht in uncachebare Blöcke.

Frontend

9. JavaScript-Umfang. Bei einem Luma-basierten Theme zähle ich die RequireJS-Module, die eine Produktseite lädt, und schaue, wie viel Skript läuft, bevor die Seite bedienbar ist. Bundling und Minifizierung helfen etwas; Module zu entfernen, die niemand nutzt, hilft mehr. Hyvä-Shops umgehen dieses Problem weitgehend, weil das Theme weder RequireJS noch den JavaScript-Stack von Luma nutzt.

10. Kritisches CSS und Schriften. Höchstens ein render-blockierendes Stylesheet, kritisches CSS inline für den ersten Bildschirm und Schriften mit font-display: swap, damit Text sichtbar ist, während die Schriften laden. Ich zähle außerdem die Schriftdateien und -schnitte pro Seite; eine lange Liste zeigt, dass das Design gewachsen ist, ohne dass jemand auf die Kosten geachtet hat.

11. Bilder. Passende Größen für jeden Breakpoint, WebP oder AVIF, feste Breite und Höhe, damit das Layout nicht springt, und Lazy Loading unterhalb des ersten Bildschirms. Das Hauptproduktbild und die erste Reihe der Kategorie-Kacheln sollten sofort laden, denn ein verzögertes größtes Bild verzögert auch den Largest Contentful Paint.

12. Drittanbieter-Tags. Analytics, Chat, Bewertungen, A/B-Tests und Marketing-Pixel. Jeder Tag-Manager-Container kostet echte Millisekunden auf dem Main Thread. Ich liste jeden Tag auf und kläre, wem er gehört und ob jemand seine Daten noch nutzt. Den Rest laden Sie, wo möglich, erst nach der Einwilligung und nach einer Interaktion.

Was die Checkliste Ihnen bringt

Nach den zwölf Prüfpunkten habe ich eine priorisierte Liste: was kaputt ist, was es kostet und was zuerst behoben wird. Die meisten Shops haben drei oder vier Punkte, die zählen, und einen langen Rest, der kaum zählt. Diese Liste wird zum Plan für die Umsetzungsphase, mit Aufwand in Stunden, damit Sie entscheiden können, was sich lohnt.

Die Checkliste ersetzt keine Messung. Ich erfasse echte Nutzerdaten auf den umsatzrelevanten Seiten vor und nach jeder Änderung, damit die Verbesserung in Zahlen sichtbar wird und nicht nur als Gefühl, dass der Shop schneller ist.

Wenn Sie diese Prüfung mit schriftlichem Bericht für Ihren Shop wünschen, sehen Sie sich die Performance-Optimierung an.