Performance - Wie man PrestaShop Beine macht

[Scully]

Ich lesen in den verschiedenen Forums-Bereichen immer mal wieder über Probleme mit der Performance von PrestaShop. Dazu einige Erfahrungen, wie man PrestaShop performant betreiben kann. Ladezeiten von unter 2 Sekunden sind oft auch ohne Hexerei möglich.
 
Server / Hosting
Wer den Shop auf einem shared Hostingpaket laufen lässt, wird fast immer an Grenzen stossen. Der Hosting - Provider wird nach Möglichkeit soviele Webseiten auf einem Server laufen lassen, wie möglich. Deshalb die Empfehlung für einen dedicated Server. Da hat man als Shopbetreiber nicht nur die Ressourcen für sich sondern meist auch mehr Konfigurationsmöglichkeiten.
 
PrestaShop Cache Settings
Diese findet man in Backoffice - Erweiterte Einstellungen - Performance. Wir haben gute Erfahrungen mit folgenden Einstellungen gemacht:
 
Smarty Cache

Generell empfehlen wir, Smarty Cache einzuschalten. In Verbindung mit dem Modul Advanced EU Compliance kann es jedoch zu fehlerhaften Anzeigen führen. Hier berichten Users, dass das Abschalten des Smarty-Cache hilft.

 

Template-Kompilierung
Templates nach Datei-Änderungen neu kompilieren. Wenn man keine Tests mehr macht, kann man auch auf "Nie kompilieren" setzen. Dabei nicht vergessen, dass man den Smarty Cache dann bei Änderungen manuell leeren muss.
 
Optionale Funktionen
Varianten und Eigenschaften deaktivieren, wenn man diese Funktionalität nicht nutzt. Ebenso Kunden-Gruppen, wenn man keine unterschiedlichen Preisregeln für Kunden-Gruppen nutzen möchte.
 
CCC
Smarty Cache für Stylesheets: EIN
Smarty Cache für CSS: EIN
Reduzierung des HTML-Inhaltes: AUS (entgegen vielfachen Hinweisen stellen wir eine verschlechterung der Performance fest, wenn aktiviert)
Javascript ans Ende verschieben: EIN
 
Media Server
Es kann sinnvoll sein, Ressourcen wie Bilder, Javascript oder CSS über einen oder mehrere Media-Server auszuliefern. Allerdings nur dann, wenn der Media-Server mindestens gleich performant ist wie der Shop selbst. Über die Browser Developer Tools kann man das recht gut überprüfen.
 
Cache (letzte Option)
DEAKTIVIERT, ausser man weiss genau, was man tut. Insbeondere der Filesystem Cache führt häufig zu einer deutlichen Verlangsamung des Systems.
 
Installation von Modulen
Es gilt der Grundsatz: je mehr Module installiert werden, desto langsamer wird das System. Jedes Modul beansprucht Verarbeitungszeit. Und nicht alle Module sind in Bezug auf Performance optimal entwickelt. Daher der Tipp: Vor der Installation eines neuen Moduls überlegen, ob es für den Shopbetrieb essentiell ist. Nicht (mehr) benutzte Module deinstallieren und nicht nur deaktivieren.
 
Themes
Verschiedentlich liest man auch Berichte über Themes, welche zu Performanceeinbussen führen. Vor einer allenfalls aufwändigen Adaption eines neuen Themes kann es sich lohnen, Demoseiten des Themes zu besuchen oder zu recherchieren, wo das Theme im produktiven Einsatz steht und die jeweiligen Nutzer zu deren Erfahrungen zu befragen. Oft zeigt auch schon ein Besuch einer Demoseite, ob das Theme performant arbeitet.
 
Multi Language
Mehrere Sprachen führen zu zu einer exponentiellen Vergrösserung der Datenbank. Zahlreiche Tabellen führen die Sprach-ID als Wert - nicht nur für Produkte. Einhergehend ist damit in der Regel eine spürbare Einbusse der Performance. Auch werden Redirects von der Hauptdomain zur passenden Sprache gemacht, z.B. von beispiel.com auf beispiel.com/de/. Diese Redirects benötigen ebenfalls Zeit und führen im Prinzip zu einer Verdoppelung der Ladezeit für den Text-Content.

 

