Gzip: Pro und Kontra
13.01.2010 in: Browser, Suchmaschinen und Webdesign • 3 Kommentare
Letzte Änderung: 01.10.2010, 18:47 Uhr.
Die Firefox-Addons YSlow (Yahoo) und Page Speed (Google) helfen Webentwicklern, die Ladezeiten ihrer Seiten zu beschleunigen.
Sie arbeiten ihrer Natur nach sehr pauschal und empfehlen immer, alle textbasierten Webressourcen mit gzip zu komprimieren.
Gzip (GNU zip) komprimiert Textdateien sehr effizient. Das Format wird nicht durch Patente belastet, und die meisten Browser und Crawler können damit umgehen. Die meisten, nicht alle.
Wir können die komprimierte Variante einer Ressource nicht auf gut Glück verschicken, sondern nur, wenn der Empfänger dies bekannt gibt:
Request-Header:
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Das heißt: Wir müssen Content-Negotiation betreiben, über den Inhalt also mit dem Empfänger verhandeln – und eine unkomprimierte Variante vorhalten.
Spannend finde ich die Erkenntnisse, die Arvind Jain und Jason Glasgow zusammengefaßt haben: Anti-Virus-Software, Browser-Bugs, Webproxys und fehlkonfigurierte Webserver verhindern oft die Kompression.
Nehmen wir einmal an, Browser 1 verstehe gzip, Browser 2 nicht. Beide erreichen unsere Website über den selben Proxyserver. Browser 1 holt sich die gzip-Variante, der Proxy speichert diese und schickt sie später Browser 2. Obwohl der mit gzip nichts anzufangen weiß. Nicht so gut.
Also senden wir das Dokument mit einem Response-Header zurück, der den Proxy darüber informiert, wann er die Seite an einen anderen Browser ausliefern darf: Wenn der das gleiche Accept-Encoding vorlegt.
Response-Header:
Vary: Accept-Encoding
Der Vary-Header wurde erst in HTTP/1.1 eingeführt – also bekommen alle Anfragen, die per HTTP/1.0 einschlagen, immer die unkomprimierte Variante.
Jetzt kann der Internet Explorer (zumindest bis Version 6) die unkomprimierte Ressource überhaupt nicht mehr im Cache behalten, und die komprimierte landet auf jeden Fall darin. »Abhilfe« schafft ein weiterer
Response-Header:
Cache-Control: private
Und jetzt kann der Proxy die Ressource nicht mehr speichern.
Um das Thema »Internet Explorer« schnell hinter uns zu bringen, seien noch zwei Bugs erwähnt:
- Wenn ein XHTML-Dokument komprimiert und mit XML-Deklaration verschickt wird und überdies sehr lange oder viele Response-Header (Cookies beispielsweise) vorausgehen, dann versucht der Internet Explorer 6 in einigen Versionen, den MIME-Typen zu erraten. Er kommt dann zu dem Schluß, er habe XML vor der Nase – und scheitert kläglich.
- Wenn ein komprimiertes Dokument per SSL (HTTPS) angeboten wird, kann es auch passieren, daß der Leser gar nichts sieht.
Inzwischen hat sich die Situation jedoch gebessert.
Zu den Problemen beim Transfer und beim Caching stellt sich noch die Frage: Lohnt es sich?
Das Ein- und Auspacken kostet ja auch Zeit. Gerade bei Dokumenten, die erst bei Abruf komprimiert werden, müssen wir Faktoren berücksichtigen, die eventuell den Zeitgewinn ausstechen: die Serverlast und die Verarbeitungsdauer auf dem Server und beim Client.
Ein 3-kB-Dokument zu komprimieren, bringt überhaupt nichts. Bei 5 kB wird es langsam interessant, und ab 10 kB spürt der Leser den Unterschied.
Wir sollten beide Varianten statisch vorhalten, damit der Server nicht immer wieder dieselbe Arbeit erledigen muß. Hier fällt natürlich noch ein gewisser Koordinationsaufwand an.
Wann also komprimieren?
- Wenn die Ressource nicht unbedingt im Cache landen soll und/oder
- 5 kB überschreitet und
- der Server genug Kapazität dafür übrig hat oder beide Varianten fertig vorliegen.
Und wann nicht?
- Wenn die Ressource unbedingt in den Cache gelangen soll (Stylesheets in einem Webforum) und noch viele IE-6-Nutzer daherkommen oder
- der Server unter hoher Last steht oder
- das generierende Skript schon lange genug arbeitet.
Diese Hinweise bitte ich als grobe Richtlinien zu verstehen. Je nach Kontext können sie auch sehr danebenliegen. Per @font-face eingebettete Schriften will man ganz gewiß komprimieren – aber nur einmal verschicken. Hier lohnt sich ein Blick ins Logfile: Welche Browser benutzen meine Leser? Und dann trifft man eine informierte Entscheidung.
Ganz hakelig wird es, wenn komprimierte Inhalte im Internet Explorer 6 angezeigt werden sollen, die auch gecacht sind. Dann schert sich der IE 6 nicht darum, welche HTTP-Header für das Cache-Handling vorhanden sind und sendet immer wieder Requests.
Das Gleiche kann passieren, wenn der IE 6 per Javascript Elemente lädt, das Caching ist dabei fehlerhaft oder wird ignoriert.
Selbst eine Anpassung des Vary-Header bezüglich User-Agent bzw. Accept-Encoding brachte für den IE 6 keine Besserung.
Sowohl serverseitig Cache-Handling als auch Komprimierung bringen bei den alten IE seltsame Ergebnisse.
Und der IE 6 lebt weiter, in abgeänderter Form des Internet Explorer Mobile auf Windows Mobile.
Eine Lösung für den Apache fand ich bislang nicht.
Serverbetreiber müssen wohl damit Leben, dass die veralteten Versionen der IE merkwürdige Implementationen haben und sich um RFCs nicht scheren.
Dummerweise hat der IE 6 immer noch eine Verbreitung im Zehn-Prozent-Bereich, weil dieser in Windows XP vorhanden ist und dort selten ein per Hand angestoßenes Update erfährt.
Ich liebe WinRAR. Dieses Programm ist zwar kostenpflichtig, aber innerhalb von wenigen Tagen per CD in meinem Briefkasten. In Informatik haben wir heute eine Komprimierungstechnik kennengelernt, bei der Texte sehr stark kompromiert werden können. Das System funktionierte so, dass alle auftauchenden Buchstaben auf Anzahl überprüft wurden und so ein Wert erstellt wurde. Statt 100 Zeichen zum Beispiel hatte man dann nur einige wenige.
Lohnt Gzip Komprimierung?
Ich sehe das grundsätzlich erstmal aus Usersicht und da muss man es immer mit Ja beantworten, da es für den Anwender einfach einen Geschwindigkeitsvorteil liefert, auch heute noch bei guter Internetanbindung. Serverseitig habe ich selbst auf schwächeren Maschinen nie Problem mit der CPU Auslastung gesehen und mit Einzug von Multi-Core Prozessoren ist das selbst auf stark frequentierten Server zu vernachlässigen.
Gruss