Jump to content

Extreeeeeem lange Ladezeiten vom Shop

SweetBeauty

By SweetBeauty
in Generelle Fragen

 Share

Recommended Posts

SweetBeauty Newbie

SweetBeauty

Posted
Posted

Hallo,

 

wir haben ganz große Schwierigkeiten mit den Ladezeiten unseres Webshops.

 

Prestashop 1.6.1.14

Template: Lorena

Hosting: 1und1 - Unlimited Plus

 

Leider wissen wir nicht welche Einstellungen wir noch ändern sollen damit die Ladezeit sich verbessert.

 

https://sweetbeauty-shop.de

 

Vieleicht hat ja jemand paar Minuten Zeit und Lust sich das anzusehen und Hilfestellung zu geben.

 

 

Vielen Dank schon mal

Link to comment
Share on other sites
Claudiocool Enthusiast

Claudiocool

Posted
Posted

Da müsste man sich mal die ganzen Settings (BO/Leistung) und auch die serverseitigen Settings ansehen. So ist das schwer zu sagen. Inhaltlich gibts da auch noch viel zu tun, vor allem funktionieren die rechtlichen Angaben im Footer nicht, da landet man dann auf einer 404-Seite.

 

kann sein, dass man da in ein paar Minuten ein paar Ansätze findet, aber ich vermute mal, dass der Shop noch viel Feinarbeit braucht, bis der wirklich startbereit ist

  • Like 1
Link to comment
Share on other sites
SweetBeauty Newbie

SweetBeauty

Posted
  • Author
Posted (edited)

Hallo

 

vielen dank für den 404 Hinweis, habe den Fehler nun behoben.

 

Folgende Einstellungen sind im Shop ausgewählt:

 

Smarty:

Templates nach Datei-Änderungen neu kompilieren - ausgewählt

Cache: JA

Cache Typ: Dateisystem

 

 

Cache löschen: Cache nach jeder Änderung löschen

 

Debug-Modus:

Nicht von PrestaShop entwickelte Module deaktivieren: NEIN

Alle Overrides deaktivieren: JA

 

Optionale Funktionen:

Varianten: JA

Eigenschaften: JA

Kundengruppen: JA

 

CCC:

Smart Cache für Stylesheets: JA

Smart Cache für Javascript: JA

Reduzierung des HTML-Codes: JA

Kompression von JavaScript im HTML-Code: JA

JavaScript ans Ende verschieben: JA

Apache-Optimierung: JA

 

Media-Server:

keine zusätzlichen Eintragungen vorhanden

 

Cache:

Cache verwenden: NEIN

 

 

Webdienste--> Einstellungen:

Webservice aktivieren: JA

PHP CGI mode aktivieren: JA

 

 

Voreinstellungen-->Allgemein:

SSL aktivieren: JA

SSL auf allen Seiten aktivieren: JA

Front-Office Sicherheit verbessern: JA

Iframes in HTML-Felder erlauben: NEIN

HTMLPurifier verwenden: JA

 

 

 

 

Serverdaten:

 

Serverdaten Linux info 3.0 #1337 SMP Tue Jan 01 00:00:00 CEST 2000 all GNU/Linux Linux info 3.0 #1337 SMP Tue Jan 01 00:00:00 CEST 2000 all GNU/Linux Linux info 3.0 #1337 SMP Tue Jan 01 00:00:00 CEST 2000 all GNU/Linux

 

Version der Server-Software Apache

 

PHP-Version 7.0.20

 

Speichergrenze 128M

 

max_execution_time 30

Edited by SweetBeauty (see edit history)
Link to comment
Share on other sites
Claudiocool Enthusiast

Claudiocool

Posted
Posted (edited)

okay,

 

mach dir mal eine php.info, dann kann man sehen, wie die Serversettings sind, nebenbei kannst du gleich mal klären, ob eine php.ini erlaubt ist, in der man die Settings des Shops optimieren könnte.

 

