Ladezeiten optimieren mit GZip-Kompression am IIS

Zugegeben: Langer Titel. Dafür weiß man dann auch, was im Beitrag zu erwarten ist 😉 Nachdem jüngst seitens Google bestätigt wurde, das Ladezeit ein „offizieller  Rankingfaktor“ ist (wenngleich derzeit noch nur ein verschwindend kleiner Bruchteil der Suchergebnisseiten von diesem Faktor – minimal – beeinflusst werden), macht sich erfreulicherweise nun auch der „nur SEO-orientierte“ Webmaster Gedanken über Optimierung der Ladezeiten auf seiner Domain, so dass dieser Beitrag nicht in den Web-Usability-Tipps erscheinen muss, sondern auch hier einen Platz findet.

Über Suchmaschinen finden sich leicht zahlreiche Anleitungen zur Nutzung der Kompression (oder Komprimierung? Hmmm…) mittels PHP bzw. passende Konfiguration des Servers – die meisten Anleitungen sind aber nur für die Linux-Welt gedacht und helfen an Microsofts Internet Information Server „IIS“ nur bedingt bis gar nicht. Und während die grundsätzliche Aktivierung für statische oder dynamisch produzierte HTML-Dokumente am IIS relativ simpel ist, muss man nach den erforderlichen Schritten zur Konfiguration einer „vollständigen“ Nutzung von GZip, so dass z. B. auch CSS-Dateien oder ausgelagerter JavaScript-Code eingeschlossen wird, länger umschauen… zumindest, wenn man sich seltener mit Administrationsaufgaben befasst. Aber keine Sorge – es ist kein Hexenwerk, erfordert keinen Serverneustart und ist hier recht ausführlich im Folgenden erläutert.

Was und warum?

Wenn es um die Optimierung von Ladezeiten für Webseiten geht, können sehr viele verschiedene Aspekte optimiert und Probleme auf unterschiedlichste Weise gelöst werden. Alle zielen darauf ab, eine Seite nicht nur schneller aufzubauen, sondern auch möglichst ohne Verzögerungen im Browser darstellbar zu gestalten. Das primäre Ziel ist es also, dem realen Benutzer eine möglichst flüssige Verwendung der Website zu erlauben. Daneben geht es aber auch darum, den eigenen Server zu entlasten, Bandbreiten einzusparen und es nicht zuletzt auch den Robots der Suchmaschinen zu ermöglichen, möglichst viele Inhalte in minimaler Zeit zu „erforschen“.

Grundätzlich ist es dabei immer eine gute Idee, sich unabhängig von allen anderen Mitteln mit der Miniminerung von Quellcode, Optimierung von Bildern und Vermeidung unnötiger Serveranfragen oder träger Auslieferung von Seiten aufgrund unterdimensionierter Datenbank- oder Webserver zu befassen (und ggf. auchg dem verwendeten CMS, Serverscripten und einer Unmenge anderer Dinge). Wer es noch nie getan hat, sollte sich daher nach Firefox und Firebug auch Google Page Speed oder Yahoo´s YSlow installieren und nicht nur mit dem dadurch aufzeigbaren Status Quo für seine Webseiten befassen, sondern auch mit den dort zu findenden Optimierungstipps, die nichts mit GZip zu tun haben. Dennoch bleibt die Aktivierung der Kompression eines der Mittel, mit denen i. d. R. der meiste Effekt erzielt wird.

So viel Warnung sei noch erlaubt:  Es ist natürlich immer eine gute Idee, bei Verfügbarkeit die Schritte zunächst an einem Testserver durchzuführen oder zumindest eine möglichst traffic-arme Tageszeit für seine ersten gehversuche zu wählen, wenn denn kein erfahrener Administrator mit der Konfiguration beauftragt werden kann. Und: Die Anleitung behandelt den recht weit verbreiteten IIS6. OK? Dann los!

GZip am IIS aktivieren

Öffnen Sie die IIS-Konsole (was z. B. hier in einem anderen Beitrag erklärt wird) und wählen Sie den „Knoten“ Websites, der direkt nach den FTP-Sites und Anwendungspools unter dem Icon für den lokalen Computer zu finden ist. Öffnen Sie nach einem Rechsklick auf den Knoten die Eigenschaften für Websites. Genau: Die folgende Einstellung betrifft alle Sites, die auf diesem Server bereitgestellt werden.  Öffnen Sie den Reiter „Dienst“.

Hier kann mit Aktivierung der Option „Statische Dateien komprimieren“ die Kompression (hier wiederum HTTP-„Komprimierung“ genannt…) für die meisten beteiligten Dateien eingeschaltet werden. Zu bedenken gibt es lediglich, dass dieser Vorgang Platz auf dem Server benötigt, weshalb hier auch ein temporäres Verzeichnis für die Kompressionvorgänge angegeben werden muss.

Hier kann theoretisch alles stehen, wenn man die Vorgabe nicht verwenden will. Entscheiden Sie sich für einen eigenen (neuen) Ordner, stellen Sie aber in den Eigenschaften des Ordners sicher, dass IUSR_{machinename} Schreibberechtigung in diesem Ordner hat, denn sonst wird zwar der Webserver nach wie vor korrekt arbeiten, aber die Kompression nicht gelingen. Sollte also nach der Konfiguration keine Verbesserung in den o. a. Werkzeugen zur Kontrolle angezeigt werden, ist hier einer der ersten Anlaufpunkte zur Fehlerbehebung. Mehr Hilfe liefert das Ereignisprotokoll des Servers.

