Tag Archives: osC optimieren

osCommerce 2.2 schneller machen

Mein 7 Jahre alter osCommerce 2.2RC wurde von mir damals (als ich noch nicht wirklich Ahnung von Ladezeiten und so esoterischem Zeugs hatte) mit zig Modulen verschlimmbessert.

Aber er läuft und läuft und läuft… Und er läuft schneller als jeder Magento, den ich bis heute aufgesetzt habe.

Da sowieso ein Facelifting anstand (ich hatte wirklich 7 Jahre nichts am Shop geändert, ausser gelegentlich Artikel oder Preis geändert), wollte ich mich auch um das Thema Ladezeiten und Geschwindigkeit kümmern.

Nicht nur google, sondern auch Besucher mögen schnelle Websites.

Verwendete Werkzeuge: Firefox-Browser, die Add-ons WebDeveloper und Firebug für FF.

Um das Add-on von Webdeveloper zu benutzen klicke einfach mit rechtem Mausklick in die zu untersuchende Webseite und wähle “Element untersuchen” aus. Dort klicke auf den Reiter “Netzwerkanalyse” und lade die Seite neu. Es geht auch schneller mittels STRG+UMSCHALT+Q.

Das Addon Firebug zu benutzen klicke einfach mit rechtem Mausklick in die zu untersuchende Webseite und wähle “Element mit Firebug untersuchen”. Dort klicke auf den Reiter “Netzwerk” und lade die Seite neu.

Um die tatsächlichen Werte zu erhalten, solltest Du auch den Browsercache deaktivieren. So wird die Seite geladen, als ob Du ein neuer Besucher wärst.

Ursprünglich lud die Startseite gut 580KB bei einer Ladezeit von 2.8s (onload) und benötigte 47 Abfragen. Das ist natürlich nicht eben toll, aber da ich nie auf die Startseite klickte, fiel mir das auch nie auf.

Derzeit sieht es so aus:

osC 2.2RC derzeitiger Stand

Mein osC 2.2RC derzeitiger Stand

27 Anfragen, 208.3KB Traffic, 0.883s onload

 

Für die, die sowas noch nicht kennen: Das sieht nur kompliziert aus.

Ganz links sieht man die Dateinamen, dann (nach rechts), den Status der Datei (ist alles OK? Fehlt sie? Ist sie kaputt?), den Host (woher kommt die Datei?), den Dateityp (Grafik, HTML, CSS, JS?) und die Dateigröße in KB.
Rechts sieht man die Anzeige, ob und wie schnell die Datei geladen wurde, welche Datei auf welche andere warten mußte etc.

 

Zum Vergleich hier einer der Shops, die bei osCommerce als Referenz angegeben werden:

Referenzshop Teil 1

Referenzshop Teil 1