Grösse der Startseite (Speicherumfang)

Als sinnvolle Faustregel kann man sagen: 1 bis 2 MB auf der Startseite nicht überschreiten. Das bekommt man hin, wenn man nicht ewig grosse Bilddateien verwendet (siehe auch nachfolgend: Image Slider) und extrem viele Zusatzmodule am Laufen hat. Die Grösse der Startseite hat verschiedene Aspekte, welche die Ladezeiten direkt und indirekt betreffen:

 

a ) Bandbreite: Je langsamer eine Verbindung, desto länger dauert die Übertragung.

b ) Anzahl zu ladende Objekte: Meist gilt: Je umfangreicher die Seite, desto mehr einzelne Objekte (Bilder, CSS, Javascript) werden geladen. Jeder Zugriff beansprucht alleine für den Verbindungsaufbau schnell 20 bis 50 ms. Bei 100 zu ladenden Objekten sind schnell 2 bis 5 Sekunden Ladezeit vergangen.

c ) Javascript und CSS sind häufige "Bremser". Javascript wird für die Ausführung von Programmelementen auf dem Client (Browser) genutzt. CSS ist zuständig für die Art der Darstellung (Design, Farben, Schriften). Bei beidem gilt im Grundsatz folgendes: Bis nicht die letzte Anweisung aus diesen Dateien geladen ist, beginnt der Browser nicht mit dem Rendering-Prozess (=Anzeige / Formatierung der Ausgabe). Je grösser diese Dateien, desto länger wird potentiell das Rendering verzögert. Gleiches wie für die Startseite gilt im Prinzip auch für Unterseiten. Trotzdem ist die Startseite als "Eingangstor" zum Shop sicher die wichtigste Visitenkarte.

 

Image Slider

Image Slider erfreuen sich allgemein höchster Beliebtheit. Meines Erachtens nicht immer zu Recht. Man muss sich im Klaren sein, dass i.d.R. alle Slider-Bilder erst geladen werden, bevor sich in der Anzeige etwas tut. Optimiert man diese Bilder nicht in Bezug auf Grösse und Kompression, so hat man schnell 1 bis 1.5 MB an zusätzlichem Datenvolumen. Auch mit geeigneter Kompression (was PrestaShop nicht wirklich kann), hat man schnell 500 KB oder mehr an Daten beisammen.

 

Zudem sind viele Slider in der Grösse so skaliert, dass diese auch auf grossen Bildschirmen ohne Scrollen 90 bis 100% des sichtbaren Seiteninhaltes in Anspruch nehmen. Wichtige andere Seiteninhalte werden dadurch unnötig in den Hintergrund verbannt. Wenn Silder: dann sollte dieser nicht mehr als etwa 50% der verfügbaren Höhe nutzen.

 

PayPal
Wir haben beim Standard-Paypal Module regelmässig beobachtet, dass sich die Performance zum Schlechten verändert. Man würde ja annehmen, dass dieses Modul erst im Warenkorb bzw. bei der Bezahlung Auswirkungen hat. Dem ist nicht so! PayPal sendet bei jedem Seitenaufruf Logging-Daten an PayPal - selbst wenn noch gar nichts im Warenkorb ist. Diese zusätzlichen Post-Requests benötigen jenachdem gerne mal 2 oder 3 Sekunden Zeit. Behelfen kann man sich, indem man Hooks des PayPal-Modules überall dort entfernt, wo es nicht um die eigentliche Zahlungsabwicklung geht.

 

Tracking Services

Aus unserer Beobachtung sehe ich, dass viele Shopbetreiber Tracking-Services nutzen, teilweise auch mehrere unterschiedliche Systeme. Google-Analytics, Goodle-Adwords, Facebook seien als prominente Beispiele erwähnt. Ja, auch hinter einem vermeintlich simplen Facebook-Button steht in der Regel in Tracking Service. Allen diesen Diensten sind mehrere Dinge gemeinsam:

