tschersich
Themenersteller
IT-Berater, technischer Projektleiter Web / e-Commerce
Beginner (31 Beiträge)

HTTP Compression - aber richtig!

am 02.05.2009, 03:49 Uhr eröffnete tschersich folgenden Thread
Webserver, Rootserver, Linux-Server    6211 mal gelesen    3 Antwort(en).

Jeder moderne Browser unterstützt das komprimierte Ãœbertragen textbasierter Inhalte wie HTML, CSS und Javascript. Leider nutzen es die wenigsten Sitebetreiber. Wer sich mit dem Firefox Add-On Live HTTP Headers mal den HTTP Verkehr zwischen Browser und Server anschaut, wird immer feststellen, dass der Browser sogar fast dazu auffordert, Kompression zu nutzen:

Accept-Encoding: gzip,deflate

Um seinen Apache Webserver richtig zu konfigurieren, sollten folgende Einträge in die httpd.conf:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript

DeflateCompressionLevel 4

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch MSIE !no-gzip !gzip-only-text/html

Header append Vary User-Agent env=!dont-vary
</IfModule>

Vorher sollte natürlich mittels

LoadModule deflate_module modules/mod_deflate.so

das Kompressions-Modul "deflate" geladen sein.


http://www.zahaira.de


gelöschter Benutzer
am 02.05.2009, 10:17 Uhr schrieb

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.


tschersich
IT-Berater, technischer Projektleiter Web / e-Commerce
Beginner (31 Beiträge)
am 02.05.2009, 12:04 Uhr schrieb tschersich

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.


http://www.zahaira.de


gelöschter Benutzer
am 02.05.2009, 17:38 Uhr schrieb

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.


  • 1


« zurück zu: Webserver, Rootserver, Linux-Server

Das Seitenreport Forum hat aktuell 5274 Themen und 36115 Beiträge.
Insgesamt sind 48327 Mitglieder registriert.