schnipp schnapp. Die Liste der Dateien war so lang, das ich keinen screenshot mehr machen konnte :(

Referenzshop Teil 2

Referenzshop Teil 2

68 Anfragen, 763.9KB Traffic, 3.71s onload

 

 

Woher stammen diese Unterschiede?

 

(Wenn ihr das nachprüft, stellt ihr wahrscheinlich Unterschiede zu meinen Werten fest. Da ihr evtl. ein anderes OS, einen anderen Browser, andere DNS-Server ansprecht, eine andere Internetverbindung habt, wird es abweichen)

  • Der Referenzshop liefert viel mehr Dateien aus, die euer Browser gleichzeitig herunterladen und verarbeiten kann. Mein Shop: 27 Dateien – der Referenzshop 68.
  • Der Referenzshop liefert 12 JavaScript-Dateien und 11 CSS-Dateien aus. Mein Shop 1 JS-Datei (von google Analytics) und 1 CSS-Datei.
  • Der Referenzshop lädt JS und CSS kunterbunt durcheinander und verwendet keine CDN-(Sub-)Domains. Auch werden JS- und CSS-Dateien ausgeliefert, die für die Anzeige der Startseite gar nicht benötigt werden.
  • Die Grafiken sind nicht optimiert.

 

Ob jetzt der eine oder andere Shop hübscher aussieht ist Geschmackssache. Hier geht es in erster Linie um Geschwindigkeit und mein Shop kann sicher auch noch optimiert werden. Ich habe auf Anhieb kein besseres Beispiel gefunden, wollte keinen fremden Webshop “auseinanderpflücken” und habe auch keinen Zugriff auf dessen PHP-Dateien.

 

 

Was kann man relativ einfach verbessern an einem osC 2.2?

 

  1. Zuerst einmal wirft man alles von den Seite, das sich bewegt, blinkt, scrollt und umherhüpft. Das braucht kein Mensch, macht die Seite langsamer und lenkt den potentiellen Kunden sowieso nur ab.
  2. Extern eingebundene Dateien, wie z.B. Prüfsiegel, Counter,  PR-Anzeigen, Drittwerbung, Links zu Websites deren Banner per Hotlink eingebunden sind, etc.  verlangsamen den Seitenaufbau extrem: Also weg damit.
  3. Fasse viele kleine CSS-Dateien zu einer großen zusammen
  4. Mache Dir Subdomains und verwende sie als CDN (Content Delivery Network)
  5. Optimiere deine Grafiken
  6. Fasse Gestaltungselemente zu einer CSS-Sprite-Datei zusammen oder erzeuge sie gleich per CSS
  7. Lege die Reihenfolge der Dateiaufrufe sinnvoll fest (CSS oben, JS unten)
  8. Verwende Standardfonts (Schriften) die jeder auf seinem Rechner installiert hat
  9. Wenn Du “Social” bist, dann binde nur die Buttons (Like, Follow, g+, Pinterest usw.) asynchron ein. Verwende kein Modul, das Deinen Stream lädt und mitsamt vieler bunter Bildchen live anzeigt

 

 

Wie setzt man das nun um?

 

Die Punkte 1 und 2 sind schnell erledigt. Je nach deiner Kundengruppe solltest Du wissen, was deine Kunden benötigen. Wenn Du dich mit technischen Spielereien von deinen Mitbewerbern abheben willst, vergiss es: Biete deinen Kunden richtige Mehrwerte wie bessere Artikel, besseren Service, schnellere Lieferzeiten.

 

 

Punkt 3: CSS-Dateien. Wenn Du Module hast, die eigene CSS-Dateien haben, dann kopiere dir deren Inhalt in deine stylesheet.css (die osCommerce Standard-CSS). Du mußt daher alle Dateien dieses Modules ansehen und nach evtl. eingebundenen CSS-Dateien suchen; diese ersetzt Du dann mit dem Pfad zu Deiner stylesheet.css. Der Sinn der Sache ist: Dein Server kann 1 grosse Datei schneller ausliefern als viele kleine Dateien.

 

 

Punkt 4: CDN per Subdomain. Der Hintergrund ist recht simpel: Ein moderner Browser kann max. 6-10 (je nach OS und Browsereinstellung) Dateien gleichzeitig von einer Domain empfangen. Ältere Browser sogar nur 2-4. Gehen wir von der theoretischen Annahme aus, daß mein Shop 27 Anfragen benötigt, jede Anfrage eine gleichgroße Datei ausliefert und jede Datei 0.3s vom Server zu Dir auf den Browser benötigt; dein Browser dröselt erstmal die DNS auf, dann lädt er die ersten 6 Dateien in 0.3s; dann Datei 7-13, 14 bis 20, 21 bis 27. Das wären dann 1.2s. Bestenfalls! Theoretisch bestenfalls… Bei 68 Dateien wären es dann aber schon 3.6s.

Einen wissenswerten Punkt gibt es noch:

Ein Browser kann nur gleichzeitig mehrere Dateien von derselben Domain empfangen, wenn sie vom gleichen Dateityp sind!

Deshalb ist es unter anderem Wichtig, die Aufrufe so anzuordnen, das stehts die maximale Anzahl von gleichartigen Dateitypen aufgerufen werden kann. Lädt der Browser eine JS-Datei und die nächstfolgende Datei ist vom Typ CSS, dann wird diese nicht parallel zur JS-Datei heruntergeladen… der Browser wartet bis das JS angekommen ist und erst dann beginnt er mit der CSS-Datei. Ordnet man also die Aufrufe der Dateitypen ungünstig an und sie befinden sich alle auf derselben Domain(!) (JS, CSS, Grafik, CSS, JS…) kann der Browser immer nur eine Datei gleichzeitig empfangen.

Was liegt nun näher, als diese Beschränkung “Ein moderner Browser kann max. 6-10 Dateien gleichzeitig von einer Domain empfangen” zu umgehen, indem man mehrere Domain verwendet? Eine Subdomain wird als eigenständige Domain angesehen. Normalerweise kostet es keinen Cent, wenn man einige Subdomains anlegt. Also machen wir doch einfach eine Subdomain für Grafiken, für JS und eine für CSS. Oder 2. Oder 3.

Bei meiner Domain z.B. liegt das gesamte CSS auf der Subdomain css.seiden-handel.de. Das JS auf der Subdomain js.seiden-handel.de, Gestaltungselemente und viele Grafiken auf der Subdomain images.seiden-handel.de.

Seht euch nochmal die Grafik von weiter oben meiner Domain an:

osC 2.2RC derzeitiger Stand

osC 2.2RC derzeitiger Stand

Schaut euch die Hosts an: Woher kommen die Dateien? Es kommen immer max. 5 oder 6 Dateien von derselben (Sub)Domain nacheinander. So können sie sich nicht blockieren und es geht einfach schneller.

 

 

Punkt 5: Grafiken optimieren ist relativ einfach. Ich verwende Photoshop und JPEGmini für JPEG. Für PNG verwende ich TiniPNG. Bei Grafiken gilt: Weniger ist mehr! Zumindest in bezug auf Schnelligkeit. Ihr könnt immer noch riesige, zig-MB-große Photos nachladen, wenn der User mit dem Mauszeiger auf das für Ladezeit optimierte Bild draufgeht oder sie anklickt. Du hast tolle Produktfotos in 1200 x 900px und würdest sie gerne in der Seitenleiste zeigen? – Mach das. Aber dann mache das Bild nur so groß, wie es auch tatsächlich in der Seitenleiste angezeigt wird. Du kannst es ja verlinken zur Artikelseite, wo das Bild dann auch in 1200 x 900px angezeigt wird.

 

 

Punkt 6: Kleine Gestaltungselemente in eine CSS-Sprite zusammenfassen? Kein Ding. Der Sinn dieser Sache ist, das Du kleine Gestaltungselemente wie Pfeile, Buttons, Linien nicht mehr normal einbindest mit dem IMG-Tag, sondern sie über CSS einbindest. Dazu verwende ich gerne dieses Tool hier: CSS-Sprite-Generator. Ersetze nur 10 Minigestaltungselemente – die der User wahrscheinlich nicht mal wahrnimmt – und spare dir 10 Abfragen… denn die sind in der stylesheet.css enthalten.

Oder erzeuge Gestaltungselemente wie Hintergründe, Linien, Farbverläufe, Buttons, Listenpunkte gleich auschließlich per CSS. Oder lasse sie einfach weg… vieles muß nicht da sein, auch wenn sich ein Webdesigner das so ausgedacht hat und sich selbst verwirklichen wollte.

 

 

Punkt 7: CSS oben und JS unten aufrufen. CSS-Dateien sollte man sehr weit oben im Quelltext aufrufen: Im header. JS sollte man möglichst weit unten aufrufen. Entweder da, wo sie im body gebraucht werden oder kurz vor dem Ende des body-Tags. Und sogar da falls möglich nur mit dem Zusatz “defer”.

Wie das geht? Ganz einfach: Ich will z.B. eine JS-Datei einbinden. Wenn ich die ganz oben einbinden würde, müßte dein Browser warten, bis er die DNS dazu gefunden hat, die Datei eingebunden hat… und erst dann geht es mit dem laden und dem Aufbau der Website weiter. So lange wartest Du geduldig vor deinem weissen, nichtssagenden Browserfenster…

Also beseitigt man solche “Blockierer” indem man sie kurz vor das schließende </body> setzt und ihnen noch ein “defer” mitgibt.

Das macht man einfach indem an das so macht:

Select Code
1
<script src="http://js.seiden-handel.de/functions.js" defer type="text/javascript"></script>

Viele JS-Scripte sind allerdings essentiell für den Betrieb und die Anzeige von Shops. Wenn man bemerkt, das die Mitgabe eines DEFER-Attributes den Shop lahmlegt, dann sollte man darauf verzichten oder auf die Quelle verzichten.

Das “defer” bewirkt, das damit ausgezeichnete scripte ZULETZT geladen werden. Also nach allen anderen Dateien. Wenn dies allerdings ein JavaScript ist, das wichtig für den Aufbau der Site ist, wie z.B. JS-Prototype oder diverse bootstrap-Scripte, dann sollte man das besser nicht mit “defer” auszeichnen. Da hilft dann nur Trial & Error.

 
Punkt 8: Standardschriftarten verwenden. Man kann sehr einfach Schriftarten (Fonts) einbetten. Entweder über die google-api oder man legt die Font-Dateien auf dem eigenen Server ab. Man muß aber im Blick behalten, das diese Dateien mehrere MB groß sein können. Und bevor der Besucher deines Shops deine tolle Schrift bewundern kann, müssen die MB auf seinen Rechner gelangen.

Wenn die Fonts über die google-api aufgerufen werden, wird zusätzlich noch ein DNS-LookUp fällig.

Es gibt genügend ansprechende Fonts, die so ziemlich jeder Besucher auf seinem PC installiert hat oder – vom Besuch einer anderen Seite – im Cache hat.

 

 

Punkt 9: Facebook, Pinterest, g+ – Buttons werden gerne falsch eingebunden. Verwende zumindest einen asynchronen Aufruf ganz am Seitenende. Verzichte möglichst darauf, z.B. die ersten Einträge Deiner Timeline mit Userbildchen anzuzeigen. Das verzögert den Seitenaufbau extrem.  Wenn es irgendwie geht, dann binde nur die Buttons asynchron ein. Schau selbst nach und staune, wie sehr Deine Seite verlangsamt wird, wie viel Zeugs diese Socialdingens laden und vor Allem: Ständig nachladen. Und das bei jedem Seitenaufruf.

 

Wie das nun alles im Detail gemacht wird, erkläre ich nicht. Die obigen Punkte sind eher für Leute gedacht, die ihr Shopsystem, ihren Editor und Server kennen und gerne frickeln. Aber bevor man etwas besserbasteln kann, muß man erstmal wissen, wo man ansetzen kann und was man relativ einfach an einem osCommerce-Shop ändern kann.