- Sie übermitteln beständig Daten an die jeweiligen Zielserver.

- Sie verzögern den Seitenaufbau, wenn entsprechende Hooks im Header genutzt werden.

- Sie sind in der Regel nur dann sinnvoll, wenn man die Auswertungs-Tools kennt und zu nutzen weiss und auch wirklich einsetzt.

- Sie nützen oft dem Anbieter des Tracking-Service sehr viel mehr als dem Shopbetreiber.

 

Bezüglich der Impacts verweise ich auf einen Ausfall bei Facebook vor ca. 6 Monaten. Viele Webseiten waren seinerzeit nicht mehr aufrufbar, weil sie sich mit Facebook verbanden, dieser Dienst jedoch gestört war. Per Default wartet ein Browser meist 30 Sekunden bis er mit einem Timeout reagiert. Solange wartet aber kein Shopbesucher, bevor er sich "ausklinkt".

 

Tipps für den Umgang, wenn man solche Services nutzen möchte

Zusehen, dass alle relevanten Aktionen im Footer Hook stattfinden. Wenn es dann eine Störung gibt, ist nicht gleich der gesamte Seitenaufbau tangiert.

Teilweise kann man auch Hooks deaktivieren. Interessant sind vor allem die Daten, wenn eine Warenkorb angelegt oder eine Bestellung durchgeführt wird. Oft kann man deshalb die meisten Hooks löschen, welche nicht mit diesen Aktivitäten in Zusammenhang stehen.

 

Unnötige Redirects
Auch häufig beobachtet sind redirects (Umleitungen), welche mehrfach in ungünstiger Sequenz ablaufen. Jeder Redirect liefert erst einmal die gewünschte Seite aus, was seine Zeit beansprucht. Wenn man nun z.B. von

http://beispiel.de

auf

http://www.beispiel.de

und dann auf

https://www.beispiel.de

umleitet, dann wird die aufgerufene Seite drei mal ausgeliefert. Bei redirects ist des daher sinnvoll, bei Bedarf Regeln in .htaccess so zu hinterlegen, dass obige Kombinationen gar nicht auftreten. In diesem Kontext sei auch darauf hingewiesen, dass das Weglassen des Präfix "www" in der Regel ein Vorteil ist. Tippt man in der Browseradresszeile eine URL ein, dann lässt man www i.d.R. weg. Das heisst - der Browser sucht ersmal, ob er die Domain auch ohne Präfix findet. Findet dann eine Umleitung auf www statt, kostet auch diese Zeit.
 
Datenbank
Von Hause aus läuft PrestaShop auf den meisten MySQL - Standardeinstellungen ganz gut. InnoDB ist in der Regel MyISAM als Engine vorzuziehen. Ein Mix unterschiedlicher Engines ist negativ in Punkto Performance. Wer sehen möchte, wie optimal der Shop auf der eigenen Datenbank läuft, kann z.B. das Script mysqltuner.pl auf den Server herunterladen und ausführen.
 
https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
 
Es zeigt in anschaulicher Weise, wie die verschiedenen Ressourcen und Buffers genutzt weden.
 
Datenbank-Tabellen von Zeit zu Zeit optimieren
Die Datenbanken und die dazugehörigen Indexe sollten von Zeit zu Zeit neu aufgebaut werden. Der Grund ist, dass die Tabellen-Indizes mit zunehmenden Einträgen fragmentiert werden, d.h. der Indexzugriff dadurch verlangsamt wird. Wichtig sind dabei vor allem diejenigen Tablelen mit vielen Einträgen. Über phpmyadmin kann man in der Tabellenansicht diese Tabellen auswählen und am Ende der Liste im Drop-Down den Befehl "optimize table" bzw. "Optimiere Tabellen" auswählen. Hier eine Auswahl von Tabellen, in denen das sinnvoll wäre:

ps_search_index
ps_product_tag                    
ps_search_word                   
ps_category_product                         
ps_image_shop                    
ps_image_lang                    
ps_image                        
ps_tag_count                        
ps_product_lang                        
ps_stock_available                        
ps_specific_price_priority                   
ps_layered_price_index                        
ps_product                   
ps_specific_price                    
ps_product_shop                        
ps_feature_product 

