Ladezeit erste Seite verbessern - combine css/js

Hallo ! Ich habe dafür ein Ticket erstellt: http://trac.shopware.de/trac/ticket/100570 Leider habe ich zuwenig php Kentnisse um das (lt. Anleitung mit combine.php) einzubinden. Hier im Forum gibt es ja ein paar gute Programmierer…wäre das ein Plugin wert ?? Was ist eure Meinung… oder sind alle zufrieden mit der Ladezeit der ersten Seite ? Ich habe mit Optimierung der Bilder, JS kleiner machen und CSS zusammenfassen für meine Begriffe ein recht flottes Ergebnis erzielt. lg klaus

[quote=“klausm”]Hallo ! Ich habe dafür ein Ticket erstellt: http://trac.shopware.de/trac/ticket/100570 Leider habe ich zuwenig php Kentnisse um das (lt. Anleitung mit combine.php) einzubinden. Hier im Forum gibt es ja ein paar gute Programmierer…wäre das ein Plugin wert ?? Was ist eure Meinung… oder sind alle zufrieden mit der Ladezeit der ersten Seite ? Ich habe mit Optimierung der Bilder, JS kleiner machen und CSS zusammenfassen für meine Begriffe ein recht flottes Ergebnis erzielt. lg klaus[/quote] Hallo Klaus, in deinem Ticket habe ich gesehen das du deine css zusammengefasst hast. Was ist mit den updates von shopware in Zukunft? die werden doch bestimmt Probleme damit haben?

Hallo ! DAS wäre ja genau der Grund, warum es idealerweise automatisch eingerichtet sein sollte… Derzeit mache ich es manuell …ist mit ein paar Klick erledigt…sollte man aber erst machen, wenn der Shop fertig ist und kaum Änderungen geplant sind. Ein Update ist da natürlich etwas mehr Aufwand… lg klaus

Hallo Klaus, …das ist schon interessant. [quote]Was ist eure Meinung… oder sind alle zufrieden mit der Ladezeit der ersten Seite ?[/quote] Solange das Vorteile bringt wie das der Kunde auf schnell geladenen Seiten eher verweilt und das der Seitenspeed bei Google Pagerank eine Rolle spielt, sollte man das Thema wohl nicht vernachlässigen. Natürlich ist Seitenspeed, Optimierung, Yslow und Co nicht die Lösung aller Probleme, aber ein wichtiger Baustein im Ganzen ist es sehr wohl. Ist natürlich auch immer so eine Sache - hat man hat eine Seite / ein Template mit vielen und/oder großen Grafiken, oder/und man eine hohe Auslastung der Hardware, viele HTTP Requests usw. sollte auf jeden Fall optimiert werden. Auf bessere/teurere Hardware zurückgreifen sollte immer die letzte Maßnahme sein. 2-4 Sekunden Ladezeit sollen z.B. keinen Unterschied beim Google PR machen, aber gefühlte 2-4 Sekunden für einen Besucher schon… Ich finde grade Beschleunigungsmaßnahmen sehr interessant, die auch ohne einen Cache funktionieren (der dann i.d.R. erst bei dem 2.ten Aufruf greift). Das ist das Beste für Erstbesucher, die man ja gerne binden und zum Kunden machen möchte. [quote]Ich habe mit Optimierung der Bilder, JS kleiner machen und CSS zusammenfassen für meine Begriffe ein recht flottes Ergebnis erzielt.[/quote] YSlow=81, da bin ich auch grade :sunglasses: …wenn man bedenkt, das man irgendwo bei ca. 6X-70 gestartet ist… :quite: …und das ein empfohlener Wert von 90 kursiert… :wtf: bleibt noch was zu tun. :slight_smile: Ein weiterer interessanter Test ist hier zu finden, da man unter Anderem eine Ladegeschwindigkeit etwas simulieren kann (z.B. DSL 1500) viele von uns haben ja oft einen sehr schnellen Zugang, was man aber nicht von jedem Kunden erwarten kann: http://www.webpagetest.org/ Sag mal was für einen Server / Hosting Tarif hast Du denn (die Antwortzeiten des Servers fließen aber bei YSlow zum Beispiel nicht mit ein, glaub ich)? Grüße rattatui

Hallo ! [quote]YSlow=81, da bin ich auch grade[/quote] Könnte mehr sein, wenn ich nicht den Google Translator laden würde… :slight_smile: [quote]Natürlich ist Seitenspeed, Optimierung, Yslow und Co nicht die Lösung aller Probleme, aber ein wichtiger Baustein im Ganzen ist es sehr wohl. [/quote] Genau…das ist ja der Punkt … Design, Funktion und Schnelligkeit unter einem Hut zu bringen… und irgendwo muß man ja mal anfangen… im Auslieferungszustand ist shopware halt hier noch nicht optimiert… diejenigen die mehr Artikel haben mit vielen Bildern merken es ja schon… also wäre primär auch eine Lösung für die Bilder zu finden …ich habe die mühsam mit RIOT optimiert …also per FTP runter und wieder rauf… gut 35% eingespart bei noch guter Optik !!! DAS sollte zB mit imagemagick idealerweise ONBOARD passieren. CONTAO hat zB im Backend eine Einstellfunktion wo ich die Bildkomprimierung von 10 - 100 einstellen kann. Das wäre auch für Shopware ideal…nicht jeder benötigt gute Bilder mit Qualität 90-100 …hängt ja auch vom Produkt ab ! Eben noch viel zu tun… [quote]Antwortzeiten des Servers[/quote] … was ist dir hier aufgefallen ?? lg klaus

