Magento-Speed-Optimierungsservices zur Rückgewinnung verlorener Conversions

Wichtige Highlights:

• Ein langsamer Magento-Storefront beeinträchtigt gleichzeitig die Conversion-Rate, die Effizienz bezahlter Suchkampagnen und organische Rankings. Damit ist die Magento-Speed-Optimierung in erster Linie eine Umsatzfrage und erst danach eine technische Herausforderung.
• Sigmas Ansatz kombiniert die Hyvä-Theme-Migration, Server- und Cache-Tuning sowie Datenbankbereinigung, um die verschiedenen Ursachen einer langsamen Magento-Plattform zu beheben, ohne ein vollständiges Replatforming durchzuführen.
• Händler, die eine strukturierte Magento-Performance-Optimierung durchführen, erreichen typischerweise innerhalb eines einzigen Release-Zyklus Core-Web-Vitals-Werte, die sich von nicht bestandenen zu bestandenen Schwellenwerten verbessern.
• Sigma setzt diese Arbeit im Rahmen einer dedizierten Engineering-Zusammenarbeit um und kombiniert Adobe-Commerce-zertifizierte Entwickler mit kontinuierlichem Monitoring, damit die erzielten Performance-Verbesserungen auch bei wachsendem Katalog und steigendem Traffic erhalten bleiben.

Für wachsende Händler ist die Magento-Performance mehr als nur eine technische Kennzahl. Mit zunehmendem Traffic, wachsendem Katalog, zusätzlichen Integrationen und erweiterten Storefront-Funktionen können Performance-Probleme Conversion-Chancen, die Effizienz bezahlter Kundenakquise, die Customer Experience und den Engineering-Aufwand zur Stabilisierung des Shops beeinträchtigen. Die richtige Optimierungsstrategie adressiert die zugrunde liegende Architektur und schützt gleichzeitig die bestehende Magento-Investition des Unternehmens.

Die Flexibilität von Magento hat ihren Preis: Jede Erweiterung, Anpassung und nicht verwaltete Cache-Einstellung erhöht die technische Last und verlangsamt den Storefront. Magento-Speed-Optimierung ist der systematische Ansatz, diese Belastungen in einer gezielten Reihenfolge zu identifizieren und zu beseitigen – von der Serverkonfiguration bis zum Browser –, anstatt lediglich einzelne Symptome zu behandeln. Für Händler mit einem umfangreichen Produktkatalog ist dies keineswegs nur ein kosmetisches Problem. Langsame Seiten reduzieren die Conversion-Rate, verschlechtern die für Suchrankings relevanten Core Web Vitals und verschwenden Paid-Media-Budget für Besucher, die die Website verlassen, bevor die Seite vollständig geladen ist. Die technischen Ursachen sind gut bekannt und lassen sich größtenteils innerhalb der bestehenden Plattform beheben, sofern die Maßnahmen richtig priorisiert und von Entwicklern umgesetzt werden, die wissen, wo sich Magento-Performance-Probleme typischerweise ansammeln.

Benötigen Sie Magento-Entwicklung, die mit Ihrem Storefront skaliert?

Warum Magento-Shops mit zunehmendem Wachstum langsamer werden

Die Magento-Performance verschlechtert sich schrittweise und nicht auf einmal. Ein Shop, der zunächst schnell gestartet ist, sammelt über mehrere Release-Zyklen hinweg Drittanbieter-Erweiterungen, nicht optimierte Produktbilder und zusätzliche Anpassungen an. Jede dieser Erweiterungen verursacht geringe Performance-Kosten, die sich mit den anderen summieren. Das standardmäßige Luma-Theme, das auf Knockout.js und RequireJS basiert, erzeugt eine JavaScript-Payload, die mit jeder Erweiterung wächst, die Code in den globalen Scope einfügt. Deshalb erreicht ein mittelgroßer Luma-basierter Shop bei Google PageSpeed Insights häufig nur Werte zwischen 30 und 50 und liegt damit deutlich unter Googles „gutem“ Schwellenwert für die Core Web Vitals. Lücken beim Caching verschärfen das Problem zusätzlich: Ein falsch konfigurierter Full-Page-Cache oder eine fehlende Redis-Integration für die Session-Speicherung zwingt den Server dazu, Seiten neu zu generieren, die eigentlich innerhalb von Millisekunden aus dem Cache ausgeliefert werden sollten. Nichts davon ist ungewöhnlich. Es ist das vorhersehbare Ergebnis einer Plattform, die auf Erweiterbarkeit ausgelegt ist, und lässt sich durch ein systematisches Audit beheben, ohne den Shop vollständig neu aufzubauen.

