klausmklausm MemberComments: 314 Received thanks: 52 Member since: November 2010 edited November 2015
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
«1

Comments

  • avengeravenger MemberComments: 916 Received thanks: 99 Member since: September 2010
    klausm wrote:
    Da der Browser ja nun von 2 Domains gleichzeitig ladet, deutlich spürbares besseres Ergebnis....
    Was hast Du da wie organisiert???
  • klausmklausm MemberComments: 314 Received thanks: 52 Member since: November 2010
    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
  • avengeravenger MemberComments: 916 Received thanks: 99 Member since: September 2010
    klausm wrote:
    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
    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!??
  • klausmklausm MemberComments: 314 Received thanks: 52 Member since: November 2010
    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

    waterfall_vorher.png

    NACHHER: Start des Seitenrenderns (erster Bildaufbau) bei 2,5 Sekunden nach 5 Sekunden fertig

    waterfall_nachher1.png


    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
    Thanked by 1testitio
  • Stefan HamannStefan Hamann AdministratorsComments: 2473 Received thanks: 443 Member since: June 2010
    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.
  • klausmklausm MemberComments: 314 Received thanks: 52 Member since: November 2010
    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
  • tschersichtschersich MemberComments: 681 Received thanks: 86 Member since: October 2010
    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.
  • tschersichtschersich MemberComments: 681 Received thanks: 86 Member since: October 2010
    klausm wrote:
    Hallo !
    (...)
    Der Browser kann ja maximal 2 Verbindungen gleichzeitg zu einer Domain aufbauen.
    (...)
    lg klaus
    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.
  • klausmklausm MemberComments: 314 Received thanks: 52 Member since: November 2010
    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.
    Danke...wieder was dazugelernt.... :thumbup:


    lg klaus
  • klausmklausm MemberComments: 314 Received thanks: 52 Member since: November 2010
    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.
    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
  • mfpromfpro MemberComments: 59 Received thanks: 7 Member since: December 2010
    tschersich wrote:
    klausm wrote:
    Hallo !
    (...)
    Der Browser kann ja maximal 2 Verbindungen gleichzeitg zu einer Domain aufbauen.
    (...)
    lg klaus
    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.
    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
  • ShopFreelancerShopFreelancer MemberComments: 39 Received thanks: 5 Member since: January 2011
    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.
  • mfpromfpro MemberComments: 59 Received thanks: 7 Member since: December 2010
    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. ;)
  • ottschoottscho MemberComments: 2595 Received thanks: 260 Member since: October 2010
    mfpro wrote:
    PS: Naechstes Mal doch lieber wieder vom Rechner, anstatt vom iPad. Bekommt man ja 'n Krampf. ;)
    Noch nicht herausgefunden wie man ein Umlaut macht, oder ist deine Schreibweise Absicht? ;)
  • tschersichtschersich MemberComments: 681 Received thanks: 86 Member since: October 2010
    klausm wrote:
    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
    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.
  • mfpromfpro MemberComments: 59 Received thanks: 7 Member since: December 2010
    ottscho wrote:
    mfpro wrote:
    PS: Naechstes Mal doch lieber wieder vom Rechner, anstatt vom iPad. Bekommt man ja 'n Krampf. ;)
    Noch nicht herausgefunden wie man ein Umlaut macht, oder ist deine Schreibweise Absicht? ;)
    Dauert nur noch länger. ;)
  • ottschoottscho MemberComments: 2595 Received thanks: 260 Member since: October 2010
    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.
  • mfpromfpro MemberComments: 59 Received thanks: 7 Member since: December 2010
    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:

    <IfModule mod_rewrite.c>
    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]
    </IfModule>


    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
  • ottschoottscho MemberComments: 2595 Received thanks: 260 Member since: October 2010
    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"]."/";
    		}
    
  • mfpromfpro MemberComments: 59 Received thanks: 7 Member since: December 2010
    Wenn du jetzt noch für die Head- & Template-Elements etwas auf Lager hast, ist das Thema damit abgeschlossen und jeder kann sich bedienen wie er will. ;)

    Viele Grüße
  • ottschoottscho MemberComments: 2595 Received thanks: 260 edited June 2011 Member since: October 2010
    mfpro wrote:
    Wenn du jetzt noch für die Head- & Template-Elements etwas auf Lager hast, ist das Thema damit abgeschlossen und jeder kann sich bedienen wie er will. ;)

    Viele Grüße
    Na klar ;)
    {block name="frontend_index_header_css_screen"}
    {if $smarty.server.SERVER_PORT == "443"}
    	<link type="text/css" media="all" rel="stylesheet" href="https://static1.domain.de/templates/_default/frontend/_resources/styles/framework.css"; />
    	<link type="text/css" media="screen, projection" rel="stylesheet" href="https://static1.domain.de/templates/_default/frontend/_resources/styles/style.css"; />
    	<link type="text/css" media="screen, projection" rel="stylesheet" href="https://static1.domain.de/templates/_default/frontend/_resources/styles/colors.css"; />
    	<link type="text/css" media="screen, projection" rel="stylesheet" href="https://static1.domain.de/templates/_default/frontend/_resources/styles/plugins.css"; />
    	<link type="text/css" media="screen, projection" rel="stylesheet" href="https://static1.domain.de/templates/_default/frontend/_resources/styles/enrichments.css"; />
    	<link type="text/css" media="screen, projection" rel="stylesheet" href="https://static1.domain.de/templates/MyTemp/frontend/_resources/styles/MyTemp.css"; />
    	<link type="text/css" media="screen, projection" rel="stylesheet" href="https://static1.domain.de/templates/MyTemp/frontend/_resources/styles/nivo-slider.css"; />	
    {else}
    	<link type="text/css" media="all" rel="stylesheet" href="http://static1.domain.de/templates/_default/frontend/_resources/styles/framework.css"; />
    	<link type="text/css" media="screen, projection" rel="stylesheet" href="http://static1.domain.de/templates/_default/frontend/_resources/styles/style.css"; />
    	<link type="text/css" media="screen, projection" rel="stylesheet" href="http://static1.domain.de/templates/_default/frontend/_resources/styles/colors.css"; />
    	<link type="text/css" media="screen, projection" rel="stylesheet" href="http://static1.domain.de/templates/_default/frontend/_resources/styles/plugins.css"; />
    	<link type="text/css" media="screen, projection" rel="stylesheet" href="http://static1.domain.de/templates/_default/frontend/_resources/styles/enrichments.css"; />
    	<link type="text/css" media="screen, projection" rel="stylesheet" href="http://static1.domain.de/templates/MyTemp/frontend/_resources/styles/MyTemp.css"; />
    	<link type="text/css" media="screen, projection" rel="stylesheet" href="http://static1.domain.de/templates/MyTemp/frontend/_resources/styles/nivo-slider.css"; />	
    {/if}
    {/block}
    
  • mfpromfpro MemberComments: 59 Received thanks: 7 Member since: December 2010
    Da ist am Ende eine Doppelklammer zu viel drin oder? :)
    PS: Und die Tmp beim eigenen Einsatz natürlich anpassen... Änderungen sind für die header.tpl im index.

    Viele Grüße
  • ottschoottscho MemberComments: 2595 Received thanks: 260 Member since: October 2010
    mfpro wrote:
    Da ist am Ende eine Doppelklammer zu viel drin oder? :)
    PS: Und die Tmp beim eigenen Einsatz natürlich anpassen... Änderungen sind für die header.tpl im index.

    Viele Grüße

    Ja, die Klammer hat sich eingeschlichen. Habe diese aber schon entfernt ;)
  • mfpromfpro MemberComments: 59 Received thanks: 7 Member since: December 2010
    Nur der Vollständigkeit halber... für die JS-Files (ist auf Minified umgeschrieben):
    {block name="frontend_index_header_javascript"}
    {if $smarty.server.SERVER_PORT == "443"}
       <script type="text/javascript" src="https://static1.domain.de/templates/_default/frontend/_resources/javascript/jquery-1.4.2.min.js"></script>;
    	<script type="text/javascript">
    	//<![CDATA[
    	{block name="frontend_index_header_javascript_inline"}
    		var timeNow = {time() nocache};
    		jQuery.controller =  {ldelim}
    			'ajax_cart': '{url controller="checkout" appendSession}',
    			'ajax_search': '{url controller="ajax_search" fullPath=false}',
    			'ajax_login': '{url controller="account" action="ajax_login"}',
    			'register': '{url controller="register" appendSession}',
    			'checkout': '{url controller="checkout" appendSession}',
    			'ajax_logout': '{url controller="account" action="ajax_logout" appendSession}',
    			'ajax_validate': '{url controller="register" appendSession}'
    		{rdelim};
    	{/block}
    	//]]>
    	</script>
    	{block name="frontend_index_header_javascript_jquery"}
    	<script type="text/javascript" src="https://static1.domain.de/templates/_default/frontend/_resources/javascript/jquery.shopware.js"></script>;
    	{/block}
    {else}
       <script type="text/javascript" src="http://static1.domain.de/templates/_default/frontend/_resources/javascript/jquery-1.4.2.min.js"></script>;
    	<script type="text/javascript">
    	//<![CDATA[
    	{block name="frontend_index_header_javascript_inline"}
    		var timeNow = {time() nocache};
    		jQuery.controller =  {ldelim}
    			'ajax_cart': '{url controller="checkout" appendSession}',
    			'ajax_search': '{url controller="ajax_search" fullPath=false}',
    			'ajax_login': '{url controller="account" action="ajax_login"}',
    			'register': '{url controller="register" appendSession}',
    			'checkout': '{url controller="checkout" appendSession}',
    			'ajax_logout': '{url controller="account" action="ajax_logout" appendSession}',
    			'ajax_validate': '{url controller="register" appendSession}'
    		{rdelim};
    	{/block}
    	//]]>
    	</script>
    	{block name="frontend_index_header_javascript_jquery"}
    	<script type="text/javascript" src="http://static1.domain.de/templates/_default/frontend/_resources/javascript/jquery.shopware.js"></script>;
    	{/block}
    {/if}
    

    Beim Upload der Styles übrigens nicht die Bilder vergessen, die in den Styles verlinkt sind. Im Idealfall diese Verlinkungen ggf. auch anpassen.


    Viele Grüße
  • ottschoottscho MemberComments: 2595 Received thanks: 260 Member since: October 2010
    mfpro wrote:
    Beim Upload der Styles übrigens nicht die Bilder vergessen, die in den Styles verlinkt sind. Im Idealfall diese Verlinkungen ggf. auch anpassen.
    Die Bildpfade im CSS sollten relative Pfadangaben sein, dann werden die automatisch über die Subdomain geladen, über welche auch die CSS Datei eingebunden wird ;)
  • mfpromfpro MemberComments: 59 Received thanks: 7 Member since: December 2010
    Ich meinte gerade auf einen anderen Static. ;)
  • Sany-MediaSany-Media MemberComments: 36 Received thanks: 2 Member since: May 2011
    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.
    Kleine Anmerkung, RSYNC funktioniert nicht mit FTP.
    Die bessere Lösung curlftpfs, hiermit lassen sich Verzeichnisse auf entfernten Server ins Dateisystem einbinden.
  • btradingbtrading MemberComments: 1 Received thanks: 0 Member since: June 2015
    Hallo zusammen,

    sind die hier erwähnten Optimierungen auch für Shopware 5 geeignet, oder mache ich mir meine Shopware Installation kaputt, wenn ich die erwähnten Schritte für Shopware 4 1:1 auf SW5 anwende?

    Danke im Voraus!
  • ShopwareianerShopwareianer MemberComments: 3569 Received thanks: 631 Member since: November 2013
    Die genannten Methoden hier haben überhaupt garnichts mit einem CDN zu tun ..
    Wenn du aber einen CDN Anbieter hast, einfach entsprechend die URL umschreiben.

    Die gängigen Anbieter bieten eine Push Funktion, also musst du hier nur die entsprechenden URLs ändern.

    Wenn du allerdings nicht massig Besucher aus dem Ausland hast, benötigst du auch kein CDN.
  • kadiskadis MemberComments: 251 Received thanks: 12 Member since: June 2012
    Hy,

    ich habe dazu mal eine Frage.

    Macht es etwas Speedtechnisch aus, wenn ich die Bilder von einer Subdomain lade, die auf /media/ zeigt? Gibt es eine Konfigmöglichkeit dafür in SW5.1?

    Bringt CDN etwas, wenn man zu 95% Inlandskunden hat. (Server steht im selben Land).

    Beste Grüße
Sign In or Register to comment.