Gzip-Komprimierung testen

ich stell mir gerade die weinenden 56k modem user vor, wobei .... bei denen hilft eh nix mehr im zeitalter von web2.0 XD

UAHHHHHHHHHHH wir brauchen noch mehr blogs am besten mit Bildern, schärfer als das Habel-teleskop xD

naja wenn du willst das man sich schnell drum kümmert schreib nen bugreport. bei mir wurde das am nächsten tag geklärt, kann mich nich beklagen

lg Daniel

Davon halte ich nichts.

Es gibt reichlich Server die das nicht zulassen.

Dann müsste man logisch auch die Anbindung der zu testenden Domain checken.

Bei einer Highspeedverbindung ins Netz macht sich eine langsame Anbindung eines Servers stark bemerkbar und zwar erheblich stärker als eine gzip Komprimierung. von Inhalten.

Und dann müsste man noch weiter gehen, denn man könnte dann auch sagen checked css und javascript caching.

Mir ist noch kein Hoster begegnet, der ein Problem damit gehabt hätte, dass ich per Komprimierung Traffic sparen möchte.

Besser, schneller und ökologisch sinnvoll ist die komprimierte Datenübertragung ohne Zweifel. Nichts desto trotz ist es kein Beinbruch, wenn der Seitenreport das nicht prüft...

UsualRedAnt schrieb:

Mir ist noch kein Hoster begegnet, der ein Problem damit gehabt hätte, dass ich per Komprimierung Traffic sparen möchte.

Oh doch jede Menge. Wenn der Server das unterstützt ok, aber das ist keine Sache einer Bewertung, da nicht Standard.

UsualRedAnt schrieb:

Mir ist noch kein Hoster begegnet, der ein Problem damit gehabt hätte, dass ich per Komprimierung Traffic sparen möchte.

Freenet, aber die bringen eh nischt auf de reihe :evil:

Ich halte eine komprimierte Ãœbertragung von Webseiten ebenfalls für sinnvoll. Komprimierte Ãœbertragungen benötigen nur etwa 1/3 des ursprünglichen Datenvolumens.

Vorteile der Komprimierung sind z.B.:
(1) Kürzere Ladezeiten für den Seitenbesucher
(2) Geringerer Traffic für den Seitenbetreiber

So gehts:
Am Anfang eines PHP-Skriptes, z.B. oben in der Datei index.php folgende Anweisung einfügen:

<?php
ob_start("ob_gzhandler");
?>

Nachteile:
Sehr alte Browser unterstützen die Komprimierung nicht. Per

<?php
$pruf = getenv("HTTP_ACCEPT_ENCODING");
?>

sollte man hier den Browser testen und die Webseite bei Nicht-Unterstützung unkomprimiert übertragen.

Falls vereinzelte Webhoster, derartige (gängige) GZIP Komprimierungen nicht anbieten, stellt sich natürlich die Frage ob hier deren Konfiguration von PHP auch in anderen Bereichen im Argen liegt => ggf. Anbieter wechseln.

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

Es geht nicht darum ob komprimiert gut oder schlecht ist oder etwas bringt.

Zig tausende von Domains auf shared Webservern können das nicht weil der Provider wegen Serverbelastung (denn der müsste komprimieren) das nicht zur Verfügung stellen.

Es ist keineswegs Standard.

Und es müsste zlib zur Verfügung stehen und zlib.output_compression eingeschaltet sein, das wäre noch etwas dazu.

Das aber ist bei einer Apache - PHP - Standardinstallation nicht vorgesehen.

Habe ich den gzhandler in der Nutzung können andere Dinge nicht verwendet werden.

You cannot use both "mb_output_handler" with "ob_iconv_handler"and you cannot use both "ob_gzhandler" and "zlib.output_compression".

Ich sehe da keinen Sinn drin das testen zu wollen.

Und eine Empfehlung deswegen den Provider zu wecheseln würde ich auch niemals geben.

Ich habe diesbezüglich einschlägige Erfahrungen mit Usern die solche Problem hatten und habe deswegen sogar diese Möglichkeit gezielt aus meiner CMS entfernt.

piratos schrieb:
Es geht nicht darum ob komprimiert gut oder schlecht ist oder etwas bringt.

Doch - genau darum geht es. Sonst könnte man genauso den Check auf den Doctype unterlassen und sagen - "es gibt doch so viele Leute, die HTML4.01 transitional verwenden"

Das Ziel des Seitenreports sollte es aus meiner Sicht sein "gewünschtes Verhalten von Webseiten und Webmastern zu fördern". Und dazu gehört neben validem XHTML und CSS eben auch das Angebot den Nutzer mit komprimierten Daten zu versorgen.

piratos schrieb:
Ich habe diesbezüglich einschlägige Erfahrungen mit Usern die solche Problem hatten und habe deswegen sogar diese Möglichkeit gezielt aus meiner CMS entfernt.

Das klingt für mich ein wenig nach - ich will nicht, dass meine "Kunden" durch den Seitenreport darauf aufmerksam gemacht werden, dass meinem CMS ein Feature fehlt

UsualRedAnt schrieb:

Das klingt für mich ein wenig nach - ich will nicht, dass meine "Kunden" durch den Seitenreport darauf aufmerksam gemacht werden, dass meinem CMS ein Feature fehlt

Das ist wohl ein Witz, diese paar Kümmerzeilen (die oben gepostet wäre noch nicht einmal ausreichend für einen sicheren Ablauf auf allen Servern).

Es fehlte nicht, es wurde entnommen, weil die Masse der Server das überhaupt nicht anbietet.
[color=grey]Anmerkung von Seitenreport: Gemeint ist hier die Komprimierung der Webseitenübertragung per GZIP.[/color]

Die Provider bieten es nicht an, weil die Arbeit vom Webserver übernommen werden müsste.
Bei shared Webservern würde das alle belasten und unterm Strich rein nichts bringen.

Und nicht umsonst ist es in der Standardinstallation von Apache und Co grundsätzlich nicht enthalten.

Und was nicht Standard ist muss nicht getestet werden - nun begriffen ?


Auf Providersite ist es sinnvoller memcache einzusetzen, das bringt erheblich mehr, wird aber genau aus den gleichen Gründen nie angeboten, da RAM intensiv - geht nur als Dienst auf einem eigenen Server.

Es wäre vielleicht sinnvoller festzustellen mit wie vielen Domains man sich einen Server teilt, je exklusiver desto fixer und besser.

piratos schrieb:
Das ist wohl ein Witz, diese paar Kümmerzeilen (die oben gepostet wäre noch nicht einmal ausreichend für einen sicheren Ablauf auf allen Servern).

Hab ich etwa den vergessen? Nix für ungut. Ich kenne Dein CMS ja nichteinmal und wollte es mit meiner Äußerung daher auch nicht werten.