Die geschäftlichen Auswirkungen nehmen parallel zu den technischen Schulden zu. Eine langsame Produkt- oder Checkout-Erfahrung kann ansonsten wertvollen Traffic in abgebrochene Sitzungen verwandeln, während Engineering-Teams zunehmend Zeit darauf verwenden, Infrastruktur- und Code-Einschränkungen zu umgehen. Für wachsende Händler geht es daher nicht nur darum, Magento schneller zu machen, sondern darum zu erkennen, welche Performance-Einschränkungen das Wachstum begrenzen und welche davon behoben werden können, ohne den bestehenden Commerce-Betrieb zu beeinträchtigen.

Die meisten Engineering-Teams übernehmen dieses Problem, anstatt es selbst zu verursachen. Ein Shop, der unter hohem Zeitdruck für einen Launch entwickelt wurde, wird über mehrere Jahre hinweg von verschiedenen Dienstleistern und internen Entwicklern erweitert. Dadurch hat schließlich keine einzelne Person mehr den vollständigen Überblick darüber, was jede Erweiterung bewirkt oder warum sie ursprünglich hinzugefügt wurde. Hosting-Entscheidungen, die früh getroffen wurden, als Traffic und Kataloggröße noch geringer waren, werden mit dem Wachstum des Unternehmens häufig nicht erneut überprüft. Dadurch kann ein mittelgroßer Händler weiterhin eine Infrastruktur betreiben, die ursprünglich für einen wesentlich kleineren Shop ausgelegt war. Die Erkenntnis, dass das Problem struktureller Natur und kein einzelner Programmierfehler ist, verändert den Lösungsansatz: Erforderlich sind ein systematisches Audit und ein priorisierter Maßnahmenplan – nicht die Suche nach einem einzelnen Verursacher.

Performance-Ziele sollten als Engineering-Zielsetzungen und nicht als garantierte Ergebnisse betrachtet werden. Die tatsächlichen Ergebnisse hängen von der Hosting-Architektur, der Kataloggröße, dem Seitentyp, dem Umfang der Erweiterungen, Drittanbieter-Skripten, Traffic-Mustern und dem Zustand der bestehenden Codebasis ab. Die folgenden Bereiche dienen als beispielhafte Zielwerte zur Priorisierung von Optimierungsmaßnahmen und zur konsistenten Messung des Fortschritts.

Beispielhafte Magento-Performance-Zielwerte

Die Hyvä-Theme-Migration bietet den größten Hebel für die Frontend-Optimierung

Hyvä ersetzt das Luma-Frontend durch einen schlanken Stack auf Basis von Tailwind CSS und Alpine.js, wodurch die Abhängigkeit von Knockout.js vollständig entfällt und die JavaScript-Payload auf jeder Seite reduziert wird. Hyvä-Theme-Migration erreichen regelmäßig mobile PageSpeed-Scores von über 90 – ein Ergebnis, das für ein Luma-basiertes Theme unabhängig vom Umfang der Optimierungen strukturell nur schwer zu erreichen ist. Die Migration ist kein einfacher Austausch: Bestehende Erweiterungen müssen auf Kompatibilität angepasst werden, und das Frontend-Team muss individuelle Komponenten auf Basis der schlankeren Architektur von Hyvä neu entwickeln. Diese Investition zahlt sich auf drei Arten aus: messbare Verbesserungen der Magento Core Web Vitals, eine bessere organische Sichtbarkeit und eine Frontend-Codebasis, die langfristig deutlich einfacher zu warten ist.

Hyvä ist nicht automatisch für jeden Magento-Shop der richtige erste Schritt. Wenn langsame Serverantwortzeiten, Caching-Lücken, Datenbankabfragen oder Konflikte zwischen Erweiterungen den Großteil der Performance-Probleme verursachen, sollten diese Engpässe zuerst behoben werden. Ein diagnosebasierter Ansatz zeigt, ob das bestehende Frontend effektiv optimiert werden kann oder ob eine Hyvä-Migration genügend Vorteile bei Performance und Wartbarkeit bietet, um die zusätzliche Investition zu rechtfertigen.