Die info.php machst du selbst, in dem du die Date ierzeugst und folgenden Inhalt einfügst, danach hochladen und aufrufen. Später nach vollendeter Arbeit aber nicht vergessen, sie zu löschen. Zweckmäßigerweise nennst du sie nicht info.php, sodern irgendwie anders, so dass nicht Hinz und Kunz jetzt kommt und auf deinem Server schnüffelt... :)

 

BTW: Wenn ich dir weiterhelfen kann, bin allerdings erst am späten Abend wieder online, jetzt muss ich was arbeiten :D

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Server-Informationen</title>
</head>

<body>
<?PHP
phpinfo ();
?>
</body>
</html>
Edited by Claudiocool (see edit history)
Link to comment
Share on other sites
SweetBeauty Newbie

SweetBeauty

Posted
  • Author
Posted

Moin,

 

@Claudiocool: Datei wurde erstellt, Informationen abgerufen, DAtei gespeichert und dann gelöscht. Soll ich dir die irgendwie zusenden?

 

@rictools: Die "sinnlosen" Marken sind nur ein Bild kein Modul. Habe es aber erstmal deaktiviert.

 

 

Vielen Dank.

Link to comment
Share on other sites
Claudiocool Enthusiast

Claudiocool

Posted
Posted (edited)

Ja, die Serversettings haben wir ja jetzt mal etwas optimiert, jetzt muss man eben mal schauen, was der Shop selbst so macht :)

 

Was mir jetzt auffällt, ist dass auf der Startseite 30 Angebot stehen, allerdings werden die on the fly skaliert, das bedeutet, dass der Shop beim Laden 30 Bilder runterrechnen muss, das kostet auf einem langsamen Server Zeit bis zur Auslieferung, die schnell in einen Timeout mündet. Ob der Slider oben sein übriges dazu tut, weiß ich nicht.

 

Ich denke, man sollte jetzt mal die Bildergeschichte genauer unter die Lupe nehmen,

Edited by Claudiocool (see edit history)
Link to comment
Share on other sites
SweetBeauty Newbie

SweetBeauty

Posted
  • Author
Posted (edited)

@ Claudiocool

 

Die letzten Änderungen aus der E-Mail hab ich eingefugt. der opcache füllt sich auch.

 

Paket bei 1und1: UNLIMITED PLUS

 

Die Sliderbilder sind auf jeden Fall mit Photoshop für Web otimiert.

 

Ich werde die Anzahl der Bilder auf der Startseite mal auf 15 setzten. Die 15 Bilder sind auch per Photoshop optimiert.

Edited by SweetBeauty (see edit history)
Link to comment
Share on other sites
SweetBeauty Newbie

SweetBeauty

Posted
  • Author
Posted (edited)

Hallo,

 

entschuldigt bitte das ich mich nicht mehr gemeldet habe, aber es war in letzter Zeit viel zu tun.

 

Ich glaube die Ladezeit ist jetzt etwas besser geworden. Vieleicht schaut Ihr ja mal drauf bei Gelegenheit.

 

 

Laut Google PageSpeed Insights funktioniert die Komprimierung immer noch nicht.

Edited by SweetBeauty (see edit history)
Link to comment
Share on other sites
Claudiocool Enthusiast

Claudiocool

Posted
Posted

Google insights zeigt bei mir auch keine Komprimierung an, ist aber vorhanden.

 

Bei dir werden die Vorschaubilder immer noch skaliert, das sollte geändert werden, so dass der Shop für jede Anzeige eigene Bilder hat, das dürfte es dann eher beschleunigen.

Weiter solltest du die CCC alle einschalten, das dürfte auch noch ein wenig rausholen, weil der dann weniger Daten abliefern muss.

 

Mach das mal :-)

Link to comment
Share on other sites
Scully Newbie

Scully

Posted
Posted (edited)
Sinnvoll wäre dabei, den Shop die Vorschaubilder generieren und abspeichern zu lassen, dann muss der die nicht mehr skalieren und muss sie somit gar nicht erst umrechnen.

 

