Die folgenden Abschnitte gehen auf die unterschiedlichen, von YSlow durchgeführten, Tests für eine Website ein, die die Performance der Website auf bestimmte Merkmale hin untersuchen. Dabei zeigen sie mögliche Ansätze für eine Verbesserung der Geschwindigkeit unter Verwendung des ECMS eZ Publish auf. Weitere Informationen zu möglichen Optimierungsmaßnahmen finden sich auf der entsprechenden Seite von Yahoo.

Make fewer HTTP requests

Prinzipiell sollte die Anzahl der notwendigen Anfragen an den Web-Server so gering wie möglich sein, um eine einzelne Seite anzuzeigen. Da eine Seite heutzutage nicht nur aus reinem Text, sondern auch aus Bildern, Stylesheets und Javascript Dateien besteht, wird in der Regel mehr als eine Anfrage an einen Web-Server gestellt, um eine Seite darzustellen. Unnötige, zusätzliche Anfragen an den Web-Server werden normalerweise aufgrund der folgenden Tatsachen gestellt:

• Die Seite benötigt mehrere Stylesheets, um die Seite korrekt zu formatieren und darzustellen
• Die Seite benötigt mehrere Javascript Dateien, um die Inhalte dynamisch zu verändern oder Inhalte nachzuladen
• Die Seite verwendet mehrere Bilder, die aus den Stylesheets heraus referenziert werden und nachgeladen werden müssen

In der Regel müssen im Hinblick auf Stylesheets und Javascript-Dateien nur genau 3 Dateien eingebunden werden:

• Eine Javascript Datei
• Eine Stylesheet Datei für die Darstellung im Browser (Media screen)
• Eine Stylesheet Datei für die Darstellung in der Druckansicht (Media print)

Dies kann in eZ Publih durch die Verwendung der ezjscore einfach erreicht werden, die einen entsprechenden Template Operator zur Verfügung stellt, um Stylesheets und Javascript Dateien zu einer Datei zusammenzufassen und zu komprimieren.

Dahingegen ist die Reduktion der durch die Stylesheets referenzierten (Hintergrund-)Bilder etwas problematischer. Gerade in Bezug auf Standard-Installationen besteht hier das Problem, dass für die Darstellung runder Rahmen mehrere kleine Bilder verwendet werden (müssen). Die Lösung für dieses Problem ist die Verwendung von CSS Sprites in denen mehrere Bilder in einer Datei zusammengefasst werden und über Stylesheets gesteuert, nur die Bereiche des Bildes angezeigt werden, die für das darzustellende Element benötigt werden. In manchen Fällen ist das technisch nicht möglich. Dennoch sollte man sich bereits im Vorfeld überlegen, wie man das Design einer Internetseite so auslegen kann, dass es eine Verwendung von CSS Sprites unterstützt.

Use a content delivery network (CDN)

Die Verwendung eines Content Delivery Network (oder auch Content Distribution Network ) ist ausgerichtet auf "große" Internetseiten, wobei "groß" sich entweder aus einer Vielzahl großer Dateien oder aus der Vielzahl von Besuchern ergibt, die gleichzeitig auf die auszuliefernden Seiten zugreifen. In solchen Fällen kann der Einsatz mehrerer Webserver, die an weit auseinander liegenden Standorten platziert sind, dazu genutzt werden, den physikalischen Abstand zwischen dem Computer des Besuchers und dem Webserver, der die Inhalte ausliefert, zu verkürzen. Dadurch findet einerseits eine Lastverteilung und andererseits auch eine Verkürzung der Antwortzeit statt. Diverse Anbieter verfügen bereits über Netzwerke aus Webservern, die zu diesem Zweck verwendet werden können. Eine solche Maßnahme ist prinzipiell unabhängig von eZ Publish.