Bereit für den nächsten Schritt nach Luma?

Server-, Cache- und Datenbankoptimierungen liefern die weiteren Performance-Gewinne

Frontend-Arbeiten allein können einen Shop mit serverseitigen Engpässen nicht optimieren. Die korrekte Konfiguration von Varnish als Full-Page-Cache, die Verlagerung der Session- und Standard-Cache-Speicherung zu Redis sowie der Einsatz einer unterstützten PHP-Version mit aktiviertem OPcache führen in der Regel zu den schnellsten und sichtbarsten Verbesserungen, da sie jede Seitenanfrage betreffen, ohne Änderungen am Frontend zu erfordern. Der Zustand der Datenbank ist ebenso wichtig: Lang laufende Abfragen auf übermäßig großen Log- und Quote-Tabellen sind eine häufige Ursache für eine langsame Time to First Byte. Durch das gezielte Hinzufügen von Indizes oder die Archivierung veralteter Daten lassen sich die Antwortzeiten verbessern, ohne zusätzliche Ausgaben für die Infrastruktur. Die Bildauslieferung vervollständigt die Optimierungsmaßnahmen. Nicht optimierte Produktbilder, die ohne WebP-Konvertierung oder Content Delivery Network ausgeliefert werden, zwingen mobile Nutzer dazu, Dateien herunterzuladen, die um ein Vielfaches größer sind, als es für ihre Bildschirmgröße erforderlich wäre. Dies ist einer der häufigsten Faktoren für eine schlechte Magento-Seitengeschwindigkeit in umfangreichen Produktkatalogen.

Diese Verbesserungen sind besonders wertvoll, wenn ein Händler die Performance verbessern möchte, ohne die Storefront Experience zu verändern oder die bestehende Commerce-Architektur zu ersetzen. Werden zunächst Einschränkungen in der Infrastruktur und auf der Datenebene behoben, lassen sich deutliche Performance-Verbesserungen erzielen, während Katalog, Integrationen und Customer Journeys unverändert bleiben.

Ein Content Delivery Network verdient besondere Aufmerksamkeit bei Händlern mit einem geografisch verteilten Kundenstamm. Die Auslieferung statischer Assets, Bilder, Skripte und Stylesheets über Edge-Standorte in der Nähe der jeweiligen Besucher reduziert die Netzwerklatenz auf eine Weise, die allein durch serverseitige Optimierung nicht erreicht werden kann. Die physische Entfernung zwischen dem Kunden und dem Origin-Server setzt eine Untergrenze für die Antwortzeit, die sich auch durch Caching nicht vollständig beseitigen lässt. Die Kombination einer CDN-Auslieferung mit responsiver Bildskalierung, sodass mobile Besucher niemals Produktbilder in Desktop-Auflösung herunterladen müssen, schließt häufig bereits einen erheblichen Teil der Performance-Lücke zwischen einem unoptimierten und einem vollständig optimierten Shop – noch bevor Änderungen am Theme oder an der Infrastruktur vorgenommen werden.

Bereiten Sie sich auf Traffic-Spitzen vor? Erfahren Sie, wie eine strukturierte Strategie zur Website-Speed-Optimierung Performance und Conversions während saisonaler Spitzenzeiten schützen kann.

Für Technologieverantwortliche ist die Optimierungsstrategie ebenso wichtig wie die einzelnen Maßnahmen. Performance-Optimierungen müssen die Geschwindigkeit verbessern, ohne Instabilität in einen umsatzgenerierenden Storefront einzuführen. Das bedeutet, Änderungen nach Wirkung und Implementierungsrisiko zu priorisieren, sie in der Staging-Umgebung zu validieren und risikoreichere Maßnahmen außerhalb wichtiger Kampagnen und Spitzenzeiten einzuplanen.

Optimierungsmaßnahmen richtig planen, ohne den Storefront zu beeinträchtigen

