Gzip-Komprimierung testen (Seite 2)

Die HTTP Compression ist sehr wohl ein Web Standard, auch wenn sie noch viel zu selten und vor allem häufig fehlerhaft eingesetzt wird.

Als Standard definiert ist sie im RFC 2616 ( www.ietf.org/rfc/rfc2616.txt ), der 1999 das HTTP 1.1 Protokoll festgeschrieben hat (bei Encoding).

tschersich schrieb:

Probleme gibt es bei Browsern und Proxies der letzten 3-4 Jahre damit nicht mehr.

17% sind mit dem IE 6 unterwegs und da gibt es Probleme.

tschersich schrieb:

Für ältere Browserversionen lassen sich in der Apache Config aber Ausnahmen definieren.

Ãœber 90% aller Domains befinden sich auf shared Webservern, also ist diese Methode absolut kein praktischer Standard, da auf diesen shared Webservern keinerlei Eingriff möglich ist.

tschersich schrieb:

Beim Seitenreport wird deshalb zu Recht table im Vergleich zu div abgestraft

Gleiche Logik wie bei dir - table ist ebenfalls definierter HTML Standard, auch wenn verpönt und in den meisten Fällen durch DIV ersetzbar.

tschersich schrieb:

Wenn meine reine HTML Seite durch Kompression z.B. statt 75KB nur noch 20KB groß ist, ist das (plus Overhead) das real übertragene Volumen.

Das Thema hat durch die inzwischen der Mehrheit zur Verfügung stehende Breitbandanbindung absolut an Bedeutung verloren.
Es ist ein Witz einer nicht sicher auf der Mehrzahl der Domains einsetzbaren Technologie hinterher zu laufen um durch Komprimierung ein paar Bytes an den Textdatene einzusparen, während heute hochauflösende Images und noch "schlimmer" Videos das Bild bestimmen. Bei deiner durchaus möglichen Beispielrechnung würde ohne Berücksichtigung der Zusatzzeit fürs Entkomprimieren bei mir eine Zeitersparnis von 0,00002 Sekunden heraus kommen, die ich an Transferzeit spare - interessiert niemanden.

tschersich schrieb:

Die Zeit für das Zippen und Entzippen ist dabei zu vernachlässigen, da es auf noch so betagten Servern und Client Rechnern nicht mal eine Millisekunde dauert.

Ein sehr guter shared Webserver hat 100 Domains gehostet und es sind durchaus andere Mengen von 1000 und mehr Domains pro Server möglich.

Man stelle sich einmal 100 x 0,001 oder 1000 x 0,001 vor, wenn jede Domain komprimieren würde oder wenn 100 oder 1000 Besucher gleichzeitig vorhanden sind.

Damit hat nun auch der letzte begriffen, warum Komprimierung zwar auf der einen Seite bestechend aber auf der anderen Seite nur Nachteile bringt.
Denn wenn es unterm Strich Vorteile bringen würde, dann hätten alle Provider es im Angebot da alle Seitenbesitzer darauf bestehen würden.

Auf die anderen Dinge wie bereits extrem starke Nutzung von internen Buffern von auf Templateengines basierenden Systemen oder Problemen mit bereits komprimierten Javascriptanwendungen wird natürlich nicht eingegangen.

Halten wir fest:

1. 17 % aller Leute sind mit dem IE6 unterwegs der Problem macht.

2.Ãœber 90% aller Domains haben keinerlei Möglichkeit das nutzen zu können.

3. Die reale Zeitersparnis ist völlig ohne Bedeutung

4. Der Zeitaufwand kann sich bei Servern je nach Betrieb so summieren das der Schuss nach hinten los geht.

5. Auf Templatengines basierenden Systemen bringt der finale gz_handler - Buffer reichlich Zeitverlust, ja kann sogar zur Nichtfunktion führen.

6.Es sind Probleme mit bereits komprimierten Anwendungen zu erwarten.

Unterm Strich wird kein Profianwender die Komprimierung verwenden um diese gewaltigen Probleme nicht wegen eines winzigen Vorteils zu haben, den die Besucher in der Masse wegen ihrer Highspeed .- Anbindung überhaupt nicht bemerken.