[quote=„klausm“]Das wäre auch für Shopware ideal…nicht jeder benötigt gute Bilder mit Qualität 90-100 …hängt ja auch vom Produkt ab ![/quote] Die hauseigene Komprimierung von Shopware kannst du nur direkt in einer php Datei einstellen. Irgendwo gibt es eine Info dazu, ich finde diese nur gerade nicht :frowning: Ich glaube in er sArticle.php

[quote][quote]Antwortzeiten des Servers[/quote] … was ist dir hier aufgefallen ??[/quote] War nur insofern als Anmerkung gedacht, als das diese Größe wohl nicht beim YSlow-Test geprüft wird… Beim Webpagetest dagegen schon. [quote]…ich habe die mühsam mit RIOT optimiert …[/quote] Oh, kannte ich noch nicht - ich dachte Puny PNG wäre zurzeit das Beste (ist etwas besser als Smush.it) [quote][quote]klausm hat geschrieben:Das wäre auch für Shopware ideal…nicht jeder benötigt gute Bilder mit Qualität 90-100 …hängt ja auch vom Produkt ab ![/quote] Die hauseigene Komprimierung von Shopware kannst du nur direkt in einer php Datei einstellen. Irgendwo gibt es eine Info dazu, ich finde diese nur gerade nicht :frowning: Ich glaube in er sArticle.php[/quote] Ich glaube auch das war die sArticle.php Das Problem neben der Dateigröße ist, das die Qualität (evtl. unnötig) arg leidet. Entweder nimmt man als Upload-Vorlage ein .jpg ohne Kompression oder ein .png Bild, das dann z.B. mit der Komprimierung in der Shopware sArticle.php mit 90 (oder wie man will wenn man den Wert dort verändert, z.B. 99 oder 70 usw.) die daraus erzeugten .jpg Bilder schlechter aussehen als sie eigentlich müssten…* *Das liegt meiner Meinung nach daran, dass eine Komprimierungsoption nicht zur Verfügung steht - die kann man z.B. in Irfan View setzen (“disable chroma color subsampling (use 1x1 blocks)”). Dann sieht man, das die Ergebnisse entweder wie in Shopware oder eben besser aussehen - das sollte man in Zukunft anwählen können. Und diese von der sArticle.php erzeugten .jpg Bilder versucht man dann ggf. mit externen Tool ggf. in der Dateigröße weiter zu schrumpfen - und bei .jpg bedeutet das nebenbei ja erneute kompression und dadurch wieder Verlust an Bildqualität… Da gibt es (soweit ich weiss) wohl derzeit nur einen sehr umständlichen Weg um das zu verhindern und trotzdem .jpg Bilder zu verwenden. Oder man verwendet die ungleich Größeren .png Bilder bei bester Qualität… Aber auch hier muss man darauf achten, dass Shopware daraus standardmäßig 32Bit-png’s macht (wozu eigentlich?) auch wenn man z.B. 24Bit Bilder hochlädt (das kann man aber in der sArticle.php abstellen) - anschließend sollten diese Bilder trotzdem mit Puny PNG oder ähnlichen Programmen nochmals verkleinert werden.

Ich beiße mir gerade an combine die Zähne aus. Irgendwo habe ich einen Fehler. Ich finde diesen leider nicht. header.tpl im default angepasst. alle css dateien zusammengenommen {block name="frontend\_index\_header\_css\_screen"} <link rel="stylesheet" href="print.css,enrichments.css,plugins.css,colors.css,style.css,framework.css" type='"text/css" media="screen" /&gt; {/block}

.htaccess rewriterule erstellt um das combine.phph script einzubinden:

RewriteBase /
RewriteRule ^(.*\.css) /combine.php?type=css&amp;files=$1

combine.php im root mit folgenden Inhalt abgelegt:

[code]
<?php

$cache = true;
$cachedir = dirname( __FILE__ ) . ' dirname . determine the directory and we should use switch case realpath break default: header not implemented exit explode last modification date of files while each if substr forbidden strlen found max filemtime send etag hash md5 stripslashes return visit no modifications so do anything modified else first time or were supported compression method strstr used : check for buggy versions internet explorer preg_match msie floatval try cache to see combined already generated fopen text filesize fpassthru fclose get contents reset file_get_contents content-type compressed gzencode force_gzip force_deflate echo regular store fwrite leider wird nun keine css mehr geladen wer findet den fehler>