Dennoch ist unter diesem Punkt auch noch eine Alternative zu nennen, die auch bei kleineren Internetseiten verwendet werden kann. Dazu muss bekannt sein, dass heutige Internet-Browser im Normalfall nur eine begrenzte Anzahl von Anfragen an den gleichen Host stellen. Erst wenn mindestens eine dieser Anfragen beantwortet wurde, wird an neue Anfrage an den gleichen Host gestellt. Dadurch kann eine Zeitverzögerung entstehen, vor allem wenn für die Darstellung einer Seite mehrere Anfragen an den gleichen Host gestellt werden müssen (was normalerweise der Fall ist). Um eine bessere Parallelisierung der Anfragen zu erreichen, können einfach zusätzliche Hosts (auf dem gleichen, physikalischen Webserver) eingerichtet werden. Das bedeutet, prinzipiell werden die Anfragen von dem gleichen Webserver beantwortet (es findet also in diesem Fall kein Lastverteilung statt), was der Internet-Browser jedoch nicht "weiß". Wenn also für die Darstellung einer Internetseite 8 Anfragen notwendig sind, würde das mit einem Host evtl. so aussehen: 4 Anfragen an Host 1 - Warten - 4 Anfragen an Host 1. Dahingegen würde es mit zwei Hosts evtl. so aussehen: 4 Anfragen an Host 1 und 4 Anfragen an Host 2 (also keine Wartezeit).

Ein solches Verfahren kann relativ einfach umgesetzt werden, indem ein (oder auch mehrere) zusätzlicher VirtualHost im Webserver konfiguriert wird, der einen unterschiedlichen Namen hat. Im Fall von eZ Publish bietet es sich an, über diesen zusätzlichen Host eben gerade die Inhalte ausliefern, die durch die Verwendung der RewriteRules bereits ohne die Verwendung etwaiger PHP-Skripte ausgeliefert werden. Dadurch können außerdem die RewriteRules auf dem anderen Host entfernt werden. Allerdings muss sichergestellt sein, dass der zweite Host auch immer für die Auslieferung dieser Inhalte verwendet wird. Dazu kann dieser Host in den entsprechenden Templates von eZ Publish (am besten über eine .ini-Datei konfigurierbar) direkt in den Verweisen verwendet werden, also z.B.

Ebenso kann in den Stylesheets eine absolute URL angegeben werden wie z.B.

Eine weiterführende Lösung ist es nicht nur einen, sondern mehrere solcher zusätzlicher Hosts zur Verfügung zu stellen und diese durch ein Rotations-Verfahren im Wechsel zu verwenden. Eine derartige, automatische Rotation ist bei Stylesheet-Dateien dann nicht mehr möglich, aber es ist durchaus möglich entsprechende Template-Operatoren zu verwenden. Allerdings dürfen es auch nicht zu viele zusätzliche Hosts werden, da für jeden Host eine entsprechende DNS-Anfrage gestellt werden muss. Das würde dann wiederum zu einer schlechten Bewertung bei dem Punkt "Reduce DNS lookups" führen.

Add Expires headers

Ruft ein Anwender über seinen Internet-Browser eine Seite auf, die von eZ Publish ausgeliefert wird, dann enthält die Antwort auf diese Anfrage in der Regel eine Information darüber, wie lange der Inhalt dieser Seite gültig ist. Hier liefert eZ Publish normalerweise ein Datum zurück, das in der Vergangenheit liegt, um sicher zu stellen, dass der Anwender immer aktuelle Inhalte zu sehen bekommt. Das gilt allerdings nur für Inhalte, die auch von eZ Publish ausgeliefert werden, also in der Regel z.B. nicht für Stylesheets, Javascript-Dateien oder Bilder, die nicht zum Inhalt gehören. Kurz gesagt alle Elemente für die es eine Ausnahme-Regel in den RewriteRules des Webservers gibt (soweit diese konfiguriert worden). Für diese Elemente ist normalerweise gar kein Datum in der Antwort des Webservers enthalten, dass eine Auskunft darüber gibt, wann der Inhalt als ungültig (abgelaufen) anzusehen ist. Das führt dazu, dass derartige Elemente immer wieder neu angefragt werden, was in den o.g. Fällen ungünstig ist, da sich diese mit sehr hoher Wahrscheinlichkeit nicht ändern, während sich ein Besucher durch mehrere Seiten klickt (dort aber ja immer wieder die gleichen Elemente angefragt werden).

