Meine Adobe-Commerce-Performance-Checkliste

Langsame Seiten kosten auf jeder Plattform Umsatz, und die Ursachen wiederholen sich von Shop zu Shop. Ich habe bisher ausschließlich mit Magento und Adobe Commerce gearbeitet, deshalb beziehen sich die folgenden Details auf Adobe Commerce. Die Reihenfolge der Prüfpunkte und die Überlegung dahinter gelten für die meisten Stacks.

Jedes Performance-Projekt beginnt gleich. Bevor ich Code anfasse, gehe ich diese zwölf Prüfpunkte auf einer Staging-Kopie und im Produktions-Monitoring durch. Dieser Durchgang erklärt meist den Großteil der langen Ladezeiten und zeigt mir, wofür ich die erste Arbeitswoche einsetze.

Die Reihenfolge ist wichtig. Infrastrukturprobleme verdecken alles, was darüber liegt. Wenn Anfragen am Full-Page-Cache vorbeigehen, wirken die Kategorieseiten auch nach viel Frontend-Arbeit nicht schnell. Deshalb beginne ich unten im Stack und arbeite mich nach oben.

Infrastruktur

1. Trefferquote des Full-Page-Caches. Varnish oder der integrierte Full-Page-Cache. Ich prüfe die Trefferquote je Seitentyp, denn eine hohe Quote auf der Startseite kann verdecken, dass Kategorieseiten bei jedem Request am Cache vorbeigehen. Liegt sie auf Kategorieseiten unter 80 % (meine eigene Faustregel), beheben Sie das zuerst. Die üblichen Ursachen sind Cookies oder Query-Parameter, die den Cache-Key verändern, und Blöcke, die das Caching für die ganze Seite abschalten. Eine dritte Ursache sind Cache-Tags, die nach dem 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, Anzahl der Evictions und die Eviction-Policy. Evictions in der Session-Instanz bedeuten, dass Kunden ihre Warenkörbe verlieren; 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, ob der Suchindex 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 unbegrenzt. „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 in Produktion aus dem Datenbank-Monitoring. Die häufigsten Ursachen sind eigene Tabellen ohne Indizes, danach Collections, die in Schleifen geladen werden, und eigene Attribute, die in jede Produktliste gejoint werden. Ein einziger fehlender Index auf einer viel genutzten eigenen Tabelle kann eine Seite um Sekunden verlangsamen.

7. Drittanbieter-Module im kritischen Pfad. Plugins und Observer, die beim Laden von Produkten, bei der Preisdarstellung, im Warenkorb und im Checkout greifen, laufen bei fast jedem Request. Ich liste sie auf, deaktiviere jedes einzeln in einer Staging-Kopie und messe den Unterschied. Meist bleiben zwei oder drei Module übrig, auf die fast die gesamte Backend-Zeit entfällt. Für jedes entscheide ich, ob ich es konfiguriere, ersetze oder entferne.

8. Layout- und Block-Cache. Ein einziger Block mit cacheable="false" in einer Layout-Datei sorgt dafür, dass der Full-Page-Cache die ganze Seite nicht mehr cachen kann. Ich suche danach in der Codebasis und in jedem installierten Modul. Personalisierte Inhalte gehören in private Content-Sections, die per JavaScript geladen werden.

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 vermeiden den Großteil dieses Problems, 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, die eine Seite anfordert; 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 wer das größte Bild der Seite verzögert lädt, verzögert auch den Largest Contentful Paint.

12. Drittanbieter-Tags. Analytics, Chat, Bewertungen, A/B-Tests und Marketing-Pixel. Jeder Tag-Manager-Container kostet im Main Thread messbar Zeit. Ich liste alle Tags auf und kläre für jedes, wem es gehört und ob jemand seine Daten noch nutzt. Tags, die niemand nutzt, entferne ich; den Rest lade ich erst nach der Einwilligung und, wo möglich, erst nach der ersten Interaktion.

Was die Checkliste Ihnen bringt

Nach den zwölf Prüfpunkten habe ich eine Rangliste der Probleme. Für jedes steht fest, was es kostet und an welcher Stelle es behoben wird. Bei den meisten Shops sind drei oder vier Punkte wirklich relevant, der lange Rest fällt kaum ins Gewicht. Diese Rangliste 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 Sie die Verbesserung in den Zahlen sehen.

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