Test die header.tpl mal so: {extends file="templates/\_default/frontend/index/header.tpl"} {block name="frontend\_index\_header\_css\_screen"} <link rel="stylesheet" href="framework.css,style.css,colors.css,plugins.css,enrichments.css,print.css" type="text/css" media="screen">{/block} Du hattest bei type=" ein Apostroph dein :wink: Mir klappts soweit nachdem ich die Reihenfolge der CSS-Dateien geändert hatte :slight_smile:

http://testshop.ottscho.de/templates/gr … adient.css (status: 403) gradient.css kein Zugriff !!! lg klaus

Hey klausm, Daran liegt es nicht. Das Default sollte ja komplett geladen werden. Es liegt am image Pfad. Hier muss über die htaccess noch was angepasst werden.

Hi…mußt du nicht die gradient .css auch ins root legen… wird ja das wirksam: RewriteBase / RewriteRule ^(.\*\.css) /combine.php?type=css&files=$1 lg

Im Root liegt keine CSS. Die combine.php änder automatisch den Pfad in den Templateordner. Bin nicht mehr dazu gekommen. Solbad ich es angepasst habe, poste ich es.

mhh, ich komme nicht weiter. Nun werden versucht die Images aus der CSS direkt unter ROOT zu laden: http://testshop.ottscho.de/images/…. Diese liegen aber hier: http://testshop.ottscho.de/templates/_d … s/images…. Nun brauche ich eine htaccess Regel, welche dies macht! Problem, Artikelbilder liegen unter /images/artciles… Diese dürfen nicht umgeleitet werden. Hat jmd eine Idee?

Wem das PHP-Gebastel nicht ganz so liegt und das lieber mit seinem Apache regelt, dem kann ich wärmstens Apache Modul mod_pagespeed empfehlen. Läuft bei uns wie eine 1. Richtig konfiguriert kombiniert es nicht nur CSS Dateien.

Wo genau könnte man die Bilder in der sArticle.php ändern??

[quote=„artep“]Wo genau könnte man die Bilder in der sArticle.php ändern??[/quote] Hi Petra, Sorry, dass war doch die upload.php, siehe betr. Bildqualität / JPG Kompression dazu auch hier …wenn Du PNG Bilder verwenden willst, kannst Du hier durch „false“ anstelle „true“ einstellen, das 24bit PNGs von Shopware erzeugt werden, und nicht wie per Default 32Bit PNGs (mit Alphachannel) das allein bringt schon kleinere Bilddateien mit kürzerer Ladezeit bei gleicher Qualität. Zeile 45 und 76 (ich weiss aber nicht mehr ob du die nur die erste, nur die zweite oder beide Zeilen ändern musst) imagesavealpha($newImage, true); Ein Problem bleibt aber: 1. 100% Qualitäts-JPG als Upload-Vorlage -> keine gute JPG Qualität (doppeltes komprimieren + Chroma Subsampling) 2. PNG als Upload-Vorlage und Verwendung von PNGs im Shop -> 1A Bildqualität -> leider große Dateien. Zum Thema Chroma Subsampling gibt es hier eine gute Erklärung. Ich habe es mal ausprobiert -die Qualitätsunterschiede sind z.B. deutlich größer, umso höher der Hell/Dunkel Kontrast ist (extremster Fall: schwarzer Kreis/Linie auf weißem Hintergrund, Muster mit den Farben Schwarz und Weiß). Die JPG-Dateien sind zwar etwas größer, aber bei sehr guter Qualität. Idealfall wäre also: PNG als Upload-Vorlage und daraus erzeugte JPGs mit passender Chroma Subsampling-Unterstüzung im Algorithmus…

1 Like

Hi, danke, die Tipps haben mir geholfen! Bilder ist komprimiert und Shop läuft merklich etwas schneller! Immer einen Schritt weiter! :wink:

[quote=“tschersich”]Wem das PHP-Gebastel nicht ganz so liegt und das lieber mit seinem Apache regelt, dem kann ich wärmstens Apache Modul mod_pagespeed empfehlen. Läuft bei uns wie eine 1. Richtig konfiguriert kombiniert es nicht nur CSS Dateien.[/quote] Hi tschersich :slight_smile: …das ist eine gute Sache -aber leider braucht man dazu Root-Rechte. In der Regel scheidet also Jeder mit Managed Hosting / Managed Server wohl leider aus :shock: …das Thema ist zu interessant als das es untergeht - gibt es zu diesem Problem villeicht doch eine Lösung? Hat vielleicht auch Shopware noch eine Idee dazu? [quote=“ottscho”][quote=“Sebastian Klöpper”]Test die header.tpl mal so: {extends file="templates/\_default/frontend/index/header.tpl"} {block name="frontend\_index\_header\_css\_screen"} <link rel="stylesheet" href="framework.css,style.css,colors.css,plugins.css,enrichments.css,print.css" type="text/css" media="screen">{/block} Du hattest bei type=" ein Apostroph dein :wink: Mir klappts soweit nachdem ich die Reihenfolge der CSS-Dateien geändert hatte :-)[/quote] Danke, stimmt :wink: Das CSS Einbinden geht nun. Aber jetzt passt was mit den Bildern nicht mehr. Der relative Pfad :frowning: Müsste ich nun alle Standard CSS Dateien abändern? [/quote] Grüße, rattatui