--- title: "Beispielbericht eines Performance-Audits" description: "Das vollständige Ergebnis eines Magento-Performance-Audits an einem fiktiven Shop: elf Befunde, jeder mit seinem Beleg, den Kosten der Behebung und einem nach Ertrag sortierten Plan. Am Ende stehen die Prüfbefehle, damit Sie dieselben Checks auf Ihrem Shop laufen lassen können." language: "de" canonical: "https://zapolu.com/de/downloads/sample-audit-report/" --- # Performance-Audit: Deep Dive (Beispielbericht) > **Dies ist ein Muster.** Den Kunden „Acme Outdoor s.r.o.“ gibt es > nicht, und die identifizierenden Details sind verändert. Die Befunde > und die Zahlen sind aus echten Performance-Audits zusammengesetzt und > anonymisiert: aus Audits, die Luboš Zápotočný in zehn Jahren > E-Commerce-Engineering durchgeführt hat, noch vor der Gründung dieser > Praxis. Es sind keine Aufträge, die unter der Marke Zapolu > durchgeführt wurden; die Marke hat noch keine eigene Kundenhistorie. Der > Nachweis dieser früheren Arbeit steht auf der Seite > [Über uns](https://zapolu.com/de/about/). Das Muster zeigt die Form: > womit ein Befund belegt wird, was seine Behebung kostet und wie die > Arbeit sortiert wird. Ein fertiger Bericht behandelt jeden Befund so > ausführlich wie unten F1; dieses Muster kürzt sechs der > elf, damit es lesbar bleibt. | | | |---|---| | **Kunde** | Acme Outdoor s.r.o. (fiktiv) | | **Shop** | acme-outdoor.example (Magento 2.4.6, Luma-Frontend) | | **Stack** | Varnish 7, Redis 7, MySQL 8, 2 App-Nodes hinter einem Load Balancer | | **Berichtsdatum** | 5. Juni 2026 | | **Felddaten** | 7. Mai bis 3. Juni 2026 (28 Tage) | | **APM-Traces** | 21. Mai bis 3. Juni 2026 (14 Tage) und ein Lasttest | | **Werkzeuge** | New Relic, CrUX, Lighthouse, k6, varnishstat, MySQL Slow Log | | **Autor** | Luboš Zápotočný, Zapolu s.r.o. | | **Engagement** | Deep Dive, 7 Arbeitstage, Festpreis | **Für einen kurzen Überblick** lesen Sie Abschnitt 1 und Abschnitt 5. Alles dazwischen ist die Beweisführung. ## 1. Zusammenfassung Die Langsamkeit des Shops entsteht serverseitig. Das Feld-LCP liegt auf Katalogseiten bei **4,6 s (p75)** (Ziel: ≤ 2,5 s), getrieben von einer **TTFB von 1,9 s**. Die TTFB ist hoch, weil der Full-Page-Cache faktisch deaktiviert ist: Varnish beantwortet nur **34 %** der Katalog-Requests, und 38 % der gesamten Serverzeit entfallen auf das Rendern von Produktseiten, im Schnitt 2,2 s pro Request. Am Kampagnenabend des 26. Mai erreichte der Checkout **6,1 s (p95)** und **3,4 % der Requests schlugen fehl**, während die CPU der Applikationsserver nie über 12 % kam. Es folgen elf Befunde. Sieben davon kosten einen Arbeitstag oder weniger, und zwei dieser sieben (F2 und F8) sind Änderungen an reinen Konfigurationsdateien. Die Zeilen 1 bis 6 des Fix-Plans beseitigen jeden Ausfall, den ein Kunde spürt: Der Checkout fällt in der Spitze nicht mehr aus, und das Checkout-p95 während Kampagnen sinkt von 6,1 s auf 1,9 s. Largest Contentful Paint erreicht Googles Schwelle von 2,5 s mit diesen Zeilen allein nicht. Das Budget: | Stand | Was sich ändert | Kategorie-LCP | Produkt-LCP | |---|---|---|---| | heute | | 4,6 s | 4,6 s | | nach Zeile 2 | F1, Katalog-TTFB 1,9 s → 1,2 s | 3,9 s | 3,9 s | | nach Zeile 5 | F5, Produkt-Hero-Bilder | 3,9 s | 3,3 s | | nach Zeile 7 | F4 vorläufig, tote Tags und Deferral | 3,5 s | 2,9 s | | nach Zeile 8 | F4, der Storefront-Neubau | 2,7 s | 2,1 s | Unter die Schwelle bringt die Produktseiten erst der Neubau in Zeile 8. Kategorieseiten enden bei 2,7 s und damit weiter darüber; was den Rest schließen würde, haben wir nicht untersucht (Abschnitt 6). Die Zeilen sind nach Ertrag sortiert; der Plan lässt sich an jeder Stelle anhalten. In Geld ausgedrückt: Am Kampagnenabend des 26. Mai endeten in drei Stunden rund 230 Checkouts mit einem Fehler. Beim durchschnittlichen Bestellwert von 1 800 CZK sind das 414 000 CZK an versuchten Bestellungen, die fehlschlugen, also rund 17 000 € bei 24,3 CZK je Euro, und die Kunden, die den Checkout nach sechs Sekunden Wartezeit abgebrochen haben, sind darin nicht enthalten. Die übrigen Befunde geben wir in Millisekunden an; eine Umsatzzahl wäre für sie spekulativ, daher lassen wir sie weg. ## 2. Was wir gemessen haben, und wie - **Real-User-Metriken:** Core Web Vitals aus einer 28-Tage- CrUX-Abfrage, segmentiert nach Seitentyp (Home / Kategorie / Produkt / Checkout). Synthetische Lighthouse-Läufe dienten nur der Reproduktion von Befunden, nicht deren Bewertung. Wo der Shop gegenüber Googles Schwellwerten steht: | Metrik (p75, Felddaten) | Shop | Schwelle | Urteil | |---|---|---|---| | LCP | 4,6 s | < 2,5 s | fällt durch | | INP | 280 ms | < 200 ms | fällt durch | | CLS | 0,04 | < 0,1 | besteht | | FCP | 2,9 s | < 1,8 s | fällt durch | | TTFB | 1,9 s | < 0,8 s | fällt durch | - **Server-seitiges Tracing:** New-Relic-Transaktionsprofil über 14 Tage, das zeigt, wohin die Serverzeit wirklich geht: | Transaktion | Anteil an der Serverzeit | Ø Antwort | |---|---|---| | `catalog/product/view` | 38 % | 2,2 s | | `catalog/category/view` | 17 % | 1,8 s | | Checkout-REST (Warenkorb + Versand) | 11 % | 1,4 s (6,1 s p95 in der Spitze) | Dazu das MySQL Slow Query Log, das Profil externer Dienste und Varnish-Hit/Miss-Statistiken je URL-Muster aus `varnishstat`. - **Lasttest:** ein Replay des Traffic-Verlaufs vom Kampagnenabend des 26. Mai (0 → 420 req/s über 20 Minuten) gegen Staging, mit demselben Cache-Zustand wie in Produktion. - **Konfigurations-Review:** PHP- und OPcache-Einstellungen, Composer-Autoloader, `env.php`, die Varnish-VCL und MySQL-Einstellungen, jeweils gegen Magentos dokumentierte Empfehlungen, nach oben angepasst, wo die Codebasis über den dokumentierten Wert hinauswächst. - **Bundle- und Asset-Audit:** was beim ersten Aufruf einer Produktseite ausgeliefert wird, was das Rendern blockiert und was unnötige Last ist. Die meisten Befunde zitieren den exakten Befehl oder die exakte Query, die wir verwendet haben: einerseits, damit Ihr Team unsere Arbeit nachprüfen kann, andererseits, weil dieselben Prüfbefehle auf jedem Magento-Shop laufen, auch auf Ihrem. Abschnitt 7 sammelt sie, damit sie unverändert laufen. Zu jeder Zahl unten steht, woher sie kommt, und die Befundtabelle trägt eine Spalte, die sagt, ob die erwartete Wirkung gemessen, unter Last reproduziert oder geschätzt wurde. ## 3. Befunde im Überblick **Hoch**: Kunden sind betroffen, oder Umsatz hängt davon ab. **Mittel**: das Team ist täglich betroffen, oder Daten werden still beschädigt. **Niedrig**: kleiner Aufwand, der ein reales Betriebsrisiko beseitigt. | # | Befund | Schweregrad | Aufwand | Erwartete Wirkung | Grundlage | |---|--------|-------------|---------|-------------------|-----------| | F1 | Full-Page-Cache ist faktisch deaktiviert und lässt sich nicht invalidieren | Hoch | 1–2 Tage | −700 ms TTFB (p75) im Katalog | gemessen | | F2 | PHP-Runtime und Autoloader für Magento falsch konfiguriert | Hoch | 0,5 Tage | −400 ms bei jedem ungecachten Request | geschätzt | | F3 | Checkout blockiert auf einem synchronen ERP-Bestandsabruf | Hoch | 3–5 Tage | −2,8 s Checkout-p95 in der Spitze; keine Timeout-Fehler mehr | Lasttest | | F4 | Frontend liefert 2,3 MB JavaScript aus, renderblockierend | Hoch | Projekt | −1,2 s LCP (Zwischenlösungen: −0,4 s) | geschätzt | | F5 | Produktbilder: 1,6-MB-PNGs, keine responsiven Größen | Mittel | 1 Tag | −0,6 s LCP auf Produktseiten | gemessen | | F6 | Indexer auf „Update on Save“ belassen | Mittel | 0,5 Tage | Admin-Speichern 30 s → ~2 s; Bestandsdrift endet | geschätzt | | F7 | PHP-FPM-Pool durch Session-Locks in der Spitze erschöpft | Hoch | 2 Tage | Checkout übersteht Kampagnen-Traffic | Lasttest | | F8 | Kein Grace-Modus in Varnish | Niedrig | 0,5 Tage | Fängt die Welle nach jedem Cache-Flush ab | geschätzt | | F9 | Zwei Extensions beobachten dasselbe Event; eine ist verwaist | Mittel | 1 Tag | −300 ms beim Hinzufügen zum Warenkorb | gemessen | | F10 | 41 GB tote Indexer-Temp-Tabellen in MySQL | Niedrig | 0,5 Tage | Backups 60 % kleiner; Restore etwa halb so lang | gemessen | | F11 | Admin-Bestellgrid filtert auf einer unindizierten Spalte | Niedrig | 0,5 Tage | Bestellgrid 12 s → unter 1 s | geschätzt | **Grundlage** sagt, woher die erwartete Wirkung stammt. *Gemessen*: wir haben es auf diesem Shop beobachtet. *Lasttest*: wir haben es auf Staging unter Kampagnenlast reproduziert. *Geschätzt*: es folgt aus Profil und Konfiguration, beobachtet hat es noch niemand. ## 4. Befunde im Detail ### F1: Full-Page-Cache ist faktisch deaktiviert und lässt sich nicht invalidieren (Hoch) **Was wir sahen.** Varnish meldet auf Katalog-URLs eine Hit-Rate von 34 %. Für einen Katalog dieser Größe, bei diesem Crawler-Anteil, sind über 90 % normal. Jede Kategorie- und Produktseite trägt `X-Magento-Cache-Debug: MISS`. Es gibt zwei unabhängige Ursachen: 1. Eine angepasste `default.xml` markiert einen Header-Block (einen Store-Switcher, der die Kunden-Session liest) als `cacheable="false"`. In Magento macht ein einziger uncachebarer Block im Layout die **gesamte Seite** uncachebar. Der Block kam mit einem Extension-Update im November 2025; die Hit-Rate brach in derselben Woche ein. 2. Varnish ist im Admin aktiviert (`system/full_page_cache/caching_application = 2`), aber in der `env.php` fehlt die Sektion `http_cache_hosts`; Magento kann also gar keine Purge-Requests an Varnish senden. Das Team behilft sich mit einem Varnish-Neustart nach jedem Deploy, und genau deshalb sind Deploys problematisch (siehe F8). So haben wir es verifiziert: ``` $ curl -sI https://acme-outdoor.example/zelte | grep -i cache-debug X-Magento-Cache-Debug: MISS # auf jeder geprüften Katalog-URL $ grep -R 'cacheable="false"' app/design app/code | wc -l 1 # der Store-Switcher-Block, default.xml $ php -r 'var_export(array_key_exists("http_cache_hosts", (include "app/etc/env.php")));' false # Magento kann Varnish nicht purgen ``` **Fix.** Den Switcher über eine Private-Content-Sektion rendern (Customer-Data-JS), damit die Seite cachebar bleibt (das dokumentierte Muster für session-abhängige Fragmente), und `http_cache_hosts` in `env.php` ergänzen, damit die Tag-basierte Invalidierung funktioniert und die Neustarts enden können. **Aufwand / Wirkung / Risiko.** 1–2 Tage inklusive Regressionstests. Erwartet: −700 ms TTFB (p75) auf Katalogseiten (gemessen: gecachte Katalogantworten in 80 ms vs. 1,9 s ungecacht). Risiko: gering; beide Änderungen sind begrenzt und pro Deploy reversibel. ### F2: PHP-Runtime und Autoloader für Magento falsch konfiguriert (Hoch) **Was wir sahen.** Die Codebase umfasst ~125 000 PHP-Dateien; OPcache ist auf 10 000 konfiguriert. Der Composer-Autoloader wurde nie optimiert: `vendor/composer/autoload_static.php` enthält keine Class-Map, und die New-Relic-Traces zeigen ganze Sekunden in der `ObjectManager`-Factory-Auflösung auf kalten Pfaden. Aktuell versus empfohlen: | Einstellung | Aktuell | Empfohlen | |---|---|---| | `opcache.max_accelerated_files` | 10 000 | 100 000 | | `opcache.memory_consumption` | 128 | 512 | | `opcache.validate_timestamps` | On, Revalidierung alle 2 s | Off; Reset beim Deploy | | `opcache.enable_cli` | Off | On (Indexer und Crons sind auch PHP) | | `realpath_cache_size` | 4M | 32M | | `realpath_cache_ttl` | 120 | 7200 | | Composer-Autoloader | nicht optimiert | `dump-autoload --optimize` im Build | So haben wir es verifiziert: ``` $ find . -type f -name '*.php' | wc -l 124862 # PHP-Dateien in der Codebase $ php -i | grep 'opcache.max_accelerated_files' opcache.max_accelerated_files => 10000 # fasst 8 % davon $ grep -c 'classMap' vendor/composer/autoload_static.php 0 # Autoloader wurde nie optimiert ``` **Warum.** Mit diesen Werten prüft und kompiliert PHP laufend einen großen Teil der Codebase neu; die Profile schreiben über die Hälfte der ungecachten Renderzeit dem Klassenladen und Seitenaufbau zu, nicht der Geschäftslogik. **Fix.** Eine Konfigurationsänderung plus ein Build-Schritt. Die einzige Kopplung, die zu respektieren ist: Mit abgeschaltetem `validate_timestamps` muss die Deploy-Pipeline beim Release den OPcache zurücksetzen. Den genauen Schritt für Ihre aktuelle Pipeline haben wir im Fix-Plan dokumentiert. **Aufwand / Wirkung / Risiko.** 0,5 Tage. Geschätzt −400 ms bei jedem ungecachten Request (und schnellere Crons und Indexer als Nebeneffekt). Risiko: gering, sofern der Deploy-Schritt zusammen mit der Konfiguration landet. ### F3: Checkout blockiert auf einem synchronen ERP-Bestandsabruf (Hoch) **Was wir sahen.** Im Versandschritt zeigt der Trace einen synchronen HTTPS-Call auf den Bestands-Endpoint des ERP mit 3-Sekunden-Timeout und einem Retry; das Profil externer Dienste schreibt 92 % der gesamten externen Wartezeit diesem einen Endpoint zu. Unter Kampagnenlast wird das ERP langsam, die Calls schöpfen ihren Timeout voll aus, und Checkout-Requests stauen sich. Genau daher kommen die 6,1 s p95 und die 3,4 % Fehler. Der Lasttest reproduziert es auf Staging. **Warum.** Die Echtzeit-Bestandsbestätigung kam nach einem Überverkaufs-Vorfall im Jahr 2025. Die Absicht ist richtig, nur legt sie die Latenz eines Drittsystems in jeden einzelnen Checkout. **Fix.** Den Bestandsabgleich aus dem Request-Pfad nehmen: gegen den lokalen Bestand reservieren, asynchron bestätigen, bei Abweichung alarmieren. Der Schutz vor Überverkauf bleibt erhalten, und der Checkout wartet nicht mehr auf das ERP. Dasselbe Muster beschreiben wir im Beitrag [warum ERP und Shop beim Bestand auseinanderlaufen](https://zapolu.com/de/blog/warum-erp-und-shop-beim-bestand-auseinanderlaufen/). **Aufwand / Wirkung / Risiko.** 3–5 Tage inklusive Abweichungs-Alarm. Entfernt ~2,8 s aus dem Checkout-p95 in der Spitze und die Timeout-Fehler vollständig (beides im Lasttest mit gestubbtem Call gemessen). Risiko: mittel; es braucht eine schriftliche Freigabe des neuen Überverkaufs-Fensters (geschätzt < 0,1 % der Kampagnenbestellungen, gegenüber heute 3,4 % fehlschlagender Checkouts). ### F4: Frontend liefert 2,3 MB JavaScript aus (Hoch) **Was wir sahen.** Der erste Aufruf einer Produktseite lädt 2,3 MB JavaScript in 61 Dateien; die Main-Thread-Blockierung liegt auf einem Mittelklasse-Smartphone bei 2,9 s. Hinter vier der vierzehn Marketing-Tags steht kein funktionierendes Konto mehr. **Warum.** Teils die Luma-Frontend-Architektur, teils acht Jahre angesammelte Tags; kein einzelner Tag dominiert die Summe. **Fix, kurzfristig (dieses Quartal).** Die vier toten Tags entfernen, das Analytics-Bundle verzögern, das Bewertungs-Widget unterhalb des Folds lazy laden. Geschätzt −0,4 s LCP, 2 Tage. **Der richtige Fix (separate Entscheidung).** Ein Storefront-Neubau auf Hyvä. Er ersetzt die JavaScript-Schicht von Luma, statt Teile davon nur zu verzögern; über die Payload entscheidet dann die Architektur und nicht die Pflege einzelner Tags. Es ist ein Projekt von 6–10 Wochen und verdient ein eigenes, sauber geschnittenes Angebot, keine Zeile in einer Fix-Liste. Wir nennen es hier, damit die kurzfristige Schätzung oben nicht als das Maximum gelesen wird, das erreichbar ist. ### F7: PHP-FPM-Pool durch Session-Locks in der Spitze erschöpft (Hoch) **Was wir sahen.** Im Lasttest beginnen die Fehler bei ~280 req/s, während die CPU bei 12 % sitzt. Die FPM-Statusseite zeigt alle Worker belegt; die Traces zeigen Warten auf Redis-Session-Locks: Kunden, die die Bestellbestätigungsseite wiederholt abfragen, halten Locks, die jeden weiteren Request derselben Session in die Warteschlange zwingen. **Fix.** Session-Locking für die Polling-Endpoints deaktivieren, die Worker-Zahl auf das anheben, was der Speicher-Headroom real erlaubt (die aktuelle Zahl stammt von einem kleineren Instanztyp), und einen Alarm für die FPM-Auslastung ergänzen; dieser Ausfall blieb unbemerkt, weil die CPU-Graphen unauffällig aussahen. **Aufwand / Wirkung / Risiko.** 2 Tage inklusive Wiederholung des Lasttests. Zusammen mit F3 übersteht Staging 420 req/s mit einem Checkout-p95 von 1,9 s. Risiko: gering. ### F5, F6, F8, F9, F10, F11 kurz - **F5 Bilder:** die Produkt-Heroes sind 1,6-MB-PNGs, in einer einzigen Größe an jedes Gerät ausgeliefert. WebP-Konvertierung + responsive Größen über das CDN: 1 Tag, −0,6 s LCP auf Produktseiten (an einer konvertierten Stichprobe gemessen). - **F6 Indexer:** beim Massenimport im Februar 2026 auf „Update on Save“ umgestellt und nie zurück. Admin-Produktspeichern dauert 30 s, und die Abweichung zwischen Shop-Bestand und Lagerrealität geht auf Reindex-Races zurück. Geplantes Indexieren wiederherstellen: 0,5 Tage. Die 30 s sind gemessen; die Zahl nach dem Fix ist eine Schätzung. - **F8 Varnish Grace:** jeder Cache-Flush schickt heute die volle Traffic-Welle auf PHP. Der Grace-Modus liefert veraltete Objekte aus, bis der Cache wieder gefüllt ist: 0,5 Tage. Die Wirkung ist eine Schätzung. - **F9 Doppelte Observer:** zwei Extensions abonnieren dasselbe Checkout-Event; eine ist seit 2023 vom Anbieter verwaist und lädt bei jedem Aufruf das Quote neu. Entfernen (ihr Feature ist ungenutzt): 1 Tag inklusive Verifikation, −300 ms beim Hinzufügen zum Warenkorb (im Trace gemessen). - **F10 Datenbank-Hausputz:** die Datenbank trägt 41 GB `catalogrule_product__temp*`-Tabellen (Überbleibsel abgebrochener Indexer-Läufe aus einer älteren Magento-Version, die nie aufräumte) plus eine eigene Queue-Tabelle mit 12 Millionen Zeilen ohne Retention. Eine `information_schema`-Query findet sie: ``` mysql> SELECT COUNT(*) tables, ROUND(SUM(data_length+index_length) -> /1024/1024/1024, 1) gb FROM information_schema.tables -> WHERE table_name LIKE 'catalogrule\_product\_\_temp%'; +--------+------+ | tables | gb | +--------+------+ | 96 | 41.2 | +--------+------+ ``` Überbleibsel löschen und Pruning ergänzen: 0,5 Tage. Backups schrumpfen von 68 GB auf 27 GB; die Restore-Zeit halbiert sich ungefähr, was aus der Größenänderung geschätzt ist und vor allem an dem Tag zählt, an dem ein Restore wirklich gebraucht wird. - **F11 Admin-Bestellgrid:** eine für das Fulfillment-Team ergänzte Spalte filtert auf einem unindizierten Attribut; das Grid lädt 12 s und bindet dabei jedes Mal einen Worker. Eine Index-Migration: 0,5 Tage. Die 12 s sind gemessen; die Zahl nach dem Fix ist eine Schätzung. ## 5. Der Plan, sortiert nach Ertrag pro Aufwand | Reihenfolge | Punkte | Aufwand | Was Sie bekommen | |-------------|--------|---------|------------------| | 1 | F2 + F8 | 1 Tag | Jeder ungecachte Request −400 ms; Cache-Flushes verursachen keine Lastspitze mehr | | 2 | F1 | 1–2 Tage | Katalog-TTFB −700 ms; Deploys brauchen keinen Varnish-Neustart mehr | | 3 | F6 + F10 + F11 | 1,5 Tage | Admin wieder benutzbar; Bestandsdrift endet; Backups halbiert | | 4 | F7 | 2 Tage | Checkout fällt in der Spitze nicht mehr aus | | 5 | F5 + F9 | 2 Tage | Produktseiten-LCP −0,6 s; Hinzufügen zum Warenkorb −300 ms | | 6 | F3 | 3–5 Tage | Checkout-p95 unter 2 s während Kampagnen | | 7 | F4 kurzfristig | 2 Tage | LCP −0,4 s, bis die Storefront-Entscheidung fällt | | 8 | F4 Neubau | separates Angebot | Produktseiten-LCP innerhalb der 2,5-s-Schwelle | Die Zeilen 1–6 ergeben zusammen 10,5 bis 13,5 Engineering-Tage und beheben jeden Ausfall, den ein Kunde spüren kann. Sie können nach jeder Zeile aufhören; die Arbeit bis dahin steht für sich. Zeile 6 ist die einzige, die die Architektur des Bestellpfads berührt. Wer auch immer sie umsetzt: Lassen Sie das Design von einem erfahrenen Engineer prüfen. Messen Sie nach Zeile 6 mit derselben Felddaten-Abfrage nach, mit der dieser Bericht begonnen hat. Bewegen sich die Zahlen nicht wie vorhergesagt, kontaktieren Sie uns, und wir ermitteln die Ursache. ## 6. Was wir nicht geprüft haben Sicherheitslage, SEO, Barrierefreiheit und Codequalität außerhalb der profilierten heißen Pfade liegen außerhalb des Umfangs dieses Engagements. Das Audit deckt die Standard-Store-View ab; die B2B-Store-View teilt den Stack, wurde aber nicht separat vermessen. Das Budget in Abschnitt 1 lässt Kategorieseiten 0,2 s über der 2,5-s-Schwelle, und woran das liegt, haben wir nicht ermittelt: Das braucht einen Durchgang durch die Kategorie-Templates, den dieses Engagement nicht umfasste. Eine Zugriffs-Einschränkung: Unser Audit-Benutzer konnte im Messfenster den Varnish-Admin-Socket nicht lesen; die Varnish-Laufzeitzähler stammen daher aus `varnishstat`-Snapshots des Hosters statt aus Live-Inspektion. ## 7. Anhang: die Prüfbefehle für Ihren eigenen Shop Das sind die Read-only-Prüfungen, mit denen dieses Audit begonnen hat. Sie laufen auf jedem Magento 2 und brauchen nichts außer einer Shell und einem Datenbank-Client. Führen Sie sie aus, bevor Sie irgendjemanden mit einem Audit beauftragen, uns eingeschlossen: Fallen alle Prüfungen unauffällig aus, liegt das Problem an einer Stelle, die dieser Bericht nicht abdeckt. **1. Liefert der Full-Page-Cache tatsächlich aus?** Rufen Sie eine Katalog-URL zweimal ab und lesen Sie den Debug-Header. ``` $ curl -sI https://ihr-shop.example/eine-kategorie | grep -i cache-debug ``` In Ordnung: `HIT` beim zweiten Aufruf. Jedes Mal `MISS` ist F1. **2. Macht irgendetwas die Seiten uncachebar?** Ein einziger Block mit `cacheable="false"` irgendwo im Layout macht die ganze Seite uncachebar. ``` $ grep -R 'cacheable="false"' app/design app/code | wc -l ``` In Ordnung: `0`. **3. Kann Magento Varnish überhaupt purgen?** ``` $ php -r 'var_export(array_key_exists("http_cache_hosts", (include "app/etc/env.php")));' ``` In Ordnung: `true`, wenn Varnish der konfigurierte Cache ist. **4. Fasst OPcache die ganze Codebase?** Vergleichen Sie die beiden Zahlen. ``` $ find . -type f -name '*.php' | wc -l $ php -i | grep 'opcache.max_accelerated_files' ``` In Ordnung: die zweite Zahl ist größer als die erste. **5. Optimiert der Build den Composer-Autoloader?** ``` $ grep -c 'classMap' vendor/composer/autoload_static.php ``` In Ordnung: jeder Wert ungleich `0`. **6. Laufen die Indexer nach Zeitplan?** ``` $ php bin/magento indexer:show-mode ``` In Ordnung: jede Zeile meldet „Update by Schedule“. Alles auf „Update on Save“ ist F6. (Befehl und Modusnamen nach [Adobes Indexer-CLI-Referenz](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/manage-indexers), geprüft am 1. August 2026.) **7. Wie viel totes Gewicht liegt in der Datenbank?** ``` mysql> SELECT COUNT(*) tables, ROUND(SUM(data_length+index_length) -> /1024/1024/1024, 1) gb FROM information_schema.tables -> WHERE table_name LIKE '%\_\_temp%'; ``` In Ordnung: eine Handvoll Tabellen. Der Shop in diesem Bericht hatte 96 davon, mit 41 GB. **8. Worauf wartet der Checkout?** Diese Prüfung braucht Ihr APM statt einer Shell: Öffnen Sie die Checkout-Transaktion, gruppieren Sie nach externem Dienst und lesen Sie den Anteil an der Gesamtzeit. In diesem Bericht entfielen 92 % davon auf einen einzigen Endpoint, und das ist F3. ## 8. Nächste Schritte Den Fix-Plan kann jedes kompetente Team umsetzen, auch Ihr eigenes: jeder Befund benennt die konkrete Änderung, die zu machen ist. Wenn wir ihn umsetzen sollen: Die Zeilen 1–6 passen in ein zwei- bis dreiwöchiges Festpreis-Engagement zu unseren üblichen [Engagement-Bedingungen](https://zapolu.com/de/downloads/zapolu-engagement-template.pdf). Fragen zu einzelnen Befunden: [info@zapolu.com](mailto:info@zapolu.com), oder [vereinbaren Sie ein Gespräch](https://zapolu.com/de/contact/) und bringen Sie Ihre eigenen Zahlen mit; im Gespräch sagen wir Ihnen, ob sich ein Audit lohnt.