Jump to content

Speedup my site Projekt - stockt wegen Smart CSS Cache


Recommended Posts

Hallo Leute,

 

ich habe  nun wieder etliche Stunden verbracht um das Standard Bootstrap Theme nach meinem Geschmack anzupassen, damit der Shop nochmal ne 1/2 Sekunde schneller wird.

 

Soweit bin ich auch mit dem Design ganz zufrieden. Eigentlich habe ich nur CSS Klassen und IDs angepasst. Die meisten habe ich sogar nur überschrieben indem ich eine eigene CSS verwende die am Schluss geladen wird. Ich verwende dafür eine Modul von DH42, das nennt sich "CSS Editing Module".

 

Soweit ich das überblicke schreibt es die Override Styles direkt in den <head> untehalb der anderen css Dateien die geladen werden. Ich habe aber auch schon das Modul deaktiviert, und meine Overrides in eine separate custom.css geschrieben, die dann als letzte Datei geladen wird.

 

Jedenfalls ist mein Problem folgendes:

 

Wenn ich auf maximale Geschwindigkeit schalte (das jeisst bei mir unter "Leistung" alles auf "an") dann läuft der Shop zwar super auf Desktop, aber auf mobilen Screens zerschießt es mir das Design total.

 

Mit meinem Debugging bin ich zumindest soweit, dass dieses Problem nur besteht, sobald der "CSS Smart Cache" eingeschaltet ist.

 

Ist dieser nicht eingeschaltet, ist allles auch mobil ok.

 

Meine Frage:

 

Gibt es irgendeine probate Methode um herauszufinden, wer/warum das Design bei eingeschaltetem Smart CSS Cache zerschossen wird?

 

thx

Link to comment
Share on other sites

Gibt es irgendeine probate Methode um herauszufinden, wer/warum das Design bei eingeschaltetem Smart CSS Cache zerschossen wird?

 

Müßig, da das einer der Gründe ist, warum das Bootstrap-Template aus 1.7 verschwindet! Im übrigen gilt auch bei PrestaShop der Leitsatz "Viel hilft viel" in Bezug auf die Performance-Leistung nicht. Die optimalen Einstellungen findest du hier: https://www.prestashop.com/forums/topic/344822-beste-cache-einstellung-f%C3%BCr-prestat-15-und-16/?do=findComment&comment=1837927

(Die empfiehlt übrigens auch dh42, dessen Modul du benutzt.)

Wenn also die Cache-Einstellungen für CSS die mobile Darstellung zerschießen. dann lass es einfach und schaff dir lieber ein detailliert konfigurierbares Cache-Modul wie z.B. Pagecache an.

 

Immer erstmal einen Blick in den Spoiler meiner Posts werfen: https://www.prestashop.com/forums/topic/483650-tipps-und-tutorials-hilfreiche-links/ ;)

Link to comment
Share on other sites

Moin moin,

 

@ kulli,

 

danke, ich hatte diese Einstellung für ein Relikt aus alten (Presta-) Tagen gehalten und dachte, da wird dann so ein komisches mobiles Template die mal ne Weile in Mode waren geladen, und da ich ja das standard-bootstrap (responsive) Theme nutze, dachte ich auch das wäre überflüssig. Jedenfalls stand das bei mir schon immer auf "immer deaktivieren" und demzufolge wäre die Antwort: Ja, auch damit zerschießt es die mobile Darstellung.

 