Zu diesem Hinweis erlaube ich mir einen Kommentar.

Prestashop geht von Hause aus nicht sehr optimal mit JPEG um. Optimal komprimierte Bilder werden von PS in der Tat selbst nochmals komprimiert.

Damit ist am Ende die Qualität schlechter aber die Datei grösser. Ist leider so.

 

Genau deswegen haben wir die Funktion z.B. für den Upload von Shop - Logos so geändert, dass diese Dateien von Prestashop ohne jeder Änderung in unsere Shops eingelesen werden. Das macht eben dann Sinn, wenn wir diese JPEG vorher auf Optimum Grösse / Kompression trimmen. Das ist aber nur ein Detail.

 

Zur Problem der Ladezeit:

Der Shop lädt auf der Startseite rund 1.2 MB. Das halte ich für grenzwertig bis eher zu viel. Wir kommen meist mit 500 bis 700 KB aus. Alleine deswegen ist er aber nicht so langsam. Overall lädt der Shop rund 4 bis 6 x langsamer, als unsere Demo-Shops, welche jeweils rund 100 Kategorien und 2'000 Produkte aufweisen.

 

Von aussen lässt sich das nur sehr bedingt analysieren. Man sieht mit Debug-Tools wohl, wie die Zeiten sind und dass sie verbesserungsfähig sind, nicht jedoch, woher die langen Ladezeiten genau herrühren. Als Beispiel: Das reine HTML der Startseite lädt bei diesem Shop etwa 20x langsamer, als unsere Startseite.

1900 ms versus ca. 80 bis 100 ms.

 

Getestet haben wir gegen diesen Shop - nur um zu zeigen, dass wir nicht Fantasie-Werte hier einstellen:

https://nextrade.ch/

 

Warum gibt es solche Unterschiede?

Wir setzen Server ein, welche für ein PrestaShop - Setup optimiert sind. Alles läuft auf SSD, die Maschinen haben ausreichend RAM und CPU.

Wir setzen MySQL-Einstellungen für eine optimale Konfiguration ein, welche wir aus vielen Tests ermittelt haben.

Wir nutzen nach Smarty noch einen 2nd Level Cache nebem Smarty.

Wir setzen nur Module und Funktionen ein, welche wir nutzen und darauf nicht verzichten können.

Alles andere muss weg. Weg = Deinstallieren.

 

Jedes Modul beansprucht irgendwo Ladezeiten. Manchmal wenig, manchmal aber auch satt im Sekundenbereich.

Wir lassen einen eigenen kleinen Mini-Crawler alle Seiten auf unseren Shops endlos abrufen. Ca. 1 Seite alle 3 Sekunden.

Das führt dazu, dass der Cache immer aktuell bleibt und fast nie ein Cache Rebuild notwendig ist, wenn ein echter Besucher die Seite anschaut. Insgesamt also ein Puzzle aus vielen kleinen Stellschrauben.

 

Und noch ein PS:

Die Optionen Reduzierung des HTML-Codes sowie Kompression von JavaScript im HTML-Code kann man getrost vergessen. In allen bisher analysierten Seiten haben diese Optionen keine Verbesserung, manchmal aber eine Verschlechterung der Ladezeiten ergeben.

 

Toi toi toi und gutes Gelingen mit dem Shop.

Edited by Scully (see edit history)
Link to comment
Share on other sites
Claudiocool Enthusiast

Claudiocool

Posted
Posted

Dazu folgendes....

 

Den Smarty kannst du in der EU beim Einsatz von AdvancedEUCompliance aus lassen, sonst kommt da ein Fehler mit den Lieferzeiten, den noch nie jemand gefixed hat.

Wenn du einen Cache-Warmer einsetzt, um die Ladezeiten zu optimieren, kann es gut sein, dass da das eine oder andere nicht so sauber läuft, wobei das hauptsächlich vom PS-Core herrührt.