Die Reihenfolge der Maßnahmen ist entscheidend, da die Verbesserungen jeder Ebene davon abhängen, dass die darunterliegende Ebene zuverlässig funktioniert. Sigma beginnt mit einem umfassenden Performance-Audit von Server, Datenbank, Cache, Erweiterungen und Frontend, um die tatsächlichen Engpässe zu identifizieren, anstatt anhand einzelner Symptome Vermutungen anzustellen. Server- und Caching-Optimierungen erfolgen zuerst, da sie ein geringeres Risiko aufweisen und die schnellsten messbaren Verbesserungen ermöglichen, ohne eine einzige Zeile des Storefront-Codes zu verändern. Anschließend werden Datenbank und Erweiterungen bereinigt. Dabei werden nicht mehr benötigter Code und veraltete Daten entfernt und häufig Konflikte zwischen Modulen aufgedeckt, die ursprünglich nie für den gemeinsamen Betrieb entwickelt wurden. Eine Hyvä-Migration erfolgt, sofern sinnvoll, zuletzt, da sie den höchsten Aufwand erfordert und von einem bereits sauber optimierten Shop profitiert. Dadurch reduziert sich der erforderliche Kompatibilitätsaufwand für bestehende Erweiterungen. Jede Phase wird zunächst in der Staging-Umgebung bereitgestellt und anhand der oben aufgeführten Benchmark-Tabelle überprüft, bevor sie in die Produktionsumgebung gelangt. So bleibt der Storefront während der gesamten Zusammenarbeit stabil und das Risiko von Ausfallzeiten durch einen einzigen umfangreichen Cutover wird vermieden.

Für Einzelhändler, die saisonale Werbeaktionen durchführen, muss die Reihenfolge der Maßnahmen auch den richtigen Zeitpunkt berücksichtigen. Änderungen mit dem höchsten Risiko, wie eine Hyvä-Migration oder eine umfassende Überarbeitung des Cachings, sollten außerhalb der Spitzenzeiten von Kampagnen geplant werden. So wird der Umsatz geschützt, während die Änderungen unter realem Datenverkehr validiert werden. Maßnahmen mit geringerem Risiko, einschließlich Bildoptimierung und Datenbankindizierung, können jederzeit durchgeführt werden, da sie nur ein minimales Regressionsrisiko bergen und nahezu unmittelbar nach der Bereitstellung sichtbare Verbesserungen erzielen können.

Ein praktischer Ansatz zur Steuerung dieses Prozesses besteht aus fünf Phasen: die bestehende Architektur analysieren, die Einschränkungen mit den größten Auswirkungen priorisieren, den vorhandenen Technologie-Stack optimieren, Komponenten gezielt modernisieren, wenn die Erkenntnisse dies unterstützen, und die Performance nach der Veröffentlichung kontinuierlich überwachen. Dieser Ansatz bietet Engineering- und Business-Verantwortlichen einen klaren Weg, um Performance-Probleme zu identifizieren, erzielte Verbesserungen zu sichern und diese auch bei der Weiterentwicklung des Shops langfristig aufrechtzuerhalten.

Die Performance bleibt nach einer erfolgreichen Veröffentlichung nicht dauerhaft unverändert. Neue Erweiterungen, Integrationen, ein wachsender Produktkatalog, Änderungen im Merchandising und steigender Traffic können nach und nach neue Engpässe verursachen. Aus diesem Grund sollte Performance als kontinuierliche Engineering-Verantwortung und nicht als einmaliges Audit betrachtet werden – insbesondere für Einzelhändler, deren E-Commerce-Geschäft sich kontinuierlich weiterentwickelt.

Sigma Infosolutions betrachtet Performance als kontinuierliche Disziplin und nicht als einmaliges Projekt

Sigma betrachtet die Magento-Performance als Teil des umfassenderen Engineering-Lebenszyklus. Die Zusammenarbeit kann mit einem gezielten Audit- und Optimierungsprogramm beginnen und anschließend durch dediziertes Engineering oder T&M-Support fortgeführt werden, während sich der Shop weiterentwickelt. Dieses Modell stellt sicher, dass die Performance-Arbeit mit Releases, Infrastrukturänderungen, Integrationen und Wachstum verknüpft bleibt, anstatt die Optimierung als eigenständiges Projekt mit einem festen Endpunkt zu behandeln.

Die meisten Magento-Performance-Projekte scheitern beim zweiten Mal, nicht beim ersten, weil sich der Shop nach der Behebung der Probleme kontinuierlich weiterentwickelt. Neue Erweiterungen, ein wachsender Katalog und Content-Updates führen innerhalb weniger Release-Zyklen erneut zu denselben Problemen, wenn Regressionen nicht überwacht werden. Sigma betrachtet Magento-Speed-Optimierung die Magento-Geschwindigkeitsoptimierung als kontinuierliche Disziplin: Nach dem ersten Audit und der Behebung der identifizierten Probleme verlagert sich der Schwerpunkt auf die Überwachung von Core-Web-Vitals-Trends, dem Server-Antwortverhalten und den Auswirkungen von Erweiterungen, damit Performance-Verschlechterungen erkannt werden, bevor sie sich in den Conversion-Daten bemerkbar machen. Dies erfolgt durch ein dediziertes Engineering-Team oder einen T&M-Retainer und nicht als Projekt mit festem Umfang. Das ist entscheidend, da die Arbeit mit dem Go-live nicht abgeschlossen ist.