Um nun den Webserver dazu zu bringen, einen sogenannten Expires-Header auszuliefern, muss der Webserver entsprechend konfiguriert werden. Eine Beispiel-Konfiguration, die eine solche Information im Antwort-Header des Webservers unterbringt, ist im Artikel eZ Publish Performance dargestellt. Dadurch wird für alle Stylesheets, Javascript-Dateien und Bilder ein Expires-Header mit einem Ablaufdatum das ein Jahr bzw. eine Woche in der Zukunft liegt, in die Antwort des Webservers eingefügt. Soweit im Rahmen der Optimierung "Use a content delivery network (CDN)" auch ein eigener Host für die Auslieferung statischer Inhalte eingerichtet wurde, sollte vor allem in der Konfiguration dieses Hosts auch das Setzen des Expires-Headers enthalten sein.

Compress components with gzip

Das Komprimieren von Inhalten muss nicht unbedingt ein Vorteil sein, da die Inhalte zunächst auf dem Server komprimiert und nach der Übertragung dann wieder auf dem Computer des Besuchers dekomprimiert werden müssen. Das geht auf beiden Seite zu lasten der Rechenleistung. Dem gegenüber steht eine bessere Ausnutzung der Bandbreite. Ob Inhalte komprimiert werden sollen oder nicht muss also im Einzelfall entschieden werden.

Für das Komprimieren von Inhalten sind keine Modifikationen hinsichtlich eZ Publish notwendig, lediglich der Webserver muss entsprechend konfiguriert werden. Dazu gibt es das Modul mod_deflate . Ein Beispiel für eine entsprechende Konfiguration des Webservers ist im Artikel eZ Publish Performance dargestellt.

Put CSS at top

Die Definition des Seitenstils sollte sich immer am Anfang einer Internetseite befinden. In der Regel wird das durch die Einbindung mehrerer Stylesheets (.css Dateien) erreicht. Diesen Inhalten Informationen darüber, wie die auf der Internetseite enthaltenen Informationen dargestellt werden sollen. Sinnvollerweise werden diese Stylesheet Dateien in eine einzelne Datei zusammengefasst (siehe auch "Make fewer HTTP requests"). Die Einbindung von Stil-Informationen innerhalb einer Internetseite sollte vermieden werden. In den Standard-Installationen von eZ Publish werden die Stylesheet Dateien am Anfang einer Seite eingebunden.

Put JavaScript at bottom

Im Gegensatz zu den Stylesheet Dateien sollten Javascript Dateien am Ende einer Seite eingebunden werden. Dadurch soll verhindert werden, dass der Browser bereits während des Ladens einer Seite mit der Ausführung von Javascript Code zusätzlich belastet wird. In den Standard-Installationen von eZ Publish werden die Javascript Dateien zwar am Anfang einer Seite eingebunden, allerdings folgt aus der reinen Einbindung nicht zwangsläufig auch die Ausführung von Javascript Code. Bei der Entwicklung eigener Javascript Dateien sollte darauf geachtet werden, dass der Code erst ausgeführt wird, wenn die Seite bereits vollständig geladen wurde. Dies kann z.B. wie folgt erreicht werden:

Dabei ist der Platzhalter <MEINE_FUNKTION> durch den Namen der Funktion zu ersetzen, die ausgeführt werden soll. Dabei können, im Gegensatz zu der onload Funktion, auch mehrere Funktionen beim Laden der Seite ausgeführt werden.

Avoid CSS expressions

