Mein erster onlineshop
mit shopware 5
Im Folgenden werde ich Dir zunächst erklären, warum Ladezeit heutzutage so wichtig ist und warum Du es dir als Shopware Shopbetreiber nicht leisten kannst, auf Performance-Optimierung zu verzichten.
Anschließend gehe ich auf das technische Know-How und die grundlegenden Prinzipien der Ladezeiten-Optimierung ein.
Nachdem wir uns mit der Theorie befasst haben, zeige ich Dir, wie und mit welchen Tools Du Deine Shop-Performance richtig messen kannst.
Abschließend zeige ich Dir verschiedene Performance-Schrauben, mit denen Du Deine Ladezeit verbessern kannst. Dabei gibt es einen gesunden Mix aus einfachen Einstellungen, die Du sofort im Backend vornehmen kannst, und Anpassungen die eher für Fortgeschrittene geeignet sind.
In jedem Onlineshop hast Du als Shopbetreiber automatisch auch Kunden (wäre schlecht wenn nicht, oder?). Kunden ist die Ladezeit einer Seite sehr wichtig. Jede Sekunde, die eine Artikelseite länger zum Laden braucht, bringt den Kunden mehr dazu, Deinen Shop wieder zu verlassen.
Frag Dich doch mal selbst: Würdest Du nochmal in einem Shop einkaufen wollen, der Dir zu langsam vorkommt? Ich auch nicht -> Kunden schauen sich nächstes Mal lieber beim Konkurrenten um.
Jeder, der als Shopbetreiber schon mal von Performance gehört hat, hat automatisch mitbekommen, dass schlechte Ladezeiten ein Conversion-Killer ist.
Dieses Phänomen lässt sich auch relativ leicht erklären: Ist der Shop schnell, hat er zum einen ein höheres Ranking, wodurch mehr Kunden den Shop im Internet finden. Außerdem verweilen Kunden länger im Shop, wenn sich nicht durch lange Ladezeiten genervt sind. Schnell kommt es dazu, dass sie sich weitere Artikel anschauen.
Die Anzahl an mobilen Benutzern ist heutzutage so hoch wie nie zuvor. Praktisch jeder hat ein Handy mit Internetzugang, mit dem er auf Deinen Shop zugreifen kann.
Auch wenn die mobile Internetgeschwindigkeit immer besser wird, unterliegt sie immer noch unserem WLAN zuhause. Daher sollten wir uns bei Ladezeiten-Optimierung auch besonders die Situation der mobilen Nutzer anschauen.
Zusätzlich zum Anstieg der mobilen Nutzer hat sich ein weiterer, grundlegender Aspekt im Internet geändert: Webseiten besitzen deutlich mehr Inhalt und Medien. Wir reden hier von Bildern, Videos, Animationen, Schriftarten etc.
Betrachtet man diese beiden Punkte, wird schnell klar, dass lange Ladezeiten mobile Kunden abschrecken. Lädt der Shop schon beim Aufruf der Startseite zu lange, entscheiden sich viele Kunden für eine andere Seite und kommen auch nicht wieder (denn sie wissen, dass der Shop langsam ist).
Zunächst sollte geklärt werden, was die Ladezeit genau ist und wie die Reduzierung dieser funktioniert. Die Ladezeit ist die gesamte Zeit, die benötigt wird, um den kompletten Inhalt einer Webseite anzuzeigen.
Dabei ist der Ablauf, vereinfacht dargestellt, immer folgender:
Die Ladezeit-Reduzierung zielt nun darauf ab, diese Prozesse für den Benutzer so schnell wie möglich durchzuführen.
Wie bei fast allem ist hier natürlich auch der Kosten-Nutzen-Faktor zu beachten. Gerade am Anfang gibt es viele Optimierungen, die sich relativ schnell und einfach durchführen lassen, gleichzeitig aber auch viel bringen.
Je mehr Optimierungen bereits umgesetzt worden sind, desto aufwendiger werden sie, bringen vergleichsweise aber immer weniger, da die Seite bereits schnell ist. Demnach sollte man sich bei der Ladezeiten-Optimierung immer auf die großen Baustellen konzentrieren, welche die meisten Erfolge bringen.
Betrachtet man den vorhin vorgestellten Ablauf, so gibt es grob vier Hebel, über die sich die Ladezeit verringern lässt:
Diese Zeit ist in unserem Ablauf Schritt 1-4. Sie ist also die Zeit, die der Browser benötigt, um eine Antwort vom Server zu erhalten. Sie wird auch oft TTFB (“Time to first Byte”) genannt.
Alles unter 100ms ist großartig. Google PageSpeed Insights empfiehlt hier eine Ladezeit von unter 200ms.
Mit der Standard-Version von Shopware, dem richtigen Server liegt diese meist bei und einem aufgewärmten Cache liegt diese meist sogar unter 100ms. Shopware ist in der Hinsicht also bereits ziemlich optimiert. Allerdings haben wir bereits öfter gesehen, dass die Server-Antwortzeit durch Plugins verschlechtert werden kann. Hierbei reichen bereits 200-400ms aus, damit sich der Online-Shop deutlich langsamer anfühlt.
Die letzten drei Hebel spielen sich in Schritt 5-6 ab. Bei diesem Hebel ist das Ziel, weniger Ressourcen zu verwenden. Ressourcen sind dabei Dateien, die ebenfalls auf dem Server liegen (z.B. Bilder, CSS- und JS-Dateien, etc.) und während des Renderings angefragt werden. Für jede Ressource muss der Browser eine weitere Anfrage an den Server schicken und ggf. warten, bis diese heruntergeladen wurde, wodurch die Ladezeit verschlechtert wird.
Dieser Schritt ist eigentlich selbsterklärend. Je schneller die Ressourcen (Bilder usw.) geladen werden, desto schneller baut sich der Onlineshop auf.
Bei diesem Punkt betrifft und eigentlich nur Javascript. Im Standard ist Shopware hier ebenfalls bereits sehr optimiert. Bei einigen Kunden mussten wir allerdings bereits feststellen, dass im JS-Code Drittanbieter Seiten aufgerufen wurden. Wichtig ist hierbei, dass solche Anfragen anderer Seiten immer asynchron passieren und den Kunden während der Aufrufzeit nicht daran hindern, weiterhin im Shop unterwegs zu sein.
Viele kennen dieses Tool wahrscheinlich bereits. Die Verwendung gestaltet sich sehr simpel: Einfach die URL in das dafür vorgesehene Feld eingeben und auf “Analysieren” klicken.
Vorteilhaft an dem Pagespeed-Tool ist zunächst einmal die Unterscheidung von “Mobil” und “Desktop”. Zusätzlich werden wichtige Daten vereinfacht dargestellt. Unter anderem gibt es hierbei den Google-PageSpeed-Score (die Zahl ganz oben in der Mitte). Dieser dient erstmal als grundlegende Orientierung, sollte aber nicht zu wichtig genommen werden. Ein Score von ca. 80 ist auf der Desktop-Ansicht beispielsweise bereits ausreichend für einen schnellen Shop.
Hierbei empfehlen wir euch, die Tests nicht nur mit der Startseite durchzuführen. Da auf dieser meist Einkaufswelten-Elemente eingesetzt werden, könnten die Testergebnisse verfälscht dargestellt werden. Tests mit der Detailseite sind meist eindeutiger.
Bei diesem Tool wird es nun etwas genauer.
Vorteilhaft ist hier, dass wir zunächst den Standard des Testservers bestimmten können. Im Standard empfehlen wir hier “Germany” auszuwählen. Wer eine internationale Kundschaft hat, kann die Seite aber auch von anderen Standorten prüfen.
Neben einem “Performance grade” sieht man hier auch wieder sofort wichtige Daten wie die “Load time”. Liegt diese Zahl bei maximal 3 Sekunden, ist laut Google alles ok. Zusätzlich findet man Auskunft über die Größe der Seite bzw. deren Ressourcen und die Anzahl der Requests, auf die wir vorhin bereits eingegangen sind.
Weiter unten sieht man eine Auflistung aller geladenen Ressourcen und deren Größe, Ladedauer etc. Die Ladezeit des ersten Eintrags entspricht dabei der Serverantwortzeit (auch TTFB).
Die Detailseite eines frisch aufgesetzten Demo-Shops hatte bei mir folgende Werte:
Auch hier darf der Performance-Grade nur als grobe Orientierung und nicht als wichtigster Messwert für die Ladezeit dienen.
Wer die Seite nicht immer bei PageSpeed Insights oder Pingdom eingeben möchte, kann die Werte auch in der Entwickler-Konsole auslesen. Hierzu öffnet man zunächst die Entwickler-Konsole (bei Firefox geht das über “Rechtsklick => Element untersuchen”) und öffnet dann den Netzwerk-Tab (bei Firefox “Netzwerkanalyse” genannt).
Hier seht Ihr ähnlich wie bei Pingdom eine Auflistung aller Ressourcen, deren Größe, Ladezeit usw.
Nachdem Du gelernt hast, wie der Ablauf beim Laden einer Webseite funktioniert und wie man wichtige Werte messen kann, kommen wir nun zu den vier großen Bereichen, bei denen wir in Shopware Performance-Optimierungen vornehmen können.
In jedem Bereich fangen wir mit dem jeweils einfacheren Einstellungen an und arbeiten uns zu den aufwändigen Anpassungen hoch.
Die Grundlage eines jeden Shops ist zunächst einmal der richtige Hoster. Dabei sollten wichtige Fragen geklärt werden:
Hier die Punkte, auf die man achten sollte:
Die einfachste Variante beim Hosting ist das sogenannte “Shared Hosting”. Dabei teilen sich mehrere Shops denselben Server. Der größte Vorteil ist hierbei, dass solche Pakete meist günstiger sind, was allerdings auf die Performance geht.
Dieses Paket empfehlen wir daher nur kleineren Kunden, deren Reichweite entsprechend noch nicht so hoch ist.
Diese Variante des Hostings kostet i. d. R. mehr als Shared Hosting, allerdings stehen einem hierbei alle Ressourcen des Servers zur Verfügung.
Größeren Kunden empfehlen wir aufgrund der Performance-Vorteile immer einen eigenen Server.
Bei beiden Namen handelt es sich um eine Server-Software. Es gibt also Server, die mit Nginx und welche, die mit Apache laufen. Unserer Erfahrung nach würde Apache bei Shops mit kleiner Besucherzahl noch ausreichen.
Geht es allerdings in Richtung +50.000 Seitenaufrufen pro Tag, empfehlen wir auf jeden fall nginx, da nginx besser mit vielen Anfragen und gerade mit “Besucher-Spitzen” besser klar kommt, als Apache.
Grundlage jedes Shops ist zunächst der Hoster. Den richtigen zu finden kann sich dabei als Laien relativ schwierig gestalten. Hierbei empfehlen wir zunächst darauf zu achten, dass es sich um einen Hosting Partner von Shopware handelt. Eine Liste der aktuellen Partner findet ihr hier: https://www.shopware.com/de/partner/list/group/hosting
Die Partner eignen sich zum einen, weil sie alle Voraussetzungen für Shopware erfüllen und manchmal sogar Shopware-Hosting-Pakete anbieten, die speziell für Shopware-Shops zugeschnitten sind.
Des Weiteren haben diese Hoster bereits Erfahrung mit Shopware und sind dahingehend meist bereits optimiert und können bei Problemen schneller und effizienter helfen.
An dieser Stelle möchten wir euch kurz unseren klaren Favoriten unter allen Hostern vorstellen: TimmeHosting. Neben Shopware-Hosting-Paketen gibt es auch Managed vServer & Managed Server für mehr Leistung. Alle Server laufen mit NGINX, der Support ist sehr gut erreichbar und hilft einem stets gerne bei seinen Problemen.
Des Weiteren konnten wir in der Vergangenheit bereits bei mehreren Kunden die Erfahrung machen, dass Server mit ähnlichen Kapazitäten bei TimmeHosting meist günstiger waren, als beim alten Hoster. Zusätzlich übernimmt TimmeHosting den Shop-Umzug kostenlos.
Shopware läuft aktuell mit der Programmiersprache PHP. Viel muss man als Shopbetreiber nicht wissen, allerdings gibt es ein paar wichtige Punkte:
Zunächst empfehlen wir dringend mindestens PHP 7.0 zu verwenden, da diese Version im Vergleich zum Vorgänger (PHP 5.6) deutliche Performance-Vorteile aufweisen kann. Wenn möglich, sollte zusätzlich auf PHP 7.2 umgestellt werden. Ab Shopware 5.6 kann dann auch PHP 7.3 verwendet werden.
Zusätzlich ist ein Bytecode-Cache empfehlenswert. Shopware selbst empfiehlt hierbei ZendOpcache + APCu.
Dieses Tool baut auf dem Google PageSpeed Insight auf, welches wir weiter oben zum Messen der Ladezeiten verwendet haben. Ist das Modul aktiviert, soll die Webseite automatisch nach den Vorgaben des Insight-Tests optimiert werden.
Hauptvorteil sind hierbei die Bilder. Diese werden nämlich automatisch ein einem optimierten Format (bei den Bild-URLs im Shop wird z.B. ein “.pagespeed.xyz.png” angehangen) ausgegeben, sofern der Browser dies unterstützt, wodurch sie kleiner sind und schneller geladen werden können.
Hierbei ist allerdings Vorsicht geboten. Wir hatten auch einige Fälle erlebt, in denen die Aktivierung dieses Modules die Performance sogar verlangsamte. Da man das Modul relativ schnell ein und wieder ausschalten kann, würde sich ein kurzer Test sicherlich lohnen. In den anderen Fällen, wo das Module keine Probleme bereitete, konnten geringere Ladezeiten (vor allem für Bilder) festgestellt werden.
In Shopware laufen die Sessions im Standard über die Datenbank. Um diese bei hohen Besucherzahlen zu entlasten, kann für die Sessions auch Redis oder Memcached verwendet werden.
Hierzu muss das jeweilige Tool zunächst auf dem Server vorhanden sein. Hier ein Beispiel für Redis:
//php.ini
...
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379"
//config.php
…
'session' => [
'save_handler' => 'redis',
'save_path' => "tcp://127.0.0.1:6379",
],
'backendsession' => [
'save_handler' => 'redis',
'save_path' => "tcp://127.0.0.1:6379",
]
Auch hier ist Vorsicht geboten. Wir konnten bei einem Kunden z. B. feststellen, dass der JTL-Connector mit Redis nicht klar kommt und deshalb die Sessions weiterhin über die Datenbank laufen mussten. Hier ist wie beim PageSpeed Module ein kurzer Test sinnvoll.
Bei Elasticsearch handelt es sich um eine sogenannte “search engine”. Diese ist auf das schnelle Suchen in sehr großen Datenmengen optimiert.
Diese Engine betrifft bei Shopware hauptsächlich das Listing, die Shopware Suche und einige Module im Backend. Da das Listing gecached wird, könnte man hier noch darüber diskutieren, ob es hierfür relevant ist.
Unserer Meinung nach ist es dennoch wichtig das Listing zu berücksichtigen, da der Cache zum einen deutlich schneller aufgewärmt werden kann und die Seiten bei nicht aufgewärmten Cache (falls mal was im Shop angepasst wird), dennoch performant bleiben.
Hier einige Zahlen von Tests, die wir mit der Shopware-Suche durchgeführt haben:
|
Elasticsearch |
Standard (MySQL) |
|
| 300 Produkte |
20-40ms |
40ms |
| 30.000 Produkte |
~80ms |
~100-150ms |
|
300.000 Produkte |
~100-150ms |
~5-15s |
Auch im Backend konnten wir einen deutlichen Unterschied feststellen. Gibt es z. B. 300.000 Artikel im Shop, braucht die Artikelübersicht mit MySQL (Standard) zwischen 10-15 Sekunden. Ist Elasticsearch integriert, sind es nur noch 50-200ms.
An dieser Stelle möchte ich noch kurz darauf hinweisen, dass Elasticsearch eine Optimierung ist, die sich nur für sehr große Shops lohnt. Wie man den obigen Tests entnehmen kann, lassen sich die ersten, leichten Verbesserungen erst ab 30.000 Artikeln messen. Wirklich lohnen wird es sich wahrscheinlich erst ab ~150.000 Artikeln (dies entspricht auch Shopwares Empfehlung). Hierzu kommen noch die Kosten für Einrichtung & Co.
Mit der Enterprise Lizenz von Shopware darf man den Shop auch auf einem “Cluster Setup” betreiben.
Bei einem Cluster-Setup werden im Grunde statt einem Server mehrere Server und Server-Komponenten verwendet. Neben wichtigen Punkten wie Erreichbarkeit und Skalierbarkeit ist ein weiterer großer Vorteil eine Verbesserung der Ladezeit. Zum Beispiel werden Kunden über einen Loadbalancer auf mehrere Appserver verteilt, die wegen der geringeren Kundenanzahl nicht so ausgelastet sind und schneller arbeiten können.
Zusätzliche Komponenten wie Elasticsearch, Redis/ Memcached Session-Handling, Redis-Cache etc. sind nicht zwingend notwendig, optimieren die Performance allerdings nochmal zusätzlich.
Da ein Cluster erst mit Shopware Enterprise eingesetzt werden kann, lohnt es sich natürlich nur für wirklich sehr große Shops. Daher gehe ich im folgenden nur sehr grob auf die Vorteile eines Clusters ein. Alles könnt ihr euch aber auch nochmal genauer hier durchlesen.
Damit ein Cache für alle Appserver verwendet werden kann, lohnt es sich den Cache in Redis auszulagern.
Sorgt dafür, dass bei Cache Invalidierung auf einem AppServer dieser auch auf allen Appservern invalidiert wird.
Mehrere Datenbanken sind für Shopware im Einsatz. “Write-queries” werden gehen an die primary-Verbindung und “Read-queries” an die replicay-Verbindungen. Hierdurch wird die Datenbank entlastet.
Statt MySQL wird Redis für die Nummernkreise verwendet. Hierdurch wird die Datenbank zusätzlich entlastet.
Zusätzliche Elemente (ProductGateway, Übersetzungen etc.) können gecacht werden und sorgen für schnellere Ladezeiten.
Grundlegend für einen performanten Shopware Shop ist der Shopware-Cache. Hierbei ist es Pflicht, einen Cronjobs zum Leeren und Aufwärmen hinterlegt. Was Cronjobs genau sind und wie man sie einrichtet, kannst Du hier nochmal nachlesen.
Einen Cronjob zum Cache-Leeren gibt es in Shopware bereits unter dem Namen “Clear HTTP Cache”. Diesen sollte man in der Nacht ausführen lassen. Ein geeigneter Zeitpunkt wäre z. B. 03:00 Uhr morgens. Hierbei muss allerdings darauf geachtet werden, dass ein externer Cronjob eingerichtet ist, der die “Cronjobs” von Shopware anstößt.
Mit “Aufwärmen” ist hierbei gemeint, dass jede wichtige Seite im Shop einmal aufgerufen und der Cache dementsprechend befüllt wird. Dieser Cronjob sollte kurz darauf (15 Minuten) laufen.
Diesen müsste man allerdings ganz auf dem Server einrichten, da es hier in Shopware keinen für gibt. Wie man ihn einrichtet kannst Du in dem oben verlinken Blogbeitrag nachlesen. Der benötigte Befehl lautet “php bin/console sw:warm:http:cache”.
Die hier hinterlegten Einstellungen passen im Standard bereits, sollten allerdings nochmal überprüft werden, falls während der Entwicklungsphase etwas umgestellt und vergessen wurde.
Hierfür öffnet ihr einfach den Theme-Manager und klickt neben “Themes neu laden” auf “Einstellungen”.
Wichtig ist, dass “Neuladen der Textbausteine erzwingen”, “Compiler Caching deaktivieren” & “CSS Source Map erstellen” deaktiviert sind.
Wichtig wäre es außerdem, einen kurzen Blick in die config.php-Datei von Shopware zu werfen. Hierbei könnten einzelne Einstellungen überschrieben worden sein. Wenn “forceCompile” auf “true” gesetzt ist, wurde das Compiler-Caching deaktiviert, was die Ladezeit extrem reduziert. Im Standard von Shopware ist diese Datei bis auf den Eintrag “db” leer. Falls hier etwas auffällt, solltest Du deinem Entwickler oder uns Bescheid geben, um hier nochmal genauer nachzuschauen.
“CSS komprimieren” & “JavaScript komprimieren” sollten hingegen aktiv sein, damit die Dateien dafür kleiner sind und damit schneller geladen werden können.
Nun schauen wir uns die Einstellungen eines einzelnen Themes an. Hierzu klicken wir im Theme-Manager auf ein Theme und gehen danach auf “Theme konfigurieren”.
Sicherlich nur ein kleine Verbesserung, allerdings lohnt es sich für die mobilen Viewportgrößen kleinere Logos zu hinterlegen, damit diese mobil schneller geladen werden.
Sollte aktiv sein. Alternativ kann die Pagination verwendet werden. Bei beiden Optionen sollte darauf geachtet werden, dass nicht zu viele Artikel sofort im Listing angezeigt werden. Ziel ist es hierbei, nur so viele Artikel, wie sie beim Seitenaufruf ohne Scrollen sichtbar sind, anzuzeigen. Hierdurch werden keine unnötigen Bilder geladen, die der Kunde erstmal nicht sieht.
Diese Option sollte auch aktiv sein. Hierdurch wird im Frontend nicht darauf gewartet, bis die Javascript-Datei geladen wurde. Bei schlecht programmierten Plugins/ Themes könnte es allerdings zu Fehlern kommen.
Wer in Shopware schonmal mit den Einkaufswelten gearbeitet hat weiß, dass bei jedem Element neben dem roten ‘Löschen’-Button auch einen blauen “Entfernen”-Button gibt, mit dem man das Element für die aktuelle Viewport entfernen kann, das Element aber nicht vollständig gelöscht wird. Das Element sieht man dann, wenn man sich die für diesen Viewport ausgeblendete Elemente anzeigen lässt.
Diese Elemente werden im Frontend zwar nicht angezeigt, allerdings trotzdem geladen. Bei der Einrichtung von Einkaufswelten kann es schnell vorkommen, dass man Elemente entfernt und dann vergisst. Hierbei sollte man also in jeder Einkaufswelt kurz prüfen, ob es Elemente gibt, die in keinem Viewport angezeigt werden und diese entsprechend löschen.
Achtet allerdings darauf, dass Ihr keine Elemente löscht, die auf einem anderen Viewport angezeigt werden, weil die Elemente nämlich auf allen Viewports gelöscht werden.
Diese Einstellung findet Ihr beim Öffnen der Performance-Modules im Backend unter “Einstellungen > Caches/ Performance”. Direkt bei der Startansicht solltet Ihr auswählen, dass Ihr den Shop im Produktivmodus verwenden möchtet, damit der HTTP-Cache aktiviert wird und der Shop entsprechend deutlich performanter läuft.
Sicherheitshalber sollte man im Reiter “Einstellungen” unter “HTTP-Cache” nochmal prüfen, ob der HTTP-Cache auch wirklich aktiv ist.
In der selben Ansicht findet ihr zusätzlich die Punkte “SEO”, “Suche”, “Sitemap”, “Topseller” & “Empfehlungsmarketing”. Bei all diesen Optionen sollte die “Aktualisierungsstrategie” nicht auf “Live”, sondern auf “Cronjob” stehen.
Zusätzlich müsstet Ihr prüfen, ob folgende Cronjobs korrekt eingerichtet und aktiviert sind:
Neben sicherheitstechnischen Gründen ist ein Shopupdate auf die aktuellste Version auch immer sinnvoll, damit der Shop performanter wird.
Mit dem Update auf Shopware 5.5 wurden z. B. in Shopware eingesetzte Technologieren wie Symfony oder jQuery auf eine höhere Version aktualisiert.
Shopware 5.6 bietet neben verbesserten Technologien wie “HTTP/2-Push” und “HTML-Minifizierung” noch einen weiteren großen Vorteil: PHP 7.3 kann im Shop eingesetzt werden.
Im Onlineshops werden Hauptsächlich JPG, PNG & SVG-Formate für Bilder verwendet. Natürlich gibt es noch viele andere, allerdings sind dies die Formate, die wir am meisten sehen. Auch bei Bildern gilt das Motto: Je kleiner desto besser.
Am besten sind hierbei SVG-Bilder. Diese Art von Bildern (Vektorgrafiken) sind grundsätzlich anders aufgebaut als JPG & PNGs. Dadurch haben sie meist eine kleinere Dateigröße & lassen sich auch beliebig hoch skalieren, ohne dass sie unscharf werden. Da das Erstellen eines SVGs etwas aufwendiger ist, werden sie oft nur für Logos, Icons usw. verwendet.
Bei JPG-Bildern handelt es sich wie bei den PNGs um Rastergrafiken. PNG-Bilder bieten dabei den Vorteil, dass sie einen transparenten Hintergrund haben können.
Ein großer Nachteil ist aber, dass sie im Vergleich zu JPG-Bildern schlechter komprimiert werden können.
Wir empfehlen daher immer auf JPG-Bilder zu setzen und nur in Ausnahmen (wenn z. B. ein transparenter Hintergrund benötigt wird) PNG-Bilder zu verwenden.
Grundsätzlich empfiehlt es sich, alle Bilder, die im Shop verwendet werden sollen, über den MediaManager hochzuladen. Ein großer Vorteil ist hierbei die Thumbnail-Generierung.
Shopware nimmt sich dabei das Originalbild und erstellt aus diesem Thumbnails mit bestimmten Maßen. Diese Thumbnails werden dann entsprechend auch leicht komprimiert, damit sie noch kleiner sind. Zusätzlich werden noch passende Thumbnails für Retina-Displays erstellt.
Die Einstellungen wie Thumbnail-Maße, Komprimierungsgrad & Retina-Thumbnails können pro Album im MediaManager eingestellt werden. Daher muss man hier auch aufpassen, dass die Bilder möglichst nicht in dem Album “Unsortiert” hochgeladen werden, da für diesen keine Thumbnails generiert werden. Alle Standard-Alben wie “Artikel”, “Einkaufswelten” etc. haben bereits die richtigen Einstellungen.
Im Shopware-Standard-Theme werden bei vielen Komponenten (Artikel-Bilder, Einkaufswelten, etc.) bereits die richtigen Thumbnails im Frontend angezeigt. Bei eigenen Anpassungen oder gar Themes kann es allerdings vorkommen, dass bei der Programmierung nicht darauf geachtet wurde, die richtigen Thumbnails zu verwenden. Dies kann dazu führen, dass zu große Bilder verwendet werden, wodurch die Ladezeit zunimmt.
Eine guter erster Anhaltspunkt ist die Verwendung von dem “srcset”-Attribut, da hier Viewport-abhängig verschiedene Thumbnails geladen werden. Dies stellt sicher, dass z. B. auf mobilen Geräten kleinere Thumbnails geladen werden, was der Ladezeit wieder zugute kommt. Shopware selbst achtet auch hier z. B. in den Einkaufswelten darauf. Bei individuellen Plugins, die mit Bildern arbeiten, sollte dieser Punkt auch beachtet werden.
Bei der Auswahl von Plugins gibt es eine Regel, die immer beachtet werden sollte: weniger ist mehr.
Jedes Plugin, dass in deinen Shopware Shop installiert wird, bedeutet grundsätzlich eine Abnahme der Performance.
Hierbei gibt es große Unterschiede, wie die Plugins programmiert wurden und ob sich bei der Entwicklung auch Gedanken um die Performance gemacht wurde.
Als Shopware Agentur haben wir schon mehrfach erlebt, dass die Serverantwortzeit durch schlecht programmierte Plugins sehr stark negativ beeinflusst wurde. Die Serverantwortzeit ist in einigen Fällen pro Plugin um über 200ms gestiegen!
Wir empfehlen immer, die Plugins erst auf einer Testumgebung zu testen, um dort die Performance zu überprüfen. Wenn die Geschwindigkeit dann abnimmt, weißt du, dass es an dem neuen Plugin liegt!
Friends of Shopware hat schon vor längerer Zeit das Performance Plugin herausgebracht. Dieses Plugin eignet sich besonders für Shopware Shops vor der Version 5.6.
Das Plugin integriert folgende Funktionen:
Es wäre für dich also vielleicht einmal ein Versuch wert, dieses Plugin zu testen!
Zusätzlich bietet es sich gerade für Shops mit vielen Bildern an, das sogenannten Lazy Loading einzusetzen.
Durch Lazy Loading werden Artikelbilder erst dann fertig geladen, wenn der Nutzer sich im Bereich des Bildes befindet.
Um die Serverauslastung auf Dauer zu reduzieren, können Bilder und weitere Inhalte auf ein sogenanntes CDN ausgelagert werden. Die Inhalte werden beim abrufen dann von dem CDN-Server geladen und nicht von dem Server, auf dem sich dein Shopware Shop befindet.
Wie Du siehst, ist es nicht ganz so einfach, die Performance Deines Shopware Shops zu optimieren. Wir empfehlen daher immer, sich im Voraus ein Bild von Deinem Shop zu machen um alle IST-Zustände festzuhalten.
Viele Maßnahmen sollten nicht von Dir selbst durchgeführt werden, da es hier sehr häufig zu zerstörten Liveshops kommst. Wir empfehlen Dir daher immer, die Agentur deines Vertrauens zu kontaktieren, damit diese im Notfall deinen Shop so schnell wie möglich wieder herstellen kann.
Unsere Standorte
Zentrale
Technologiepark 23
33100 Paderborn
Leipzig
Bernhardstraße 34
04315 Leipzig
Kontakt
E-Mail: support@8mylez.com
Telefon: +49 (0) 5251 284 710
Shopware Dienstleistungen
Über 8mylez
✓ 38 Mitarbeiter
✓ Shopware Gold Partner
✓ 40.000+ Plugin Downloads
✓ 160+ betreute Shops
✓ Full-Service Shopware Agentur
✓ 70 Shopware Videos auf Youtube
✓ Alle Shopware Zertifizierungen
Social
Was denkst du?