Habs auch mal probehalber dauerhaft aktiviert, und damit wird es natürlich auch zerschossen. :(

 

@ eleazar

 

ich kenne diese Hinweise auf die optimale Einstellung. Danke.  Im Grunde ist mein Shop jetzt auch mit deaktiviertem CSS Smart Cache ziemlich schnell. Das ist eher ein Perfektionismus-Problem. Als Sturkopf will ich einfach nicht einsehen, dass der Cache ja mit dem Standard-Bootsrap funktioniert, und nachdem ich rund 300 Zeilen CSS überschrieben/ergänzt habe, soll das nicht mehr der Fall sein?! Das kann ich eigentlich nicht anzeptieren. Und Google würde natürlich auch sagen, "das kann man besser machen. Zuviele CSS Dateien werden geladen blablabla..."

 

Wenn ich den Smartcache richtig verstehe, dann packt er ja alle CSS-files in eine zusammen und löscht die überflüssigen Leer-Räume.

 

Da bei mir also diese Komprimierung nur in der mobilen Ansicht versagt, hätte ich zunächst gedacht es liegt vielleicht an den 2-3 @media queries, die ich angefasst habe. Probeweise hatte ich diese aber rausgenommen und trotzdem blieb das Prolblem.

 

Ich glaube ich werde testweise auch nochmal versuchen alle "Überschreibungen" direkt in die jeweilige *.css Datei zu packen um es dann nochmal zu probieren. Im schlimmsten Fall könnte ich auch ohne den Smartcache klar kommen.

 

Dabei aber noch eine Frage, die sich mir gerade auftut:

 

Wie verhält sich das eigentlich mit der Update-Sicherheit? Wäre das richtige Vorgehen, dass ich erst eine Kopie des Bootstrap Theme mache (im Backend)

 

Voreinstellungen > Templates & Vorlagen > Neues Template erstellen > Vorhandenes Template duplizieren...

 

und daran dann die Änderungen?

 

Und, warum kann ich eigentlich nicht einfach ein Template per FTP (nicht als Zip) hochladen, und der Shop erkennt es als neue Alternative? Muss ich da in der Datenbank noch irgendwas zuordnen? Weiß das einer?

 

Btw: Der Tip mit dem "Pagecache" ist auch nicht so schlecht. Das Ding flitzt ja in der Demo ungeheuerlich. Ich würde das nur gerne vorher testen, und das geht ja leider nicht mit Presta (bei Shopware kein Problem). Rund 100€ finde ich schon nicht ganz billig um nicht 100% zu wissen, ob der mit der eigenen Seite auch so performant wird..

Link to comment
Share on other sites

Hier mal ein Beispiel einer von mir betreuten Website (gehört meiner Frau, Prestashop 1.5.6.2 mit Modul PacheCache):

http://www.webpagetest.org/result/160407_N6_18VB

http://www.alexa.com/siteinfo/fadenkreuz-shop.de

 

Zum Vergleich deine eigene unter denselben Bedingungen:

http://www.webpagetest.org/result/160407_EN_19HY/

http://www.alexa.com/siteinfo/Mr-fuss.com

 

Na ja, stimmt nicht ganz, weil ich mit Slidern und Hochglanzfotos ganz spartanisch hausieren gehe. Mich persönlich nervt nichts so sehr in einem Shop wie Slider und herumschwirrende Bilder, die mich als Kunden nur vom Stöbern abhalten. Aber, wie gesagt, meine Meinung ... :)

Link to comment
Share on other sites

Ok, wir werden nochmal einen Test gegen den Shop deiner Frau machen, wenn ich das Template umgestellt habe. :D

 

Ich verstehe diese Messungen von webpagetest nicht. 11 Sekunden habe ich immer nur dort. Pingdom lädt die Seite aus Amsterdam beim ersten mal mit 3,3 Sekunden. Ich weiss nicht, ob die irgendwie extra extrem viel Last erzeugen, oder so, aber ich behaupte diese Messung entspricht nicht den realen Bedingungen. Aus meiner subjektiven Mesusng lädt meine Seite je nachdem mit ansprechender Technik und guter DSL Verbindung so ca. 1,5 bis 2.5 Seiten aus D. Das ginge noch.

 

Aber, wie gesagt ich werde jetzt mal mit einen Standard-Bootstrap und weniger Schnick-Schnack einen Test fahren. Mal sehen ob ich dann mehr verkaufe.

 

Ein Nadelöhr hat mein derzeitiges Template auf jeden Fall:

 

Wenn ich die Seite mit meinem (inzwischen schon bissi alten) Ipad 3 lade, dann braucht sie doch etliche Sekunden. Vielleicht macht webpagetest ja die Messung mit vergleichbarer Technik.

 