Im Prinzip ist es beim Presta so, dass die Usability gegeben ist, wenn der unter 2 Sek. Ladezeit bleibt, im Shop aus dem Thread hier sind wir ja schon ein Stück weitergekommen, weil der Server ziemlich basic konfiguriert war. Hier haben wir schon das eine oder andere Rädchen gedreht, das passt insgesamt.

 

bei den Bildern kann ich dir wiedersprechen, die werden bei dem hier besprochehen Shop skaliert, d.h., die werden vermutlich nur in einer Größe auf dem Server gespeichert und der bedient sich dann dort und skaliert on the fly. Besser ist es, die Bildersache so zu konfigurieren, dass der die Slalierung schon im Upload erledigt und die jeweils passende Größe dann ohne Umweg zum Browser geschickt wird. dann die Bilder vo dem Upload fürs Web optimieren (geht ganz easy im Photoshop), dann können theoretisch 1000 Bilder auf die Startseite, das stört kaum, weil ohnehin nur der visible range geladen wird.

 

Der Second-Level-Cache kann funktionieren, aber in der Regel bemerkt man den Unterschied, der einem hier suggeriert wird, nirgends, das User-Feeling ist hier nicht 1:10 wie einem die Ladezeiten z.B. bei Seobility vielleicht suggerieren würden.

 

Die Nutzung der CCC-Settings bringt entgegen deiner Ansicht einiges, vergleicht man die Seitenquellteste in den jewiligen Einstellungen, sieht man schnell, warum das so ist, der Browser kriegt es dann so serviert, wie der Seitenaufbau passenderweise erfolgt, dann wird auch tatsächlich geladen, was benötigt wird, ohne das lädt er Sachen, die man noch nicht braucht, bevor er das holt, was als nächstes nötig wäre.

 

Beim Server gebe ich dir recht, hier ist Performance angesagt, Presta ist hier sehr hungrig, was ich an allen Ecken und Enden zeigt. WP z.B. ist da trotz ähnlich großer Datenmengen deutlich weniger anspruchsvoll, das zeigt sich dann in wrklich schnellen Ladezeiten, selbst auf relativ lahmen Servern kann man hier einigermaßen vernünftige Ergebnisse erzeieln, beim Presta ist das leider nicht so, der frisst Ressourcen ohne Ende,

  • Like 1
Link to comment
Share on other sites
Scully Newbie

Scully

Posted
Posted (edited)
Den Smarty kannst du in der EU beim Einsatz von AdvancedEUCompliance aus lassen, sonst kommt da ein Fehler mit den Lieferzeiten, den noch nie jemand gefixed hat.

 

Heisst das, dass der Smarty cache beim Einsatz des Adv.-EUCompliance dann komplett aus ist? Das wäre ja nicht im Sinne der Sache.

 

Wenn du einen Cache-Warmer einsetzt, um die Ladezeiten zu optimieren, kann es gut sein, dass da das eine oder andere nicht so sauber läuft, wobei das hauptsächlich vom PS-Core herrührt.

 

Wir arbeiten nun etwa zwei Jahre mit diesem System. Keine Probleme soweit. Allerdings: nachts um ca. 3h löschen wir alle Caches und bauen alles Daten jeweils neue auf.

 

Im Prinzip ist es beim Presta so, dass die Usability gegeben ist, wenn der unter 2 Sek. Ladezeit bleibt, im Shop aus dem Thread hier sind wir ja schon ein Stück weitergekommen, weil der Server ziemlich basic konfiguriert war. Hier haben wir schon das eine oder andere Rädchen gedreht, das passt insgesamt.

Zwei Sekunden ist grundsätzlich ein guter Wert. Das sehe ich auch so. Der Shop ist Stand aktuell auch keineswegs mehr "unterirdisch" unterwegs. Potential gibt es immer.

 

Beim Server gebe ich dir recht, hier ist Performance angesagt, Presta ist hier sehr hungrig, was ich an allen Ecken und Enden zeigt. WP z.B. ist da trotz ähnlich großer Datenmengen deutlich weniger anspruchsvoll ...

 

