Schnellere Webseiten und höhere Conversion durch Komprimierung

Anfang Januar habe ich das Hosting dieses Weblogs gewechselt und zwar von meinem seinezeit dienstältesten Root-Server (AMD Single Core, 2 GB RAM) dessen Last zum überwiegenden Teil von Mails erzeugt wird hin zu einem Dual Qualdcore mit 8 GB RAM, der vornehmlich für datenbankgestützte Webanwendungen genutzt wird. Mit dem Umzug einher gingen auch ein paar technische Umstellungen. Die reichlich vorhandene Power des neuen Servers setze ich u.a. dafür ein sämtlichen HTML-, CSS- und JavaScript-Content mit GZip komprimiert auszuliefern.

Kurz und bündig

  • Je schneller eine Webseite sich im Browser aufbaut, desto besser ist die User Experience, mit entsprechenden Auswirkungen auf Verweildauer, Klickverhalten auf Werbung, etc.
  • Die Komprimierung von HTML, CSS und JavaScript Code reduziert die Ladezeiten einer Webseite teils signifikant.
  • Mit wenigen Zeilen kann man seinen Webserver (auch bei Verwendung von Shared Hosting) dahingehend abrichten, die o.g. Inhalte komprimiert an Browser und Bots auszuliefern.

Technische Kosten und Nutzen der Komprimierung

Als Faustregel sagt man grob, dass die CPU Last bei der Verwendung der on-the-fly Komprimierung um etwa 10% pro Request ansteigt. Da HTML, CSS und JavaScript sich sehr gut komprimieren lassen (im Schnitt spart man etwa 70% Platz), lässt sich mit dieser recht einfachen Maßnahme viel Bandbreite sparen und die Daten werden vom Server schneller an den Webbrowser ausgeliefert, da die bei der Übertragung eingesparte Zeit bei weitem größer ist als die zusätzlich benötigte Zeit für die Komprimierung. Diese schnellere Auslieferung hat denn auch positiven Einfluss auf das Nutzerverhalten. Mehr dazu später.

GZip Komprimierung aktivieren für Apache 2.x

Die Realisierung der autom. Komprimierung von HTML, XML, CSS und JavaScript erfolgt über die .htaccess Datei im Hauptverzeichnis des Webs mit folgendem Code:


<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
</ifmodule>

Dieser Code gilt den Apache 2.x mit aktiviertem Modul mod_deflate, es handelt sich dabei um den Nachfolger des mod_gzip Moduls des Apache 1.3 Webservers. Sollte dies nicht vorhanden / aktiv sein, werden die Anweisungen einfach ignoriert. Für ein paar Problemkinder unter den Browsern, vornehmlich einige Dinosaurier, sind zudem Ausnahmeregelungen enthalten, damit es nicht zu Komplikationen kommt. Generell geht man aber davon aus, dass 90% und mehr der aktuell verwendeten Browser problemlos mit GZip Komprimierung klarkommen.

Über die Visualisierung der Crawling-Statistik in den Google Webmaster Tools kann man den Beschleunigungseffekt sehr schön darstellen. Hier sieht man deutlich, wie bei gleichbleibender Menge an Anfragen und abgerufener Daten (entpackt) die benötigte Zeit zum Herunterladen deutlich nach unten ging:

Verringerte Zugriffszeit nach Serverwechsel und Aktivierung der Komprimierung

Verringerte Zugriffszeit nach Serverwechsel und Aktivierung der Komprimierung

Mit der Grafik (und einem Kontrollblick in die Server-Logs) kann man auch direkt die Frage mit einem eindeutigen Ja beantworten, ob der Google-Bot die GZip Komprimierung unterstützt. Dies machte Google schon zu sehr frühen Zeiten und man kann sich vorstellen, wieviel Bandbreite und damit einhergehende Kosten sich so sparen lassen.

Je schneller desto Conversion

Web-Surfer sind ungeduldig. Trotz eines gewissen Trends zu ballaststoffreichen Websites mit viel Flash, Videos, etc. erwartet der User, dass Webseiten sich schnell im Browser aufbauen. Der stetige Fortschritt auch und gerade bei den Bandbreiten der Internet-Anschlüsse und die vollmundigen Werbeversprechen der Anbieter führen hier zu einer gewissen Erwartungshaltung.