Hierbei handelt es sich um einen Punkt der ausschließlich im Zusammenhang mit dem Internet Explorer Browser von Microsoft steht. Da heutzutage niemand mehr Browser der Firma Microsoft verwendet, kann dieser Punkt getrost vernachlässigt werden.

Reduce DNS lookups

Wo in den Anfangszeiten des Internet die Inhalte in der Regel von einem Webserver mit einem Host-Namen ausgeliefert wurden, sind heute oft mehrere Hosts (egal ob auf einem oder mehreren Webservern) an der Auslieferung einer Seite beteiligt. Ein typisches Beispiel in eZ Publish ist die Verwendung von Javascript Dateien aus der Yahoo User Interface Library ( YUI Bibliothek ), die nicht von dem Webserver ausgeliefert werden, auf dem eZ Publish installiert ist, sondern direkt von den entsprechenden Yahoo Servern. Für jeden Host-Namen, der für die Auslieferung einer kompletten Seite notwendig ist, muss zunächst eine DNS-Anfrage (Domain Name Service) an einen Nameserver gestellt werden. Dieser ermittelt die zu einem Host-Namen gehörigen IP Adresse. Als grobe Richtlinie sollten nicht mehr als vier unterschiedliche Hosts notwendig sein, andernfalls kann sich die für die DNS-Anfragen notwendige Zeit bereits negativ bemerkbar machen. Das sollte auch beachtet werden, wenn für einen Internetauftritt ein kleines CDN verwendet wird (siehe "Use a content delivery network (CDN)").

Minify JavaScript and CSS

Typischerweise sind Javascript- und Stylesheet-Dateien so geschrieben, dass sie vom Menschen gut gelesen werden können. Das ist für die Entwickler einer Seite entsprechend wichtig, für den Besucher einer Seite jedoch nicht. Aus diesem Grund sollten diese Dateien auf einem Produktiv-System entsprechend verkleinert werden, indem Leerzeichen, Tabulatoren und Zeilenumbrüche entfernt werden, ohne das das Format der Datei ungültig wird.

Zu diesem Zweck kann in eZ Publish die Erweiterung ezjscore verwendet werden, die entsprechende Template Operatoren zur Verfügung stellt. Diese verkleinern die Dateien nicht nur, sondern führen auch mehrere Dateien zu einer einzigen zusammen (siehe auch "Make fewer HTTP requests").

Avoid URL redirects

Das Vermeiden von URL redirects in eZ Publish ist nicht ganz einfach, da es ein integraler Bestandteil von eZ Publish ist. Daher gibt es hierfür im Moment keinen mir bekannten Lösungsansatz. Allerdings werden in eZ Publish Weiterleitungen bevorzugt bei der Bearbeitung von Inhalten verwendet, aber nicht wenn Inhalte einfach nur ausgeliefert werden sollen. Daher sollte dieser Punkt keine negativen Auswirkungen haben, soweit es sich um einen normalen Besucher der Internetseiten handelt, der sich die Inhalte lediglich ansehen möchte.

Remove duplicate JavaScript and CSS

Soweit die in einer Seite einzubindenden Javascript und Stylesheet Dateien - wie bereits erwähnt - zentral am Anfang einer Internetseite auf die eZ Publish typische Art und Weise eingebunden werden, kann relativ einfach sichergestellt werden, dass Dateien nicht mehrfach eingebunden werden. Hierzu kann einfach die Ausgabe des "ezini" Template Operators, der die Dateien aus einer .ini liest, an den Template Operator "unique" übergeben werden, der dann doppelte Einträge heraus filtert. Im optimalen Fall wird die dadurch erzeugte Ausgabe wiederum an die bereits erwähnten Template Operatoren der ezjscore Erweiterung übergeben, um diese zusammenzufassen und zu verkleinern.

Configure entity tags (ETags)

