HTTP Compression - aber richtig!

Gute Anleitung.

Was die Nutzung betrifft stossen wir immer wieder auf das gleiche Problem.

Weit über 90% aller Domains liegen auf shared Webserver.

An einen Zugriff in die httpd.conf ist nicht zu denken.

Und wegen der zusätzlichen benötigten Rechenleistung schalten die Provider das nicht freiwillig ein.

Ausserdem sind noch unglaublich viele Surfer mit IE6, ja sogar IE 5.5 unterwegs und da gibt es bekannterweise direkte Browserprobleme.

PHP seitig wird das über den Start eines Buffers mit dem gz_handler abgewickelt.

Systeme die z.B. eine Templateengine wie Smarty oder TPLE nutzen sind besser beraten den finalen Buffer weg fallen zu lassen, da intern bereits zig mal von Buffern Gebrauch gemacht wird.
Die Performance wird da unterm Strich schlechter und kann auch nicht besser werden wenn man zusätzlich komprimiert und wir reden da über richtige Werte und nicht über Kleinkram.

Und es gibt zahlreiche Javascriptanwendungen die bereits selbst komprimiert sind und auch da können sich empfindliche Probleme einstellen.

Unter Strich sind meiner Meinung die Nachteile für einen Seiteanbieter größer als die Vorteile, da man durchaus die Gefahr sehen muss das man allerhand Besucher aussperrt.

Da sich die Komprimierung zudem nur auf Texte bezieht und die haben einen relativ kleinen Anteil am Transfers darf man sich ruhig die grundsätzliche Frage nach dem Vorteil für alle stellen.

Da so manche mögliche Probleme auf der Besucherseite emtstehen können machen von der Komprimierung auch Siteanbieter regelmässig keinen Gebrauch davon, auch wenn sie es könnten.

Natürlich gibt es noch Surfer die mit Modem oder ISDN ans Netz gehen müssen, weil es keine anderen Möglichkeiten gab. Bis vor kurzem gehörte ich auch noch zu denjenigen die das mit ISDN machen mussten.

Allerdings bin ich nun mit echten 20 MBit online und da stellt man fest das die Netzanbindung einer Site selbst eine viel größere Rolle spielt, was einem vorher nicht aufgefallen ist.
Bei 2,5 MB pro Sekunde spielen die paar Bytes keine Rolle mehr, wenn aber ein Anbieter seine Inhalte mit netto 125 KB durch die Leitung drückt, dann liegt der "Ärger" ganz woanders.
Und das meiste sind Inhalte die in keinster Weise komprimierfähig sind.

Die Kompression zu nutzen kann nicht so falsch sein, wenn High-Traffic Websites wie google.de, amazon.de, de.wikipedia.org, tui.com, thomson.co.uk, firstchoice.co.uk oder www.vodafone.de (teilweise) sie einsetzen. Bei einem Teil der o.g. Websites war/bin ich selbst an dem Prozess beteiligt. Nicht überall wird die Kompression über die Apache Webserver selbst geregelt, sondern manchmal auch über sog. Load Balancer, die eigentlich die eingehende Last auf mehrere Webserver verteilen und mit der Kompression nur noch eine Zusatzfunktion übernehmen. Das Prinzip ist aber das gleiche.

Wer als Sitebetreiber Angst hat, damit Nutzer auszusperren, die noch mit IE 5.5 oder IE 6 surfen, dann definiert er die entsprechenden Ausnahmen in der Config und testet seine Site auch mit älteren Browsern durch.

Natürlich können die meisten Website Betreiber es wegen Shared Hosting nicht nutzen, aber deshalb kann es ja trotzdem eine gute Sache sein.

Die textbasierten Inhalte zu komprimieren, ist übrigens durchaus lohnenswert, denn seit ca. zwei Jahren werden wg. der Ajax Technologie wieder vermehrt Javascripts eingesetzt, die locker mal 50-100KB pro Datei haben und auch historisch gewachsene CSS Dateien werden gern mal so groß.

Natürlich macht die Kompression eine schlechte Serveranbindung oder eine total überladene Seite nicht völlig wett, aber wer als Betreiber die ausgehende Bandbreite um 25% drücken kann, kann auch mit einer nicht so dicken Leitung mehr Anfragen abarbeiten.

tschersich schrieb:

Natürlich macht die Kompression eine schlechte Serveranbindung oder eine total überladene Seite nicht völlig wett, aber wer als Betreiber die ausgehende Bandbreite um 25% drücken kann, kann auch mit einer nicht so dicken Leitung mehr Anfragen abarbeiten.

Das muss jeder selbst entscheiden, aktuell sind ca. 17% der Leute noch mit dem IE6 unterwegs und da gibt es ja die Probs.

Wenn an anderer Stelle hier 100ms als entscheidend für 1% Verlust zitiert dem wird klar sein, das man nicht gerne auf max. 17% verzichten wird.

Wenn ich mir so manche CMS oder Portalsysteme ansehe die bei 0,3 bis 0,5 Sekunden und manchmal auch noch mehr an Generierungszeit benötigen bevor sie überhaupt ein einziges Zeichen abliefern scheint mir die Verbesserung dort erheblich notwendiger zu sein, als nun über Komprimierung oder nicht zu reden.