Was das genau ist, keine Ahnung. Mit dem Iphone wieder ist sie normal schnell, und ich habe mir sagen lassen, mit dem neuen Ioad auch..

 

Also, vielleicht werde ich ja diesen Page-Cache testen, wenn ich mit dem Template fertig bin, mal sehen..

Link to comment
Share on other sites

Ich glaub bei mir muss es etwas anderes sein. Wie gesagt, die Seite lädt überall in D so mit sagen wir mal 2-3 Sekunden. Nur der blöde webpagetest macht da soe ein Horrorszenario draus, und, mein Ipad3. :)

 

Der webpagetest Waterfall sagt ja auch was anderes. Da ist es vor allem der Firstbyte 4.764s der schon mal ordentlich einschlägt. Dabei bin ich auf einen eigenen V_Server umgezogen, und finde z.B. selbst, dass gerade hier der Wechsel von all-inkl. zu V-Server ordentlich zeit gebracht hat.

 

Wie kann man eigentlich selbst am Firstbyte schrauben?

 

Und bei mir sieht es ja optisch (Waterfall) so aus, als würden auch die redirects von

 

domain.com

 

zu

 

www.domain.com

 

und

 

https://www.domain.com

 

viel zeit Kosten. Kann man das irgendwie besser machen?

Link to comment
Share on other sites

Hi kulli,

 

ja dieses "ReferenceError: productHasAttributes is not defined" hatte ich auch schon gesehen. Das ist aber kein Serverproblem, so wie ich das sehe, sondern ein Modul (Shippingcountdown) dass diesen Fehler produziert. Mein Server läuft mit "FPM über Apache" das war die einzige Konfiguration mit der ich den Nginx einigermaßen Fehlerfrei zum Laufen bekommen habe.

 

Wie gesagt, Ich glaube nicht, dass dieser Fehler durch die Servereinstellungen kommt. Glaube eher das Modul ist nicht 100% programmiert.

 

Muss ich mal dem Entwickler schreiben.

 

Was ich übrigens total merkwürdig finde, aber vielleicht ist es ja auch normal, wenn ich die CCCs anschalte aber unten den "Cache" (ganz unten) aus lasse, dann braucht der Shop immer für den ersten Aufruf einer Seite ewig, und danach geht es dann zackig.  Also, das wirkt so, als müsse man den Cache dann erst "aufwärmen" aber ist ja gerade eben nicht an, das macht doch eigentlich keinen Sinn.

Link to comment
Share on other sites

Es ist schon sehr merkwürdig. Wenn ich bei meinem Shop den Smarty Cache aktiviere, sind einigen Seiten nach dem 2.ten Aufruf zwar sehr schnell, aber bei manchen Seiten dauert der erste Seitenaufruf etliche Sekunden, z.B. 10+. Das ist ja völlig inakzeptabel. Also, der Shop läuft mit dem marty Cache aktiviert, total ungeschmeidig. Im Grunde nicht zu gebrauchen.

 

Besser ist es dann, wenn ich den Smarty Cache gar nicht aktiviert habe, dann sind die Seiten zwar einen ganz kleinen Tacken langsamer, vielleicht so etwa 200 ms, aber der Shop insgesamt läuft dann schön smooth.

 

Den unteren Cache kann man gar nicht benutzen, wenn man die Filterfunktionen vom Shop verwenden will, die gehen dann nämlcih nicht.

 

Habt Ihr schon mal ähnliche Erfahrungen gemacht? Oder ist das nur bei mir so...

Link to comment
Share on other sites

All das deutet für mich immer mehr darauf hin, das die Einstellungen des Servers nicht stimmen.

 

Bei wem liegt denn der Server ? V-Server ? Sind die zugesicherten Leistungen auch wirklich vorhanden ?

Mit welchem Tool kannst Du Einfluss auf die Servereinstellungen nehmen ? cPanel ? Plesk?

 

hier mal meine php 5.6: (ist aber kein vserver !)

-apcu -bcmath -dom -fileinfo -gd -imap -intl -ioncube_loader -json -mbstring -mcrypt -memcache -memcached -mysql -mysqli -mysqlnd -opcache -pdo -pdo_mysql -pdo_sqlite