Bei den ETags (Entity Tags) handelt es sich um eine eindeutige ID, die für jedes Element einer Seite (also z.B. Stylesheets, Javascript-Dateien, Bilder, etc.) vergeben werden kann. Diese ID kann zusammen mit dem Response-Header bei der Antwort des Webservers übermittelt werden. Soweit für die Auslieferung von Inhalten mehrere Webserver oder Hosts verwendet werden, kann diese ID dazu verwendet werden ein Element (eine Entität) eindeutig zu identifizieren, um weitergehend abfragen zu können, ob das jeweilige Element noch gültig ist oder nicht. Da eZ Publish diesen Mechanismus bisher nicht unterstützt, ist es am besten die Unterstützung für ETags im Webserver einfach zu deaktivieren. Im Apache Webserver kann dazu einfach die Zeile

in die Konfiguration des virtuellen Hosts (VirtualHost) eingetragen werden.

Make AJAX cacheable

Nicht erst seit gestern ist AJAX in aller Munde und moderne Internetseiten machen reichlich Gebrauch von dieser Funktionalität. Soweit nur wenige AJAX Anfragen innerhalb einer Seite an einen Webserver gestellt werden, ist dieser Punkt wahrscheinlich zu vernachlässigen. Allerdings geht der Trend eindeutig in die Richtung das immer mehr Anfragen im Hintergrund an den Webserver gestellt werden, um den Aufbau einer Seite zu beschleunigen bzw. dem Besucher ein entsprechendes Gefühl zu vermitteln. Mit einer steigenden Anzahl solcher Anfragen, muss sich ein Entwickler auch Gedanken darum machen, wie eine solche Anfrage dauert. Wenn für jede Anfrage immer wieder der gesamte Inhalt neu ausgeliefert wird, kann dies ebenfalls einen negativen Einfluss auf die Geschwindigkeit der Seite haben. Deshalb sollte darauf geachtet werden, dass auch bei "Teil-Seiten", die über AJAX nachgeladen werden, die bereits erwähnten Maßnahmen greifen. Soweit Standard-eZ-Publish Seiten über AJAX nachgeladen werden und die bereits erwähnten Maßnahmen durchgeführt wurden, sollte dieser Punkt damit ebenfalls abgehandelt sein. Andernfalls, muss sich ein Entwickler selber darum kümmern ein 304 (not modified) zu senden, falls die nachzuladenden Inhalte gleich geblieben sind.

Use GET for AJAX requests

Des weiteren sollte ein Entwickler darauf achten, dass bei einer Anfrage, die per AJAX an den Webserver gestellt wird, die GET und nicht die POST Methode verwendet wird. Das ist zwar nicht immer möglich, sollte ab in der meisten Fällen der Standard sein. Der Hintergrund hierbei ist, das im Optimalfall eine GET-Anfrage in einem TCP-Paket (Transport Control Protocol) verschickt werden kann.

Reduce the number of DOM elements

Die Anzahl der DOM Elemente (Document Object Model) ergibt sich im wesentlichen aus der Anzahl der HTML-Tags und Javascript Funktionen, die auf einer Seite verwendet werden. Die Erweiterung Firebug für den Firefox Internet Browser erlaubt es einem, durch diese Element zu navigieren, um einen Eindruck zu erhalten, was alles in dem sogenannten DOM Baum gespeichert wird. Die Anzahl der DOM Elemente zu reduzieren kann durch kleinere Internetseiten (also weniger HTML Code) und durch kleinere bzw. weniger Javascript Dateien erreicht werden. Je weniger DOM Elemente eine Internetseite enthält, desto weniger Daten müssen aus dem Internet übertragen werden und desto schneller wird Javascript ausgeführt, dass mit diesen Elementen arbeitet.

Avoid HTTP 404 (not found) error