Sigma führte eine vergleichbare Performance- und UX-Optimierung für die Website eines Ratenkreditanbieters mit Sitz in Atlanta durch. Durch die Bereinigung von Plugins, Caching und eine vollständige Überarbeitung des Frontends konnte der Traffic neuer Nutzer um 40 Prozent gesteigert und die Nutzerbindung um 50 Prozent verbessert werden. Die Plattform dieses Projekts basierte auf WordPress und nicht auf Magento, doch die zugrunde liegende Methodik – systematisches Audit, gezielte Optimierungsmaßnahmen und Monitoring nach dem Launch – entspricht dem hier angewandten Ansatz.

Speziell im Magento-Bereich migrierte Sigma die Plattform eines US-amerikanischen Großhändlers von Magento 1 auf Magento 2.4. Dabei wurden Systeme für benutzerdefinierte Attribute, Produktvergleichsfunktionen und eine auf Elasticsearch basierende Suche neu entwickelt. Dies führte in den darauffolgenden zwei Jahren zu einer Steigerung des durchschnittlichen Bestellwerts um 12 Prozent, nachdem die Plattform schneller geworden war und sich die Verbesserungen der Customer Experience langfristig auswirken konnten.

Lesen Sie die vollständige Case Study zur Optimierung der Website-Performance eines führenden US-amerikanischen Kreditgebers und erfahren Sie mehr über den gesamten Prozess vom Audit bis zum Launch.

Das WordPress-Projekt verdeutlicht Sigmas umfassenderen, Audit-basierten Ansatz für Performance Engineering und nicht Magento-spezifische Ergebnisse. Das Projekt für Hansen Wholesale liefert das Magento-spezifische Beispiel und zeigt, wie Plattformmodernisierung, individuelle Funktionalitäten und eine schnellere Commerce Experience langfristige wirtschaftliche Verbesserungen unterstützen können

Dieses Projekt zeigte, wie eine Audit-basierte Behebung von Problemen – anstelle eines vollständigen Plattform-Neuaufbaus – sowohl Traffic als auch Nutzerbindung wiederherstellen kann, wenn die eigentlichen Engpässe in technischen Altlasten bei Code und Konfiguration liegen. Derselbe strukturierte Ansatz wurde auf eine tatsächliche Magento-Plattform angewendet, bei der die Größe des Produktkatalogs und die Legacy-Architektur die tatsächlichen Einschränkungen darstellten. Dadurch konnten nachhaltige Steigerungen des durchschnittlichen Bestellwerts erzielt werden, die auch zwei Jahre nach dem Go-live Bestand hatten.

Erfahren Sie, wie eine Migration von Magento 1 auf Magento 2 den durchschnittlichen Bestellwert bei Hansen Wholesale innerhalb von zwei Jahren um 12 Prozent steigerte.

Fazit:

Magento-Speed-Optimierung liefert den größten Mehrwert, wenn sie als Engineering-Disziplin betrachtet wird, die an Geschäftsergebnisse gekoppelt ist, und nicht als einmalige technische Bereinigung. Die Ursachen für einen langsamen Magento-Shop sind gut bekannt und reichen von Frontend-Code-Bloat, Caching- und Serverfehlkonfigurationen über nicht optimierte Medien bis hin zu Datenbankproblemen. Jede Ursache wird durch eine spezifische, überprüfbare Lösung behoben und nicht durch Vermutungen oder willkürlich angewandte Maßnahmen.

Hyvä-Theme-Migration bietet heute die größten strukturellen Frontend-Verbesserungen, die für einen Magento-Shop möglich sind. Server-Tuning, Caching-Konfiguration und Datenbankoptimierung stellen den Großteil der verbleibenden Performance wieder her, ohne das Design oder die Katalogstruktur des Shops zu verändern. Die Umsetzung dieser Maßnahmen in der richtigen Reihenfolge schützt den Shop vor Störungen und führt gleichzeitig zu messbaren Verbesserungen bei Core Web Vitals, Seitengeschwindigkeit und Conversion-Rate.