Die Vorteile gehen zudem auch noch vollständig flöten wenn eine Seite ein zweites mal besucht wird, da der Inhalt dann im Browsercache vorliegt.

Zunächst einmal wollte ich kein Dogma aufstellen, dass HTTP Compression das einzig wahre Mittel zur Erlangung der Glückseligkeit ist. Es gibt immer mehrere Wege zum Ziel und es ist (wiederholt bemerkt) richtig, dass das bei Shared Webhosting Paketen nicht angeboten wird, weil es je nach Kompressionsgrad die CPU Last der Apache Prozesse mehr als verdoppelt und Hosting Provider mit ihren Ressourcen knapp kalkulieren müssen, damit sie konkurrenzfähig bleiben.

Nichtsdestotrotz setzen viele große Firmen sie ein und sparen dadurch deutlich ausgehende Bandbreite, die sie bei ihrem Provider teuer bezahlen müssen und die reale Zeitersparnis ist mess- und spürbar, was in Tests auch nachgewiesen wird.

Für IE6 Benutzer und älter läßt sich - wie ebenfalls bereits erwähnt - die Kompression deaktivieren.

Aus dem Browser-Cache kommen nur Elemente, die bereits geladen wurden. Beim Erstbesuch auf einer Website ist das also nicht der Fall und bei jeder weiteren, neu aufgerufenen Seite werden nur CSS, globale Images und allenfalls globale Javascripts aus dem Cache geholt. Die Seite selbst muss übertragen werden und wenn ich das ein paar Prozent schneller hinbekomme als meine Mitbewerber auf dem Markt, habe ich einen kleinen Vorteil - keinen Meilensprung.

Um mal wieder auf die Messmethode hier bei Seitenreport zurückzukommen: Wenn z.B. meine CSS Datei eigentlich 50 Kilobyte groß ist, ich aber nur 15 Kilobyte über\'s Netz schicke, weil sie komprimiert wurde oder weil ich sie anders klein bekommen habe, dann sollten auch nur 15 Kilobyte angezeigt werden, denn das ist dann der reale Wert. Wie die 15 Kilobyte zustande gekommen sind, ist dann unerheblich.

tschersich schrieb:

Zunächst einmal wollte ich kein Dogma aufstellen, dass HTTP Compression das einzig wahre Mittel zur Erlangung der Glückseligkeit ist.

Das hat wohl auch jeder so verstanden, hier geht es um die Diskussion der Vor - und Nachteile.

Ich habe zumindest bei den deutschen Top 10 noch keine einzige Site gesehen die Komprimierung verwendet und die haben täglich zig tausende von Besuchern.

Ich kann mir lebhaft vorstellen, das offenbar die Nachteile dort überwiegen, ansonsten hätte man das ja wohl genutzt, denn ich gehe davon aus das dort Profis dahinter stecken.

Für mich gilt - was die Superprofis nicht nutzen kann für den normalen Profi auch nicht berauschend sein.

Was ein CMS betrifft kann ich das ziemlich gut beurteilen - garnicht mehr erst anbieten.

Ich habe eben mal bei Alexa.com die deutsche Top 10 und mit den Live HTTPHeaders die Encodings gecheckt.

Eigentlich setzt die gesamte deutsche Top 10 HTTP Komprimierung ein....

piratos schrieb:

17% sind mit dem IE 6 unterwegs und da gibt es Probleme.

An dieser Stelle sei mit in die Diskussion eingeworfen:

der IE Death March
http://iedeathmarch.org.

Wer weiß obs etwas bringt, die Aktion ist jedenfalls längst überfällig.

Seitenreport wird Nutzern des IE 6 demnächst ebenfalls zum Update auffordern und über Browser-Alternativen informieren. (eingebettet in die Verbesserungstipps für die Homepage).

HTTP Kompression / GZIP => So gehts:
http://www.seitenreport.de/forum/beitraege/webserver_konfiguration_und_sicherheit/http_compression_aber_richtig.html

tschersich schrieb:

