Weboptimierung

Permalink

In den letzten beiden Wochen habe ich mal wieder ein gutes Buch für mich entdeckt: Responsive Webdesign. Wunderbar aufbereitet, mit lockerem Still und thematisch treffsicher. Ich kann es jedem nur ans Herz legen dieses Buch zu lesen.

Was hat das aber mit dem Thema diese Artikels zu tun? Eigentlich nicht viel. Ich habe nur das Kapitel “Performance” des Buches zum Anlassen genommen die gängigen Maßnahmen zu Performanceoptimierung auch mal auf meinen eigenen Internetauftritt anzuwenden.

Bei der Performanceoptimierung von Webauftritten gibt es vier Aspekte. Das Volumen eine Webseite, also die Anzahl der Bytes die über das Netzwerk übertragen werden müssen, die Anzahl der HTTP-Requests und damit den Umfang des Protokoll-Overheads, die Zeit die benötigt wird bis die Seite einsatzbereit erscheint und die Ausführungsgeschwindigkeit der Javascripte.

Letzteres werde ich nicht weiter betrachten, weil es für meine Seite so gut wie keine Rolle spielt – ich verwende schlicht kaum Javascript.

CSS-Minifizierung

bei der Minifizierung von CSS-Dateien geht es darum das Stylesheet so klein als möglich zu machen und auch dessen Zersplitterung in mehreren Dateien zu verhindern. Da ein solches Stylesheet, es besteht quasi nur noch aus einer einzigen langen Zeile, nicht gerade dazu einlädt daran weiterzuarbeiten benötigt man ein Tool. Solch ein Tool machen aus einer sauber und ordentlich strukturierten CSS-Datei eine Textwüste. Für diese Arbeit benutze ich persönlich den YUI Compressor. Da diese Java-Programm nur jeweils eine Datei bearbeitet schreibe ich mir Batchscripte die alle Dateien eines Projektes abklappern. Anschließend kopiere ich mir dann alle Ergebnisse zu einem Gesamt-Stylesheet zusammen. Wie das ganze dann aussieht kann man am Stylesheet dieser Seite sehen.

Das dieser Schritt nicht in meiner Übersichtstabelle unten auftaucht liegt daran das ich das schon seit längerer Zeit so umgesetzt habe und daher keine Vergleichswerte zur Hand hatte.

Scripte verlagern

Ein üblicher Tipp ist es die <script>-Tags möglichst weit unten im HTML-Dokument zu notieren. Am besten direkt vor dem schließenden <body>-Tag. Der Grund hierfür: Wann immer der Browser auf ein Script trifft bearbeitet er erst mal nur dieses Script und sonst nichts. Wenn die Scripte also am Ende stehen erscheint die Seite bereits fertig. Wenn der Browser also mit den Scripten anfängt hat der Benutzer gute Chancen die Seite bereits nutzen zu können.

Data-URI’s

Bilder kann man nicht nur in Dateien ablegen. Man kann sie auch als Kette von Buchstaben repräsentieren. Diese Base64-Codierung kann man verwenden um Bilder direkt in eine CSS-Datei einzubinden anstatt Referenzen auf zusätzliche Daten zu benutzen. Diese Art Bilder in einer direkten Repräsentation zu verwenden wird als Data-URI bezeichnet Damit kann man die Anzahl der HTTP-Requests reduzieren. Im Gegenzug erhöht sich aber die Größe der Bilder durch die Base64-Codierung.

Komprimierung

Man kann den Datenstrom zwischen Server und Client komprimieren. Wenn der Browser im Request angibt welche Kompressionsalgorithmen er unterstützt kann der Server eine menge Traffic sparen.

Im Apache Webserver kann man mittels einiger Zeilen in einer .htaccess-Datei die Komprimierung aktivieren und Konfigurieren:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/css application/json
  AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript
  AddOutputFilterByType DEFLATE text/xml application/xml
  AddOutputFilterByType DEFLATE application/xhtml+xml application/rss+xml
  AddOutputFilterByType DEFLATE application/atom+xml
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
  AddOutputFilterByType DEFLATE font/ttf application/x-font-ttf font/opentype
  # No need to GZIP woff files, they're already GZIP'd
</IfModule>

Caching

Noch mehr Transvervolumen kann man sparen wenn man Dateien gar nicht erst auf die Reise schickt. Dies kann man erreichen indem man alle verschickten Dateien mit einem “Mindesthalbarkeitsdatum” versieht. So weiß der Client, normalerweise also ein Browser, wie er gut cachen kann.

Ein Ablaufdatum lässt sich wiederum durch einen Eingriff in die .htaccess-Datei für die einzelnen Dateitypen einstellen:

<IfModule mod_expires.c>
  Header set cache-control: public
  ExpiresActive on
  ExpiresByType text/html "access plus 2 hours"
  ExpiresByType application/xhtml+xml "access plus 2 hours"
  ExpiresByType application/x-javascript "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
  ExpiresByType text/javascript "access plus 1 month"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType text/plain "access plus 1 month"
  ExpiresByType image/svg+xml "access plus 1 month"
  ExpiresByType image/png "access plus 1 month"
  ExpiresByType image/x-icon "access plus 1 month"
  ExpiresByType font/ttf "access plus 1 year"
  ExpiresByType font/opentype "access plus 1 year"
  ExpiresByType application/x-font-woff "access plus 1 year"
  ExpiresByType application/vnd.ms-fontobject "access plus 1 year"
</IfModule>

Ergebnis

Veränderungen einzelner Werte für jeden Optimierungsschritt
Situation Erstmaliger Aufruf Wiederholter Aufruf (Caching)
Ladezeit HTTP-Requests Volumen HTTP-Requests Volumen
Einheit ms kb kb
Ausgangssituation 1500 13 230,6 12 47.1
Veränderungen -806 -4 -123,2 -11 38,2
Scriptverlagerung 1620 13 230,6 12 47.1
CSS Data-URI’s 785 10 247,0 9 74,5
Kompression 833 10 134,0 9 26,4
Caching 1350 10 134,0 2 0
WOFF Mime-Type 694 9 107,4 1 8,9

Die Messungen habe ich mit YSlow durchgeführt. YSlow ist ein Firefox-Addon das allerlei Hinweise und Analysen rund um das Thema Webperformance bereitstellt.

Leider sind bei mir die aus YSlow entnommenen Ladezeiten nicht wirklich zu gebrauchen. Meine Internetverbindung schwankte während der Messungen scheinbar sehr.

Mime Types

Wer die obige Tabelle aufmerksam gelesen hat hat bestimmt gemerkt das diese eine weitere Zeile “WOFF Mime-Type” enthält die bisher nicht erklärt wurde. Im verlauf der Optimierung habe ich festgestellt das das Dateiformat WOFF nicht mit dem korrekten Mime-Type ausgeliefert wird. Also habe ich die passende Deklaration in der .htaccess-Datei ergänzt.

AddType application/font-woff .woff

Interessanterweise hat dies Auswirkungen auf YSlow: Die Schriftdatei fällt jetzt komplett aus der Messung heraus und wird weder bei der Anzahl der HTTP-Requests noch beim Transfervolumen angerechnet.