Einzelhändler, die Performance als kontinuierliche, überwachte Aufgabe und nicht als einmaliges Projekt betrachten, können ihre Verbesserungen trotz Katalogwachstum, saisonaler Traffic-Spitzen und neuer Integrationen langfristig aufrechterhalten. Bei Unternehmen, die Performance hingegen als einmalige Maßnahme behandeln, treten dieselben Probleme typischerweise innerhalb von zwei oder drei Release-Zyklen erneut auf. Sigma Infosolutions unterstützt diese Arbeit durch ein dediziertes Adobe-Commerce-Engineering-Team, das ein initiales Audit, bei Bedarf eine Hyvä-Migration sowie langfristiges Monitoring nach dem Launch umfasst.

Für Einzelhändler in der Wachstumsphase besteht das Ziel nicht einfach darin, einen besseren PageSpeed-Score zu erreichen. Vielmehr geht es darum, eine Commerce-Plattform aufzubauen, die steigenden Traffic, wachsende Katalogkomplexität, Integrationen und Kundenerwartungen bewältigen kann, ohne dass Performance-Probleme das Wachstum einschränken. Sigma verfolgt diesen Ansatz bei der Magento-Performance durch einen strukturierten Zyklus aus Audit, Optimierung, Modernisierung und kontinuierlicher technischer Betreuung. So können Einzelhändler ihre bestehenden Commerce-Investitionen optimieren, bevor sie die Risiken und Kosten einer umfassenderen Plattformmigration eingehen.

Bereit, Ihren digitalen Storefront zu skalieren?

Häufig gestellte Fragen

Was umfasst die Magento-Speed-Optimierung konkret?

Es handelt sich um einen strukturierten Audit- und Optimierungsprozess, der Serverkonfiguration, Caching, Datenbankzustand, das Verhalten von Erweiterungen und Frontend-Code umfasst. Ziel ist es, Ladezeiten zu reduzieren und die Core Web Vitals zu verbessern, ohne die zugrunde liegende Plattform zu ersetzen. Dabei werden die einzelnen Ebenen in einer Reihenfolge optimiert, bei der sich die Verbesserungen gegenseitig verstärken, anstatt einzelne Symptome isoliert zu behandeln.

Kann die Magento-Performance ohne vollständige Neuentwicklung verbessert werden?

In den meisten Fällen ja. Probleme bei Konfiguration, Caching und Code entstehen schrittweise über mehrere Release-Zyklen hinweg und lassen sich in der Regel durch gezielte Engineering-Maßnahmen beheben, anstatt ein kostspieliges und risikoreiches Replatforming durchzuführen. Eine vollständige Neuentwicklung ist nur selten erforderlich, sobald die tatsächlichen Engpässe durch ein fundiertes Audit identifiziert wurden.

Was ist eine Hyvä-Theme-Migration und wann lohnt sich die Investition?

Hyvä-Theme-Migration ersetzt das standardmäßige Luma-Frontend von Magento durch einen schlanken Stack aus Tailwind CSS und Alpine.js, der die Abhängigkeit von Knockout.js vollständig entfernt. Die Investition lohnt sich, sobald Server- und Caching-Probleme bereits behoben sind und der Shop den größtmöglichen verbleibenden Performance-Gewinn im Frontend benötigt.

Wie beeinflusst die Magento-Geschwindigkeit neben Conversions auch Suchmaschinenrankings?

Core Web Vitals sind ein bestätigtes Google-Ranking-Signal. Ein langsamer Shop hat daher nicht nur direkte Conversion-Verluste, sondern auch Nachteile in der organischen Suche. Eine Verbesserung der Geschwindigkeit stärkt somit zwei Umsatzkanäle gleichzeitig, weshalb diese Kennzahl zunehmend auch in der Verantwortung von Engineering-Verantwortlichen und nicht ausschließlich des Marketings liegt.

Wie lange dauert eine Magento-Speed-Optimierung typischerweise?

Eine gezielte Optimierung von Caching, Datenbankbereinigung und Bildauslieferung kann vom Audit bis zum Deployment etwa drei bis fünf Wochen dauern. Eine vollständige Kann die Magento-Performance ohne vollständige Neuentwicklung verbessert werden?