Hat es hingegen funktioniert, sollte nach dem Bestätigen der Änderungen und einem Reset des Servers* die Analyse der Ladezeit einer von hier ausgelieferten Seite deutlich verbesserte Werte zeigen. In Page Speed zum Beispiel ist die Kompression in der Liste der Prüfungen nun wahrscheinlich bereits mit einem grünen Haken versehen… oder zumindest von rot auf gelb gewechselt.

* Wer auch die nächsten Schritte unten gehen will, kann sich den ersten Reset ersparen und auch den Rest der Konfiguration anpassen, bevor der Server entweder über die Konsole per iisreset auf der Kommandozeile neu gestartet wird.

Aber selbst dort, wo nun „alles im grünen Bereich“ ist, kann ggf. noch etwas herausgeholt werden. Außerdem sollten Sie sich nicht nur mit der Ladezeit der Startseite befassen, sondern auch andere (wesentliche) Inhalte Ihrer Website aufsuchen. Vor allem dort, wo statische Seiten mit dynamischen Inhalten gemischt sind, ein Shopsystem an ein CMS angedockt wurde oder auf andere Weise verschiedene Technologien oder Lösungen unterschiedlicher Anbieter gemixt sind, lohnt sich ein längerer Streifzug.

CSS + Scripte (und andere Dateitypen) ebenfalls komprimieren

Um bei umfangreichen Scriptsammlungen etc. auch hier die Kompression nutzen zu können, müssen Sie leider etwas tiefer in die Konfiguration des Servers eingreifen. Das kann für eine ganze Menge an Dateitypen sinnvoll sein… CSS und JavaScript sind aber die typischsten Kandidaten (und Sie sollten sich je nach Umfang hier parallel zur Kompression auch um eine Minimierung bemühen). Dazu muss die so genannte „Metabase“ des Servers manuell modifiziert werden. Mit anderen Worten: Es muss eine XML-Datei mit einem Texteditor bearbeitet werden. Dabei handelt es sich um die Datei „metabase.xml“ im Ordner „inetsrv“ unter System32 Ihrer Windowsinstallation.

Wenn Sie versuchen, diese mit Notepad zu öffnen, wird es allerdings i. d. R. zu einer Fehlermeldung kommen, weil zunächst die Bearbeitung der Metabase im laufenden Serverbetrieb explizit erlaubt werden muss. Das geht zum Glück wiederum per Knopfdruck und ohne irgendwelche Neustarts in den Eigenschaften des IIS-Dienstes.  Am Einfachsten geht dies über das Kontextmenü des Knotens für den lokalen Computer in der IIS-Konsole (oder entsprechend im Kontextmenü unter Start – Verwaltung – Computerverwaltung – Dienste und Anwendungen – Internetinformationsdienstemanager) und aktivieren Sie dort die entsprechende Option.

Nach einem Klick auf „OK“ sollte der Zugriff auf die o. a. XML-Datei nun ohne Fehlermeldungen möglich sein.

So geht es nun weiter:

• Suchen Sie den ersten Eintrag, der mit „<IIsCompressionScheme“ beginnt. Es gibt (mindestens) zwei davon; einen für deflate und einen für gzip. In beiden Bereichen müssen die hier beschriebenen Änderungen – in der gleichen Weise – durchgeführt werden.
• Der Wert unter HcScriptFileExtensions muss nun (bei beiden Einträgen) um die gewünschten Extensions (also z. B. css und js, aber auch ggf. aspx, php oder andere) erweitert werden. Das hier für die bestehenden Dateitypen verwendete Format ist auch für die hinzugefügten Extensions zu verwenden.
• Da Sie nun schon mal hier sind, sollten Sie auch den Wert für HcDynamicCompressionLevel großzügig anpassen und z. B. eine 9 eintragen – ebenfalls wieder in beiden Abschnitten. Der Maximalwert ist 10 – diesen sollten Sie aber nur verwenden, wenn Sie bereits mit Level 9 vergleichswerte ermittelt haben, denn nicht immer führt 10 zu wirklich schnelleren Ergebnissen und hier geht es ja um PageSpeed 😉

Der ganze Spaß sollte also nun z. B. so aussehen:

Speichern Sie die Änderungen, sperren Sie ggf. wieder die Bearbeitung der Metabase und dann ist es Zeit für den zweiten Neustart – oder den ersten, wenn Sie den Neustart nach der Aktivierung der Kompression ausgelassen haben. Eine Nachkontrolle mit PageSpeed oder dem Werkzeug Ihrer Wahl sollte nun keine Einträge mehr für die hinzugefügten Dateitypen zu finden sein.

Wer dann noch nicht genug hat, kann sich mit den zahlreichen anderen Optimierungsmöglichkeiten auseinandersetzen, die von den verschiedenen Werkzeugen aufgedeckt werden. Normalerweise wird sich aber jenseits von Kompression selten etwas finden, was einen ebenso „sichtbaren“ Effekt hat. Je nach CMS ist aber vielleicht auch das Caching von Inhalten ähnlich vielversprechend. Der Tipp lautet daher: Investieren Sie einfach ein wenig Zeit in die Analyse der Schwachstellen und suchen Sie nach schnellen Lösungen, denn als „Einhand-SEO“ haben Sie wahrscheinlich noch ein oder zwei andere Aufgaben zu erledigen, die potentiell auch einen größeren Effekt auf Rankings haben, als es (jedenfalls derzeit noch) die Optimierung der Ladezeit vermag.