CarCare24
Magento 2 Webshop Performance-Optimierung: LCP von 14-16s auf 2,14s CrUX bei echten Nutzern. Neun Wellen, custom Tieman_Csp Modul, alle Core Web Vitals gruen.
Screenshots


Über dieses Projekt
CarCare24 ist ein Magento 2 Webshop mit ~3.400 Produkten in vier Sprachen. Mobiler LCP lag bei 14 bis 16 Sekunden im Labor. Nach neun Performance-Wellen, WebP Hero-Konvertierung, Redis und FPC Tuning, Defer Third-Party Scripts und einem custom Tieman_Csp Modul liegt der LCP bei 2,14 Sekunden bei echten CrUX-Nutzern. A11y von 90 auf 100, Best Practices von 88 auf 96, SEO 100.
Highlights
Fallstudie
CarCare24 ist ein Magento 2 Webshop für Kfz-Zubehör mit ~3.400 Produkten und ~13.600 generierten Seiten, aktiv in vier Sprachen (NL, EN, DE, FR). Der Shop läuft auf Hypernode mit Cloudflare Free, Theme Infortis Ultimo, PHP 8.1.34-fpm, und seit Mai 2026 Magento 2.4.6-p15.
Die Herausforderung
Die mobile Ladezeit war kritisch. Lab-Messungen via PageSpeed Insights (Slow 4G, 4× CPU) zeigten einen LCP von 14 bis 16 Sekunden. Nicht ein Ausreißer, sondern neun wiederholte Messungen mit vergleichbaren Ergebnissen. Für einen Shop im Kfz-Segment bedeutet das verlorene Conversions auf Mobilgeräten, dem größten Traffic-Segment.
Neben dem LCP bestanden folgende Probleme:
- A11y-Score bei 90 durch fehlende Alt-Attribute und Kontrast-Issues
- Best Practices bei 88 durch CSP-Verletzungen und unsafe-inline Scripts
- SEO-Probleme durch fehlende Canonicals auf CMS-Seiten
Was ich angegangen habe
9 Performance-Wellen
Jede Welle zielte auf einen spezifischen Engpass. Zusammengefasst:
- Hero Image — WebP-Konvertierung,
loading="eager",fetchpriority="high". Das LCP-Element wartete auf ein 2× zu großes JPEG. - Third-Party Scripts — Defer Gate hinzugefügt, sodass Tracking und Chat erst nach User Interaction laden. Signifikant reduzierte Blocking Time bei Slow 4G.
- Redis und FPC — Magento Full Page Cache und Session-Speicher optimiert. TTFB sank von ~974ms auf ~390ms in CrUX über 28 Tage.
- PHP-FPM Workers — Konfiguration an das Hypernode Worker-Modell angepasst. Weniger Queue-Wartezeit unter Last.
- Checkout INP — Warenkorbabbrüche reduzieren durch schnellere Interaktion im Checkout. INP für ausgewählte Flows verbessert.
- SRI-Hashes — Race Condition gefunden, bei der SRI-Hashes nach einem Deploy nicht synchron mit den ausgelieferten Assets liefen (P1 Incident). Behoben via Tieman_Csp Modul.
- CMS Canonicals — CanonicalForCms Komponente hinzugefügt, um Duplicate Content auf Flat Pages zu verhindern.
Custom Tieman_Csp Modul
Vier Komponenten in einem Modul:
- CanonicalForCms — Canonical Tag auf CMS-Seiten, wo Magento ihn nicht automatisch setzt
- DeferThirdPartyScripts — Interaction Gate für alle nicht-essenziellen Scripts
- InteractionGate — Generischer Defer Wrapper für lazy-geladene Widgets
- SriRepositoryLock — SRI-Hash Synchronisation, behebt die Race Condition bei Deploys
Multi-Tenant Kontext
CarCare24 läuft als Stores 1 bis 4 plus Website 1 in einer Multi-Store-Datenbank. Jede Anpassung ist multi-store-aware gebaut, sodass alle vier Sprachen konsistent profitieren.
Magento p14 auf p15
Am 15. Mai 2026 wurde das Upgrade von 2.4.6-p14 auf 2.4.6-p15 durchgeführt. Ich habe den Deploy-Prozess begleitet und die Post-Deploy-Verifikation übernommen.
Ergebnisse
Lab vs CrUX — was sagen diese Zahlen?
Lab-Scores (PSI) sind Worst-Case: Slow 4G Simulation, 4× CPU Throttling, kein CDN-Vorteil, kein warmer Cache. Die Bandbreite 38 bis 65 mobil und 71 bis 92 Desktop spiegelt PSI-Varianz von ±15 Punkten auf derselben Seite wider. Ein einzelner Run bei 8,6 Sekunden LCP sagt weniger als der Durchschnitt über neun Runs.
CrUX sind echte Nutzerdaten von Chrome-Nutzern über 28 Tage. Die 2,14 Sekunden LCP und 111ms INP sind das, was Besucher tatsächlich erleben. Alle Core Web Vitals grün.
Stack
- Magento 2.4.6-p15, PHP 8.1.34-fpm
- 328 aktivierte Module (inkl. Tieman_Csp custom)
- Infortis Ultimo Theme
- Hypernode Hosting, Cloudflare Free
- ~3.400 Produkte, ~13.600 Seiten
- 4 Store Views: NL, EN, DE, FR
Was dieser Unterschied bedeutet
Ein LCP, der von 15 Sekunden auf 2,14 Sekunden bei echten Nutzern sinkt, ist keine Benchmark-Übung. Besucher auf Mobilgeräten sehen das Hero-Bild innerhalb von zwei Sekunden. Der Checkout läuft schneller. SRI-Probleme, die bei einem Deploy einen Production Incident verursacht haben, sind strukturell behoben, nicht temporär gepatcht.
Lighthouse Vorher und Nachher
Zwei Messungen via Google PageSpeed Insights (Slow 4G, Emulated Moto G Power, Lighthouse 13.0.1). Links der Ausgangszustand, rechts nach den Performance-Wellen.


Lighthouse Messung vor und nach den Performance-Wellen. Labordaten uber Google PSI.
Ist dein Webshop auf Mobilgeräten auch zu langsam? Nimm Kontakt auf für eine unverbindliche Analyse.