So auch unsere Erfahrung. WP bennötigt viel weniger Ressourcen als PrestaShop. Das liegt vor allem an den viel komplexeren Datenstrukturen mit viel mehr dynamischem Datenanteil von PrestaShop. Wordpress kann man bei normalen Seiten problemlos statisch cachen und die Daten z.B. einmal am Tag neu aufbauen. Bei Prestashop haben wir dynamisch u.a. Benutzernamen, Warenkörbe, Preise, Filter-Auswahlen und Sortierkriterien welche immer à Jour sein müssen. Sogesehen lassen sich diese Systeme auch nicht direkt vergleichen.

Edited by Scully (see edit history)
Link to comment
Share on other sites
Claudiocool Enthusiast

Claudiocool

Posted
Posted

Ja, der Smarty-Cache läuft mit EU-Compliance unsauber. Es macht sich schnell bemerkbar, dass bei den Lieferzeitenangaben plötzlich die Übersetzungen fehlen, was besonders dann auffällt, wenn man mehrsprachig unterwegs ist. Bei manchen Systemen wird dann die Zeile gleich zweimal gezeigt.

 

Ob jetzt der Smarty-Cache oder EU-Compliance der "Übeltäter" ist, lässt sich so nicht 100% sagen, was allerdings sicher ist, keiner geht dran, hier einen Workaround anzustossen. Ich habe den bei mir dann ausgemacht und soweit es ging, die Settings auf dem Server optimiert, um das etwas zu kompensieren. Letztendlich musste hierfür auch PHP 7.0.x herhalte, obwohl ich den Rest mit 7.1.x betreibe. Deswegen auch meine Anmerkung mit dem Cachewarmer, das ist gerade bei wenig frequentierten Systemen durchaus ein probates mittel, den Shop geschmeidig wirken zu lassen.

  • Like 1
Link to comment
Share on other sites
Scully Newbie

Scully

Posted
Posted (edited)

Aber die Hooks sind ja nicht das Problem sondern dass wie von Dir vermutet Smarty-Cache und das Eu-Compliance Modul nicht sauber zusammenarbeiten.

Normalerweise prüft ja ein Modul in enem Hook erstmal, ob es den Smarty-Cache für den Hook bzw. das Modul schon gibt.

Wenn ja, lädt es aus dem Cache und gibt dies als Return der Funtkion zurück.

Jetzt könnte man der Funktion einfach vorgaukeln, dass es keinen Smarty-Cache gibt. Damit wäre dieser Cache-Level generell aktiviert, jedoch nicht mehr für dieses konkrete Modul.

 

Vielleicht stelle ich mir das aber viel einfacher vor, als es ist. Von aussen betrachtet, müsste ein solches Modul ja nicht allzuviel können, ausser bei allen Seiten beim Erstbesuch einen Overlay mit Button einblenden. Falsch gedacht?

 

Kannst Du evtl. per PN einen Link auf den Quellcode des Moduls oder ein ZIP zur Verfügung stellen? Ich brauche das Modul ja selbst nicht, aber vielleicht einmal 5 Min. reingucken in den Quellcode.

Edited by Scully (see edit history)
Link to comment
Share on other sites
Scully Newbie

Scully

Posted
Posted

Gerade mal installiert. Und was macht der Shop? Erster Seitenaufruf nach der Installation dauert dann 30 Sekunden.

Danach schneller, aber doch eine spür- und messbare Verlangsamung. Hab noch nie ein Modul gesehen, dass etwas im ersten Schuss so langsam macht.

Angezeigt im Front-End wurde aber trotzdem nichts, trotz rudimentärster Konfiguration.

 

Und ja, es ist schon so, dass dieses Modul eine Menge .tpl referenziert. Man kann diese wohl trotzdem rausnehmen und testhalber schauen, ob es dann mit Smarty läuft, aber nicht "on the fly" machbar.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...