Wird eine Internetseite aufgerufen, die es gar nicht gibt, resultiert das in einem schlechten Kosten-Nutzen-Verhältnis: Der Server und das Netzwerk werden (wenn auch nur gering) belastet, aber der Besucher der Seite hat von dem Ergebnis nichts. Daher sollten derartige fehlerhafte Anfragen vermieden werden. Das ist selbstverständlich nicht möglich, wenn der Besucher z.B. eine falsche URL eingibt. Fehlerhafte Verweise in den Internetseiten können dagegen vermieden werden. Dazu bietet eZ Publish im Administrations-Bereich die URL Verwaltung an, mit der ungültig Verweise ermittelt werden können. Außerdem werden fehlerhafte Anfragen in der Regel auch in der error.log Datei protokolliert. Es kann also nicht Schaden diese Datei zu untersuchen. Letztendlich gibt auch die access.log Datei des Apache Webservers Informationen darüber preis, welche Anfragen mit einem 404 Fehler beantwortet wurden.

Ein Beispiel hierfür it die Datei "favicon.ico", die in der Regel automatisch von aktuellen Browsern angefragt wird, obwohl sie evtl. nirgends referenziert ist. Entweder wird also diese Datei im Hauptverzeichnis des Webservers zur Verfügung gestellt oder in der Internetseite wird ein Verweise auf die entsprechende Datei hinterlegt.

Reduce cookie size

Die wenigen Cookies, die in einer Standard-Installation von eZ Publish verwendet werden, haben bereits eine geringe Größe (da sie einen entsprechend kleinen Inhalt haben). Dieser Punkt muss also nur dann berücksichtigt werden, wenn man zusätzliche Cookies verwendet oder die Inhalte vorhandener Cookies vergrößert.

Use cookie free domains

Die Cookies, die von eZ Publish verwendet werden, werden primär dazu verwendet, den aktuell angemeldeten Benutzer zu identifizieren bzw. benutzerbezogene Informationen dem aktuellen Besucher korrekt zuordnen zu können. Diese Informationen werden jedoch nicht für alle Elemente einer Seite benötigt (wie z.B. Stylesheets, Javascript Dateien oder Bilder, die nicht zum Inhalt gehören). Daher spielen die Cookies bei Anfragen an den Webserver für diese Elemente keine Rolle. Um zu verhindern, dass die Cookies bei Anfragen für diese Elemente übermittelt werden, kann eine eigene Domain eingerichtet werden, die für die Auslieferung eben dieser Elemente verwendet wird, jedoch keine Cookies überträgt. Somit bietet es sich an, aus dem unter "Use a content delivery network (CDN)" beschriebenen zusätzlichen Host für die Auslieferung statischer Elemente eine Domain zu machen. Somit wird dann z.B. für die Auslieferung der eigentlichen Inhalte der Host "www"

verwendet (der sich in der Domain dynamischer.host.de befindet), während für die Auslieferung der statischen Inhalte der Host "mein"

verwendet wird (der sich in der Cookie-freien Domain statischer.host.de befindet). Das "Cookie-frei" ergibt sich daraus, dass im Fall der statischen Elemente auf dem Server keine PHP-Dateien ausgeführt werden, die in der Regel dazu verwendet werden eine Session und damit dann auch Cookies zu erzeugen.

Avoid AlphaImageLoader filter

Hierbei handelt es sich um einen Punkt der ausschließlich im Zusammenhang mit dem Internet Explorer Browser von Microsoft (kleiner Version 7) steht. Da heutzutage niemand mehr Browser der Firma Microsoft verwendet, kann dieser Punkt getrost vernachlässigt werden.

Do not scale images in HTML

Dieser Punkt kann im Fall von eZ Publish getrost vernachlässigt werden, da in eZ Publish Bilder (die zum Inhalt gehören) automatisch bereits auf dem Server skaliert werden. Daher besteht keine Notwendigkeit eine Skalierung von Bildern in HTML vorzunehmen.

Make favicon small and cacheable

Die Datei "favicon.ico" wird in der Regel automatisch von heutigen Browsern angefragt. Aus diesem Grund sollte dafür Sorge getragen werden, dass

• diese Datei existiert
• sie möglichst klein ist
• und sie mit einem sinnvollen Expires-Header (siehe oben) ausgeliefert wird