-phar -soap -posix -sockets -suhosin -tidy -wddx -xsl -zend_guard_loader -zip

allow_url_fopen	On
always_populate_raw_post_data	0
apc.rfc1867	On
apc.rfc1867_freq	0
apc.rfc1867_name	APC_UPLOAD_PROGRESS
apc.rfc1867_prefix	upload_
apc.rfc1867_ttl	3600
date.timezone	UTC
default_charset	UTF-8
display_errors	Off
error_reporting	E_ALL
expose_php	On
file_uploads	On
geoip.custom_directory	no value
include_path	xxxxxxxxxxxxx
log_errors	On
mail.force_extra_parameters	no value
max_execution_time	60
max_input_time	-1
max_input_vars	4000
memory_limit	512M
open_basedir	no value
output_buffering	4096
post_max_size	16M
session.save_path	/tmp
short_open_tag	On
suhosin.get.max_value_length	2000
suhosin.post.max_vars	2000
suhosin.request.max_vars	2000
upload_max_filesize	16M
upload_tmp_dir	/tmp
xcache.admin.pass	xxx
xcache.admin.user	xxx
Link to comment
Share on other sites

Bei mir ist das ein V-Server von Netcups

 

 

 

8 Kerne, 24 GB RAM 320 GB SSD.

 

Läuft bei mir mit Plesk 12.5.30

 

Sieht soweit aber ok aus. Ich kann mal mit Deinen Einstellungen vergleichen. Wie schon gesagt läuft da Nginx Reverse Proxy mit Apache FPM.

 

Das von mir beschrieben Verhalten habe ich aber explizit mit dem Bootstrap Template. Wenn ich das andere auf dem gleichen Server nehme sind diese langen Ladezeiten nicht da.

 

Wo hostest Du Denn deinen Shop?

Edited by eleazar 
URL entfernt (see edit history)
Link to comment
Share on other sites

das gibt es durchaus Parallelen:

Bei netcup hatte ich 2015 einen ganz kleinen rootserver, die zugesicherten Leistungen waren aber gar nicht vorhanden, der Support konnte oder wollte das natürlich gar nicht verstehen.

Gerade zu dieser Zeit hatte ich die dort einen Prestashop und die PHP cache Erweiterungen liessen sich zwar einrichten, aktivieren und wurden auch in der phpinfo.php angezeigt, aber richtig funktioniert habe sie überhaupt nicht was beim Einschalten genau zu diesen Problemen geführt hat die Du schilderst.

Templateabhängig war das bei mir aber nicht - die Fehler traten beim Bootstrap genauso auf wie beim Silbersaiten-Theme.

Leider kann ich die Leistungen(oder nicht vorhandenen) von damals nicht mehr mit den Neuen vergleichen um zu finden wo der Fehler eventuell noch gelegen haben könnte.

 

zudem gab es nach der Kündigung noch Probleme beim Domainumzug (Authcodes waren ständig ungültig)

 

Edit: Du kannst ja mal einen Test machen und einen Shopware-Shop auf dem Server installieren um zu schauen wie der mit dem cache dort zurechtkommst; Du kommst ja aus der Ecke, ist ja in 10 Min. erledigt ;)

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

Hi kulli,

hier ist der Spielplatz

 

[/unpassend daher entfernt]

läuft mit PHP7 und wie sau! Cache ist an. Da könnte man glatt schwach werden. Aus Erfahrung weiß ich aber, dass die Shops (das gilt gleichermaßen für SW und Presta) mit den Demodaten immer sauschnell sind, wenn man dann seinen eigenen Content drin hat, sehen die Werte gleich ganz anders aus. Aber dennoch schnell isser da mal.

Jedenfalls habe ich in den Errorlogs wegen meinem SmartyCache Problem was gefunden. Leider scheint da ein Modul (der Visual Composer) irgendwie im Weg zu stehen. ab dem Entwickler da mal die Fehlermeldungen gesendet, mal sehen ob der weiterhilft...

Edited by dusticelli (see edit history)
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
×
×
  • Create New...