Ich habe eben mal bei Alexa.com die deutsche Top 10 und mit den Live HTTPHeaders die Encodings gecheckt.

Eigentlich setzt die gesamte deutsche Top 10 HTTP Komprimierung ein....

Ich weiss ja nicht was du da getestet hast aber keiner verwendet dort Komprimierung.

Für mich ist der Einsatz der Komprimierung ein voll negativer Moment - die zahlreichen Gründe habe ich ja schon angeführt.

Hat jemand eine Komprimierung ist das für mich keine Aufwertung sondern eine glatte Abwertung.

Die angeführten Gründe sind handfest und absolut nicht entwertet worden.

Es kann auch nicht die Aufgabe einer Seitenbewertung sein die Anwender zur Nutzung einer aktuellen Browserversion zu bewegen
nu um ein Test in das richtige Licht zu rüclen.

Wenn das die Anbieter der Browser selbst nicht geschafft haben diese Gruppe zu einem Update zu bewegen, dann hat das wohl seine Gründe.

Ich glaube man kann sich in dem Punkt auch z.B. an seitwert orientieren - auch da ist das absolut kein Thema.

Wenn man lediglich zur Information anführt. das eine Seite Komprimierung anwendet dann ist das in Ordnung.

Fliesst das jedoch in ein Ergebnis ein, dann führt das für mich (und andere) zur Abwertung von Seitenreport selbst, denn dann taugt das Ergebnis nichts.

Ich schreibe nur mal exemplarisch für alle anderen dem 200er Returncode beim Aufruf von Google.de:

HTTP/1.x 200 OK
Cache-Control: private, max-age=0
Date: Tue, 05 May 2009 16:50:54 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
Content-Length: 2917

Der Rest der Top 10 hat das gleiche Muster.

Ich hatte ja auch lediglich vorgeschlagen, die real übertragene Dateigröße anzuzeigen. Ob sie durch Komprimierung oder durch ausgefuchstes Gebastel zustande gekommen ist, ist dann bei der Bewertung wurscht.

Die Argumente in diesem Gesprächsfaden wiederholen sich. Lasst uns das Thema beenden.

Ich ärgere mich etwas, dass ich die Diskussion verpasst habe. Die Argumente mit der Serverbelastung durch die Komprimierung sind vollkommen richtig, ebenso die Gegenüberstellung der Vorteile durch reduzierten Traffic.

Ich denke es muss für jeden speziellen Fall abgewogen werden, welche Strategie zu nutzen ist. Ich habe aber noch einen weiteren Aspekt der beachtet werden sollte. Und zwar bestehen heutzutage sehr viele Sites aus dynamischen Inhalten, wodurch die angedachte Komprimierung bei jedem Seitenaufruf durchzuführen ist und damit ad absurdum geführt wird. Man müsste dann für jede Seite festlegen können, ob komprimiert wird oder nicht. :haha:

Was aber jeder machen kann und das ist mit keinerlei Nachteil behaftet, ist das Entfernen von sinnlosem Content, wie Leerzeichen, Einzüge usw.. Dafür gibt es hier(http://www.denapp.com/de-DE/Services/Tools/HtmlShrink) ein kostenloses Tool, das HTML und CSS bereinigt. Da verschwindet mal locker ein viertel einer HTML Datei. Und diese verschwundenen Daten müssen nicht im RAM sein, nicht geladen werden, nicht kopiert werden, nicht ausgeliefert und nicht im Cache gehalten werden.

Find ich genial.

PS. Und falls komprimiert werden soll, müssen die verschwundenen Daten auch nicht komprimiert werden.

!!Achtung, die Originaldateien werden überschrieben!

Grüße

seitenreport schrieb:


Eine Abfrage über Seitenreport wird in absehbarer Zeit natürlich folgen und komprimierte Ãœbertragungen besser bewerten.

Wie schaut es aus, erfolgt schon die Abfrage gzip-Komprimierung?

Schalte ich die gzip-Komprimierung auf meiner Site ein, werden trotzdem noch die unkomprimierten Dateien für das Ranking einbezogen...

Gruß