NGINX
nginx ist auf unseren System nicht im Einsatz. Meines Erachtens erhöht es die Komplexität des Systems, rewrite Rules und anderes muss dafür adaptiert werden. Indes führte es nach bei uns durchgeführten Tests kaum zu signifikanten Verbesserungen, jedoch immer mal wieder zu Stolpersteinen. Wer ohne nginx bereits 10 Sekunden Ladezeit für die Startseite hat, wird es auch mit nginx nicht auf einen passablen Wert bringen.

Edited September 13, 2017 by Scully (see edit history)

[Claudiocool]

Sehr gute Info, die mit vielen Mythen aufräumt!

[Scully]

Ach gibt es Mythen? Ja stimmt. Reduktion des HTML - Inhalts. Verbraucht auf dem Server i.d.R. viel mehr Zeit als es auf dem Client Zeit einspart.

Habe gerade noch zu nginx und Silders was ergänzt.

Edited August 13, 2017 by Scully (see edit history)

[preisfischer]

Tolle Infos, habe sie direkt umgesetzt. Zusätzlich habe ich noch das Modul "PrestaShop Cleaner" installiert und verwendet, das hat ne Menge gefunden und behoben. Weiters habe ich gesehen, dass Google PageSpeed eine Integration für Apache anbietet, sollte man das verwenden oder ist das über?

 

https://developers.google.com/speed/pagespeed/module/

[Scully]

ui Google Pagespeed

Google Pagespeed hat eine Unschönheit. Man kann die Expiration des Google Pagespeed Cache nur schwer steuern. Wenn man Änderungen am Shop vornimmt, kann es Stunden oder auch mal Tage dauern, bis diese sichtbar werden. Wenn man Änderungen zeitnah testen will, bliebe somit nur die "einfache" Variante, PageSpeed abzuschalfen. Dafür ist jedoch oft auch ein Eingriff in die .htaccess notwendig. Als auch nicht ganz "On-the-Fly".

 

Wir nutzen dieses Modul deshalb nicht (mehr) ein.

 

edit: Ich habe noch etwas zu Datenumfang und Tracking Services hinzugefügt.

Edited September 7, 2017 by Scully (see edit history)

[Scully]

Gerade eben bei den "Streifzügen" zwei Shops entdeckt, die man in die Liste der weniger performanten Shops aufnehmen könnte.

 

Shop 1: Startseite 12.6 MB, davon ca. 10 MB Bilder, Anzahl Objekte 137. Ladezeit 47 Sekunden

Shop 2: Startseite 4.2 MB, davon 1.7 MB Javascript, Anzahl Objeke 78, Ladezeit 32 Sekunden

 

Beide Messungen mit leerem Browser-Cache. Was wohl in 1.7 MB Javascript alles drin steckt?

 

Noch eine Ergänzung zum PS Cleaner und dem Post von preisfischer.

 

Wir nutzen den Cleaner auch regelmässig - aber um korrekt zu sein. Der Cleaner "behebt" keine Fehler sondern er löscht Datensätze, für welche die referentielle Integrität nicht mehr gegeben ist. Solche Inkonsistenzen kann es primär aus zwei Gründen geben:

 

1. Objektdaten werden (im Prestashop Backend) nur teilweise gelöscht. Ob aus Nachlässigkeit oder um die Ausführungszeiten im Backend nicht negativ zu tangieren. Beispiel: Löscht man aus dem Katalog ein Stichwort (Tag), dann wird dieses Tag nur aus der Tabelle ps_tags gelöscht. Die Zuordnung von Tags zu Produkten in ps_product_tag bleibt jedoch erhalten, obschon das Tag selbst nicht mehr vorhanden ist. Solches Verhalten gibt es an etlichen Stellen in PrestaShop.

 

2. Aufgrund maneuller Datenbank-Eingriffe (z.B. durch Löschen von Datensätzen aus einzelnen Tabellen, Verändern von Auto-Increment-Werten) wurde die referentielle Integrität verletzt.

 

