dusticelli Posted April 6, 2016 Share Posted April 6, 2016 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 More sharing options...
kulli Posted April 7, 2016 Share Posted April 7, 2016 Das erinnert mich an folgende Einstellung: Voreinstellung - Templates - Mobil Wird es auch "zerschossen" wenn Du hier "immer deaktivieren" einstellst ? Link to comment Share on other sites More sharing options...
eleazar Posted April 7, 2016 Share Posted April 7, 2016 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 More sharing options...
dusticelli Posted April 7, 2016 Author Share Posted April 7, 2016 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 More sharing options...
eleazar Posted April 7, 2016 Share Posted April 7, 2016 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 More sharing options...
dusticelli Posted April 8, 2016 Author Share Posted April 8, 2016 Ok, wir werden nochmal einen Test gegen den Shop deiner Frau machen, wenn ich das Template umgestellt habe. 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 More sharing options...
kulli Posted April 8, 2016 Share Posted April 8, 2016 Bei meinen Seiten ist (war) es das google analytics script was noch so gebremst hat. Link to comment Share on other sites More sharing options...
dusticelli Posted April 8, 2016 Author Share Posted April 8, 2016 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 More sharing options...
kulli Posted April 8, 2016 Share Posted April 8, 2016 (edited) da gibt es Cache-Fehler auf der Seite: ReferenceError: productHasAttributes is not defined das ist ein nginx-Server, da gibt es was im englischen Forum drüber. Hast Du denn die gleichen Probleme auch auf einem Apache ? Edited April 8, 2016 by kulli (see edit history) Link to comment Share on other sites More sharing options...
dusticelli Posted April 8, 2016 Author Share Posted April 8, 2016 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 More sharing options...
dusticelli Posted April 8, 2016 Author Share Posted April 8, 2016 p.s.: Habe gerade im Original (vor meinen letzten Änderungen) auf 100% Apache geguckt, und da ist der Fehler "ReferenceError: productHasAttributes" auch mit dabei.. Link to comment Share on other sites More sharing options...
dusticelli Posted April 9, 2016 Author Share Posted April 9, 2016 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 More sharing options...
kulli Posted April 9, 2016 Share Posted April 9, 2016 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 More sharing options...
dusticelli Posted April 9, 2016 Author Share Posted April 9, 2016 (edited) 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 April 11, 2016 by eleazar URL entfernt (see edit history) Link to comment Share on other sites More sharing options...
kulli Posted April 10, 2016 Share Posted April 10, 2016 (edited) 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 April 10, 2016 by kulli (see edit history) Link to comment Share on other sites More sharing options...
dusticelli Posted April 10, 2016 Author Share Posted April 10, 2016 (edited) 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 April 11, 2016 by dusticelli (see edit history) Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now