In seinem Buch Website Optimization gibt Autor Andrew King auch anschaulich Zahlenmaterial weiter, welches Blogger Gabriel Svennerberg in seinem Beitrag Page Load Times vs. Conversion Rates teilweise zusammenfasst:

  • Eine von 0,4 auf 0,9 Sekunden ansteigende Ladezeit verringert den Umsatz bei Google um 20%.
  • Jede 0,1 Sekunde zusätzlicher Ladezeit verringert den Umsatz bei Amazon um 1%.
  • Ein Drittel aller Benutzer mit Breitband-Internet-Zugang ist nicht bereit länger als 4 Sekunden Seiten-Ladezeit hinzunehmen.

Zusätzlichen Lesestoff bietet King auf seiner Website zum Buch.

Abschluss und Ausblick

Wer seine Leser also nicht vergraulen möchte, sollte darauf bedacht sein ihnen eine möglichst gute Benutzererfahrung (Ist das wirklich die passende Übersetzung des Fachterminus UserExperience?) bieten. Neben dem Design kommt der gefühlten Geschwindigkeit einer Website hierbei eine tragende Rolle zu. Die hier vorgestellte Möglichkeit ist nur eine von sehr vielen kleinen und großen Maßnahmen, die man ergreifen kann. In jedem Fall ist sie aber sehr schnell umgesetzt und  auch für Laien einfach zu verwenden.

Seit gestern Abend habe ich in diesem WordPress Blog zusätzlich das WP Super Cache Plugin laufen. U.a. speichert es den von WordPress generierten HTML Output als Datei zwischen und liefert diese direkt an Browser aus (mit der zwischenzeitlichen Komprimierung durch den Webserver), so dass der Overhead für Datenbankabfragen und einen Großteil der PHP Skript-Ausführung wegfällt. Ähnliches macht das Boost Plugin für Drupal und Typo3 bringt diese Funktion von jeder mit.

Je nach System, Know-How und Budget gibt es eine Unmenge an organisatorischen und technischen Maßnahmen zur Optimierung der Ladezeiten einer Website. Einen guten Überblick erhält man auch bei Yahoo! in den Best Practices for Speeding Up Your Website (eine deutsche Kurzfassung gibt es auch bei den Webkrauts). Einen schönen Überblick über die eigenen Ladezeiten erhält man u.a. mit dem Firefox Plugin Firebug in der Netzwerkansicht und mit der Firebug Erweiterung YSlow (“Warum langsam?”) von Yahoo!.

Für einen ersten Rundblick tut es aber z.B. auch ein webbasierter Dienst wie den Web Page Analyzer von Andy King. Hier muss man aber etwas vorsichtig sein, da ja der anfragende und auswertende Server in den USA (Chicago) steht..

Kommentare (4) Schreibe einen Kommentar

  1. Sehr schöner Beitrag!

    Ist das wirklich alles? Also dass nur ein Eintrag in der .htaccess erforderlich ist, dass gzip komplett läuft oder muss ich auch noch spezielle Header senden, Inisets, ….?

  2. Nein, das ist im Grunde schon alles. Voraussetzung ist natürlich, dass mod_deflate vorhanden, aktiv und vom Hoster für die eigene Verwendung in der .htaccess freigeschaltet ist.

  3. Pingback: Praktische Tipps und Plugins zur Ladezeit-Optimierung » Ladezeit-Optimierung » Ladezeit, Optimierung, Tipps, Plugins, Blog, Google

  4. Sind wir doch mal ehrlich: Lädt eine Seite ruckweise und nur etwas zu langsam für unseren übereilten Geschmack, so verfallen wir oftmals in einen Fluchtinstinkt. Übertreibt es eine Seite mit den Informationen schon im Startbereich, nehmen die User ebenso schnell Reißaus. In den letzten Jahren habe ich in Bezug auf das Layout einer Website eines gelernt. Eine Seite ist nur so gut, wie Ihre Struktur. In diesem Bereich das Prinzip: Weniger ist manchmal mehr.

Hinterlasse eine Antwort

Pflichtfelder sind mit * markiert.