PS Cleaner räumt nun mit diesen Datenleichen auf. Bei denjenigen aus obigem Nr. 1 ist das wunderbar und verringert auch die Datenvolumen der DB. Bei den Löschungen welche aufgrund von Nr. 2 erfolgen, können im schlechten Fall jedoch produktiv relevante Daten verloren gehen.

 

Fazit zum PS Cleaner: Der ist gut und hilfreich, wenn man in der Datenbank nicht unsachgemäss selbst Hand angelegt hat. In diesem Fall kann man die Option 3 "Einschränkungen der funktionalen Integrität" ohne Probleme laufen lassen. Ist man unsicher, macht man vor der Ausführung einen Backup.

 

Und noch ein Mythos:

Bei einigen Systemen zeigen sich die folgenden Tabellen als wahre Speicherfresser:

 

ps_connections - > Loggt jede Verbindung von einem Client zum Shop.
ps_connections_source -> Loggt, von welcher Seite ein Benutzer zum Shop verlinkt wurde.

ps_connections_page -> Loggt jede Seite, die ein Besucher im Shop aufruft.

 

Diese Tabellen loggen (leider) auch alle Crawler, Suchmaschinen und allerlei unerwünschte Bots, die den Shop beusuchen. Oft macht dieser Verkehr mehr Anteil an den Verbindungen aus als effektive Kunden. Alle diese Daten kann man bei Bedarf getrost löschen, z.B. so:

truncate table ps_connections;
truncate table ps_connections_source;
truncate table ps_connections_page;

Es werden  dadruch keine für den operativen Betrieb relevanten Daten gelöscht. Man verliert jedoch die Information im Kundenstamm unter dem Titel "Letzte Verbindungen" - vielen Shopbetreibern wird aber gar nicht aufgefallen sein, dass es diese Information überhaupt gibt.

 

Wenn die Tabelle ps_connections_page gefüllt wird, liegt das an der Einstellung im Modul Statistik - "Seitenaufrufe jedes Kunden speichern". Die angehäufgen Datenmengen sind kaum so wertvoll, als dass man nicht auf diese Option verzichten könnte.

Edited August 14, 2017 by Scully (see edit history)

[Scully]

Aus aktuellem Anlass.... gerade haben wir wieder mal eine Seite mit Antwortzeiten um 15 bis 20 Sekunden Beine gemacht.

Bösewicht war ein Modul "Redirections URL (301 / Auto-fixing / Multishop / SEO) Module".

 

Modul deinstalliert und die Antwortzeiten verbesserten sich auf einen Schlag auf ca. 1.5 bis 3 Sekunden. Und natürlich haben wir nicht auf Anhieb dieses Modul verdächtigt, da es sich erstmal als eher unscheinbar präsentierte sondern der Reihe bzw. dem Gefühl nach mühsam Module um Module geprüft.

 

Das ist wieder ein klassisches Beispiel dafür, dass ein Modul manchmal wenig Vorteile aber dafür erhebliche Nachteile mit sich bringt. Darum mein stetiges Mahnen: Module nur dann definitiv im Betrieb belassen, wenn diese einen deutlichen Mehrwert für den Shop darstellen. Bei einer zu grossen Zahl von Modulen ist das leider nicht gegeben. In diesem Fall => deinstallieren

Edited September 6, 2017 by Scully (see edit history)

[rictools]

Ich habe übrigens gestern etwas gelesen, was mir neu war:

 

Durch die Nutzung von HTTP/2 läßt sich die Geschwindigkeit teils erheblich erhöhen, HTTP/2 funktioniert aber nur in Verbindung mit SSL und nur wenn es der Hoster unterstützt, was aber nicht mehr ungewöhnlich ist. In diesem Fall läuft der Shop mit SSL schneller als ohne oder mit nur teilweisem - so hatte ich es bisher eingestellt - SSL.

[Scully]

Danke für Deinen Input Christian. Ich werde das gelegentlich testen und über die Ergebnisse berichten.