Shop - Ladezeit beschleunigen - TIP - CDN

Hallo ! Ich habe mal testweise bei meinem Shop mittels Subdomain ein CDN eingerichtet. (Infos dazu: http://developer.yahoo.com/performance/rules.html#cdn ) Muss sagen, DAS bringt etwas. Wer also die Möglichkeit hat auf seinem Server einen Unterordner einzurichten der via Subdomain erreichbar ist, kann ich das nur empfehlen… Ich würde es toll finden, wenn das Shopwareteam die Option CDN Unterstützung einbauen würde, dann ist das ganze auch updatesicher ! LINK VOR CDN Umstellung: http://www.webpagetest.org/result/11032 … 1/details/ LINK NACH CDN Umstellung http://www.webpagetest.org/result/11032 … 1/details/ Da der Browser ja nun von 2 Domains gleichzeitig ladet, deutlich spürbares besseres Ergebnis… lg klaus

[quote=„klausm“]Da der Browser ja nun von 2 Domains gleichzeitig ladet, deutlich spürbares besseres Ergebnis…[/quote] Was hast Du da wie organisiert???

Hallo ! Mal global gesagt: Kopie von Ordner /templates auf die Subdomain legen und die header.tpl anpassen (Link des *.js und *. css Aufrufes im Header). Zusätzlich noch Anpassungen an der .htaccess von der Subdomain um das gzip zu gewährleisten. (das war einer der schwierigsten Brocken, da ja Shopware intern über /engine/backend/php/sCacheTemplate.php das gzip regelt. Aber habe ich mit mod_deflate.c gelöst. Derzeit rufe ich nur bestimmte css und js auf, weil ich noch teste bei welcher Zusammenstellung die beste Ladezeit erfolgt. Wenn ich das beste Ergebnis herausgefunden habe, poste ich das hier… lg klaus

[quote=“klausm”]Hallo ! Mal global gesagt: Kopie von Ordner /templates auf die Subdomain legen und die header.tpl anpassen (Link des *.js und *. css Aufrufes im Header). Zusätzlich noch Anpassungen an der .htaccess von der Subdomain um das gzip zu gewährleisten. (das war einer der schwierigsten Brocken, da ja Shopware intern über /engine/backend/php/sCacheTemplate.php das gzip regelt. Aber habe ich mit mod_deflate.c gelöst. Derzeit rufe ich nur bestimmte css und js auf, weil ich noch teste bei welcher Zusammenstellung die beste Ladezeit erfolgt. Wenn ich das beste Ergebnis herausgefunden habe, poste ich das hier… lg klaus[/quote] Ich weiß nicht, die paar CSS- und JS-Dateien können doch nicht so einen großen Unterschied machen, vor allem, wenn sie gezipped sind… Bilder wäre m.E. eher ein Kandidat für eine 2. Domain. Dann könnten HTML, JS und CSS von der einen, die Bilder von der anderen Domain geladen werden. Ich meine, Stefan Hamann hätte schon mal was gepostet, um Bilder von einer alternativen URL zu laden!??

Hallo ! NATÜRLICH …mit den Bildern wäre das optimal !!! Aber das ist derzeit ohne massive Eingriffe nicht möglich, da die ja alle beim Cache leeren neu erstellt werden. IDEALFALL ist 1 Hauptdomain, 2 Subdomain ist aber dann schon ziemlich komplex. Habe jetzt mit 2 Subdomain getestet: VORHER: Start des Seitenrenderns (erster Bildaufbau) bei 4,5 Sekunden nach 8 Sekunden erst fertig NACHHER: Start des Seitenrenderns (erster Bildaufbau) bei 2,5 Sekunden nach 5 Sekunden fertig Mann sieht eigentlich sehr schön (grüne senkrechte Linie !), dass das rendern der Seite deutlich früher sttfindet. Halbe Zeit !!! Der Browser kann ja maximal 2 Verbindungen gleichzeitg zu einer Domain aufbauen. Die Reihenfolge ist ja zuerst die HTML Seite, dann CSS, dann JS, dann den Rest… DAHER die CSS und JS sind enorm wichtig, weil bevor die nicht vollständig im Browser sind, gibt es für den user nichts zu sehen… und wenn der user um die halbe zeit früher etwas sieht…hat er das gefühl der Schnelligkeit einer Webseite ! Das rendern der Seite beginnt erst wenn CSS und JS vollständig geladen sind… Wenn ich also von 3 Domain lade verkürzt sich mit 6 gleichzeitigen Verbindungen die Ladezeit ! @ avenger…und wenn wir jetzt noch die Bilder auch so laden…ein Traum wäre das an Performance !!! CPU Last übrigens deutlich geringer…siehe orange Linie …auch ein Vorteil bei vielen verbindungen gleichzeitig… hier noch ein Link zum Ergebnis: http://www.webpagetest.org/result/11032 … 1/details/ Hoffe ich kann shopwareteam damit überzeugen, dass CDN eingebaut wird… lg klaus

Moin, NATÜRLICH …mit den Bildern wäre das optimal !!! Aber das ist derzeit ohne massive Eingriffe nicht möglich, da die ja alle beim Cache leeren neu erstellt werd Habe ich irgendwas verpasst? Die Bilder werden NICHT neu erzeugt, wenn du den Shopcache leerst!! Das ist eigentlich total easy einzubauen. Du musst nur in deiner .htaccess eine RewriteRule integrieren. Also Beispiel: RewriteRule /images/articles/(.*) http://subdomain.server.de/images/articles/$1 Dann werden alle Requests, die auf das Verzeichnis mit den Artikelbildern verweisen, automatisch von einem anderen / externen Server geholt. Je nach Konfiguration müsstest du das lokale Bilder - Verzeichnis und das Remote-Verzeichnis noch per rsync synchronisieren oder aber das Upload-Script von Shopware so anpassen, dass die Bilder z.B. direkt per FTP auf einem anderen Server hochgeladen werden. (< 10 Zeilen Code) Für die CDN-Geschichte als solches mach doch bitte mal ein Ticket im Trac auf - ich halte das wohl für interessant.

OK…Danke… Ich dachte immer, dass beim Leeren von “Artikel und Kategorien” auch die Bilder alle neu generiert werden… d.h. wenn man Bilder auswechselt bei den Artikeln bleiben die alten Bilder erhalten ? Werden die dann erst durch das Bereinigungsscript gelöscht ? Konnte das mangels Bildernamen nie nachvollziehen… jetzt wo ich mir das Datum der Bilder ansehe ist es mir auch klar lg klaus

Diese Lösung aber bitte nur produktiv einsetzen, wenn für die Domain(s) ein Wildcart-Zertifikat eingesetzt wird. Ansonsten werden Browser beim Checkout und Wechsel auf https:// eine Sicherheitswarnung anzeigen und das wird massiv Kunden vom Kauf abhalten. Alternativ: Ihr benutzt gar kein Zertifikat und damit nur http:// , wovon ich aber abraten würde.

[quote=“klausm”]Hallo ! (…) Der Browser kann ja maximal 2 Verbindungen gleichzeitg zu einer Domain aufbauen. (…) lg klaus[/quote] i.d.R. sind es bei modernen Browsern je nach Typ zwischen 4 und 8 gleichzeitigen Requests pro Subdomain, aber auch das kann mächtig aufhalten. Der IE6 kann bei HTTP 1.1 nur zwei gleichzeitige Verbindungen, bei HTTP 1.0 vier. Das Auslagern der CSS und JS ist nur bei der ersten geladenen Seite effektiv, wenn man Server-Caching (siehe Tutorial Caching Zeiten) angeschaltet hat. Danach bedient sich der Browser aus dem eigenen Cache, bis die Cache-Zeit abgelaufen ist (expires:…) und somit fallen diese Dateien nicht mehr ins Gewicht. Effektiv ist das mit den Subdomains tatsächlich bei den Produktbildern, wenn man diese auf mehrere Subdomains verteilen kann, denn diese sind fast die einzigen Seitenelemente, die auf jeder Seite anders sind und damit bei einem Besuch nur selten mehrfach aufgerufen werden, um aus dem Cache bedient werden zu können.

[quote]i.d.R. sind es bei modernen Browsern je nach Typ zwischen 4 und 8 gleichzeitigen Requests pro Subdomain, aber auch das kann mächtig aufhalten. Der IE6 kann bei HTTP 1.1 nur zwei gleichzeitige Verbindungen, bei HTTP 1.0 vier. [/quote] Danke…wieder was dazugelernt… :thumbup: lg klaus

[quote=“Stefan Hamann”]Moin, … Das ist eigentlich total easy einzubauen. Du musst nur in deiner .htaccess eine RewriteRule integrieren. Also Beispiel: RewriteRule /images/articles/(.*) http://subdomain.server.de/images/articles/$1 Dann werden alle Requests, die auf das Verzeichnis mit den Artikelbildern verweisen, automatisch von einem anderen / externen Server geholt. [/quote] Hallo ! Habe das getestet, klappt auch…allerdings kommt dann für diese Bilder 302 Found zurück ! Hat das nicht negative Auswirkungen auf das Cache-Verhalten ? lg klaus

[quote=“tschersich”][quote=“klausm”]Hallo ! (…) Der Browser kann ja maximal 2 Verbindungen gleichzeitg zu einer Domain aufbauen. (…) lg klaus[/quote] i.d.R. sind es bei modernen Browsern je nach Typ zwischen 4 und 8 gleichzeitigen Requests pro Subdomain, aber auch das kann mächtig aufhalten. Der IE6 kann bei HTTP 1.1 nur zwei gleichzeitige Verbindungen, bei HTTP 1.0 vier. Das Auslagern der CSS und JS ist nur bei der ersten geladenen Seite effektiv, wenn man Server-Caching (siehe Tutorial Caching Zeiten) angeschaltet hat. Danach bedient sich der Browser aus dem eigenen Cache, bis die Cache-Zeit abgelaufen ist (expires:…) und somit fallen diese Dateien nicht mehr ins Gewicht. Effektiv ist das mit den Subdomains tatsächlich bei den Produktbildern, wenn man diese auf mehrere Subdomains verteilen kann, denn diese sind fast die einzigen Seitenelemente, die auf jeder Seite anders sind und damit bei einem Besuch nur selten mehrfach aufgerufen werden, um aus dem Cache bedient werden zu können.[/quote] Waren es beim IE6 und 7 nur zwei parallele Verbindungen, sind es bei FF 3.6 sechs Verbindungen und bei Opera und Safari acht Verbindungen. Grundsätzlich ist der CDN-Betrieb wunderbar. Aus Erfahrung ist es (zwar in diesem Beispiel nicht geannt, dennoch wissenswert) nützlich, wenn die Daten nicht Random von einem Space geladen werden. Dies verzögert die Auslieferung eher bei jedem Aufruf, als das es etwas beschleunigt (Optimiertes CDN gegen Random CDN; unsecured level). Es macht Sinn, JS, CSS sowie eben innerhalb jeder Größe verschiedene Bilder via CDN zu laden. Doch genau da liegt eben der Haken. Die Bilder sollten immer vom gleichen CDN kommen, was derzeit eben nicht einfach mit Shopware lösbar ist. Okay, das außen vor gelassen, ist es definitiv sinnvoll die JS-Dateien, die CSS und andere statische Inhalte auf verschiedenen Subs zu verteilen. Jedoch sollten Dateien, die zum Rank bzw. vom Rank der Hauptdomain etwas erben sollen, unbedingt mit auf der Hauptdomain liegen. Bei JS- oder CSS-Dateien ist dies bekanntlich irrelevant. Bei den wichtigen und eben großen Produktbildern ist es schon bedeutender. Doch davon werden auf einer Detailsseite bekanntlich wenige gleichzeutig geladen. Dass die Dateien nach einmaligem Aufruf sowieso im Zwischenspeicher liegen ist natürlich richtig, zumindest solange es um eine unverschlüsselte Verbindung geht. Eben so ist es wictig, dass alle zum CDN gehörenden Subs ebenfalls über eine bestehende Verschlüsselung verfügen. Wird ansonsten auf einer eigentlich verschlüsselten Verbindung ein unverschlüsselter Inhalt geladen gibt’s nette Meldungen und für den Benutzer ist die sichere Verbindung augenscheinlich für die Katz. Über die Google App Engine lässt sich dazu ebenfalls ein CDN aufbauen (auch secured), wenn eben das Budget da ist - oder es sich rechnet lieber dort zu spiegeln, anstatt bzw. über einen eigenen Balancer etc. Muss man für sich selbst berechnen, vor allem auch was die wirklich Belastung des Servers angeht. (Kleiner Tipp noch: Für die Google App-Engine wird eine Sub benötigt, via CNAME mag man nicht mehr.) CDN definitiv sinnvoll, zuerst jedoch erst einmal Minification und den Server optimieren. Aus eigener Erfahrung bringt’s da auch nicht unbedingt der PageSpeed-Mod für den Apachen, neben ACP. Spätestens im Backend funktioniert der Mod mit Standard-Konfig leider nur noch bedingt, im Frontend bringt er nicht immer Erfolg - den sollte man jedoch ebenfalls erst optimieren bzw. nutzen, wenn der Rest schon optimiert wurde. EDIT: Ein Eingriff in Shopware mit dem bspw. auch CDN innerhalb einer Bildergröße möglich wäre, die jedoch auf jedem Sub nur einzeln liegen und nicht bspw. via rsync auf allen Subs und Random mit jedem Aufruf ausgegeben werden, wäre, dass man die Bilder beim Upload in explizite Unterordner oÄ. aufteilt, die man dann je Sub einzeln verteilt. Alternativ über einen Index der Session-Abhängig und nicht Request-Abhängig ist. Hauptbilder (Max-Size) sollten dennoch auf der Stammadresse (Folder, nicht Sub) liegen - aus SEO-Sicht. Aber aus SEO-Sicht wäre der Bildname durch Upload im Backend (nicht WaWi) noch wichtiger. Viele Grüße

Um das Thema mal noch auszuweiten. Ich hatte mich intensiver mit den Büchern aus dem O´Reilly Verlag dazu beschäftigt - “Even Faster Websites” von Steve Sounderslohnt sich definitiv. Sehr viel Ladezeit geht wirklich im Frontend verloren (wir haben bislang noch nicht von Datenbank-Optimierung geredet), allerdings ist CDN nur ein(!) mögliches Mittel. Die Frage stellt sich für mich hier nach Aufwand und Nutzen, und ob nicht andere Maßnahmen erstmal einfacher (-> zeitsparender -> kostengünstiger) umzusetzen sind. Ich denke, dass JS im ersten Schritt noch nicht mal ausgelagert werden muss, eine erste Maßnahme wäre alles JS vor den schließenden body-Tag zu verlagern. Javascript ist blockierender Natur - d.h. es verhindert weitere Downloads wie CSS und von Bildern. Worst case soll laut Tests dann sein, wenn nach einem Inline-JS ein CSS-File eingebunden ist. Shopware ist hier im vergleich zu früheren Versionen besser aufgestellt, Problem ist aber, dass es keine Inline-JS-Methodenaufrufe bzw. etwa Library-Initialisierungen im Quellcode geben darf, bevor die Library (in dem Fall jQuery) eingebunden wurde. Nach dem Paradigma Unobtrusive JS sollte das sowieso umgesetzt werden, die Praxis sieht zumeist anders aus. Im Idealfall ist alles JS im Fuß zu finden und wird asynchron eingebunden wie Ajax. Es gibt dafür auch Tools wie nbl.js. Minifizierung ist wichtig und der “defer” Tag kann auch helfen. Zur Analyse helfen Tools wie Ylow und GooglePageSpeed, wobei auch dort nur bestimmte Fragenkataloge abgearbeitet werden - Sounders listet diese alle auf und macht Tests dazu. Dazu das Problem - mfpro´s Hinweis geht in die Richtung - dass Browser Elemente in versch. Reihenfolge laden. Ziel ist alle Anfragen möglichst non-blocking zu bekommen. Dazu kommt klassisches Tuning im Frontend durch Sprites etc: also das Grundziel die Anfragen an den Server zu minimieren. Insofern sehe ich die Sache mit den Artikelbildern in einem anderen Verzeichnis auch skeptisch - dann werden dort alle Anfragen für Bilder hingeleitet, auf dem gleichen Server. Übersehe ich da was? Sinn würde es ja machen, wenn die Bilder auf verschiedenen Servern liegen würden - also CDN.

Also ich fuer meinen Teil meine verschiedene Subs/Server bzgl. der Folder. Async. bzw. paralleles Laden der JS ist def. interessant. Aber bspw. (nur um mal einen zu nennen) auch head.js o.Ae. Bzgl. der SQL Optimierung kann ich nur zustimmen, jedoch ist das wahrlich noch etwas mehr vom Server abhaengig wie CDNs einzurichten (rein im Bezug auf die parallele Performance auf einer physk. Maschine). Wobei es bei den meisten (und davon betreue ich auch einige) CE-Shops auf virtuelle Hosts hinauslaeuft die oftmals neben im Idealfall nur 7 weiteren Kunden auch jeweils Plesk laufen haben. Ich bin derzeit dabei auch ein VPS mit „garantierten CPUs und RAM“ am optmieren, ein CDN waere hier kostenguenstig (selbst ueber App-Engine) schon super. Nunja, wir werden sehen. Es macht schliesslich wenig Sinn den Core dahingehend umzustricken, wenn doch desoeferten Updates im Grossformat erscheinen. Mal sehen was Stefan und sene Truppe draus macht. Viele Gruesse, Andi PS: Naechstes Mal doch lieber wieder vom Rechner, anstatt vom iPad. Bekommt man ja 'n Krampf.

[quote=„mfpro“] PS: Naechstes Mal doch lieber wieder vom Rechner, anstatt vom iPad. Bekommt man ja 'n Krampf. ;)[/quote] Noch nicht herausgefunden wie man ein Umlaut macht, oder ist deine Schreibweise Absicht?

[quote=“klausm”]Hallo ! Habe das getestet, klappt auch…allerdings kommt dann für diese Bilder 302 Found zurück ! Hat das nicht negative Auswirkungen auf das Cache-Verhalten ? lg klaus[/quote] Ja, hat es und dazu kommt noch, dass dadurch die Anzahl der Requests an den Webserver steigt, was für den Kunden wieder Performance kostet. Die rewrite Rule müßte für internes Rewriting umgeschreiben werden. Wer kompletten Zugriff auf den Server hat und nur das mit den Subdomains nutzen will, ohne den Bildnamen zu verändern, kann auch anders ein bisschen tricksen, ohne überhaupt Dateien zu kopieren oder umzuleiten: Ab der DocumentRoot der Subdomain erst den Pfad bis zu den Bildern mit mkdir nachbauen und dann beim images Verzeichnis einen Symbolik Link ( ln -s ) rüber zum “echten” images Verzeichnis der Hauptdomain setzen. Das klappt äquivalent natürlich auch nur mit den CSS oder JS Dateien. Dabei kannn man dabei sogar überlegen, ob man für die Subdomain-Bilder einen etwas schlankeren Webserver wie lightppd einsetzt, den man ohne PHP-Einbindung usw. konfiguriert.

[quote=“ottscho”][quote=“mfpro”] PS: Naechstes Mal doch lieber wieder vom Rechner, anstatt vom iPad. Bekommt man ja 'n Krampf. ;)[/quote] Noch nicht herausgefunden wie man ein Umlaut macht, oder ist deine Schreibweise Absicht? ;)[/quote] Dauert nur noch länger.

Hey, ich versuche nun auch mal die Images über die Subdomain zu laden. Wenn ich die Site nun über Firebug analysiere, bleibt aber die Domain von der Hauptdomain stehen.(Ist ja soweit korrekt, da die URL der Bilder in der DB ja nicht geändert wird, sondern erst bei aufruf über die htaccess). Gibt es ein Messtool, welches mir dann auch die Zugriffe über die Subdomain anzeigt? Oder habe ich hier einen Denkfehler? Der htaccess Eintrag sieht so wie Stefan gepostet hat aus.

Hallo, ich möchte nur noch einmal auf eine sehr einfache Lösung für ein CDN zurückkommen, da ich die letzten Tage eine Benachrichtigung zu diesem Thema bekam… kann sowohl für eigene Subdomains (dann natürlich nur mit Wildcard-SSL-Zertifikat) wie auch (in meinem Fall) für Amazon S3 bzw. Cloudfront genutzt werden. Der Vorteil dabei ist, dass Daten sowohl via 80 als auch 443 abgerufen werden können. Somit ist vor allem ein weiterhin gültiges Zertifikat im Warenkorb etc. sichergestellt… Wie dem auch sei… für Artikelbilder wäre in der .htaccess eine sehr einfache Lösung:
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} images/articles/
RewriteRule ^(.*)$ http://DEINBUCKET.cloudfront.net/$1 [R,L]

RewriteCond %{SERVER_PORT} 443
RewriteCond %{REQUEST_URI} images/articles/
RewriteRule ^(.*)$ https://DEINBUCKET.cloudfront.net/$1 [R,L]
ABER Speed bringt das nicht. Weiterleitungen lassen dennoch erst einmal die URL im Quelltext auf dem alten Ort, erst wenn der Browser nun bei den Bildern angekommen ist merkt er, dass die Bilder auf “einmal anderen Space” liegen. Solange sind die Adressen auch geblockt bis sie dran sind. Es muss also direkt die Quelle eine andere Adresse haben … so klappt’s eher mit dem Traffic auslagern. Viele Grüße

Dann muss in der sArticles.php der Pfad geändert werden. Ca. Line 3700 Das bringt auf jede Fall etwas. if (preg\_match("/443/",$\_SERVER['SERVER\_PORT'])){ $this-\>sSYSTEM-\>sPathArticleImg = "https://static.subdomain.de/".$this-\>sSYSTEM-\>sCONFIG["sARTICLEIMAGES"]."/"; }else { $this-\>sSYSTEM-\>sPathArticleImg = "http://static.subdomain.de/".$this-\>sSYSTEM-\>sCONFIG["sARTICLEIMAGES"]."/"; }