JavaScript gzippen?

[nam]

Hallo Forum!

Bei einer Webanwendung habe ich ein ziemlich grosses JavaScript, welches auch durch kurze Namen und jsmin reduziert immer noch knapp 100kb "wiegt".

Durch zusätzliche Kompression mit mod_gzip komme ich auf nur 28kb, was eigentlich ganz ok ist.

Nun habe ich aber in einem guten Forum und auf einer guten Seite gelesen, dass es dabei zu Problemen kommen könne.

Sind diese Aussagen heute (2007) noch aktuell? Oder kann ich mod_gzip getrost verwenden? Gibt es Dinge zu beachten?

PS:
Ich verwende serverseitig folgendes am Anfang meiner jsDatei.php:

  
<?php  
 ob_start('ob_gzhandler');  
 header('Content-type: text/javascript; charset: UTF-8');  
 header('Cache-Control: public, must-revalidate');  
 $lzeit=604800; //=7*24*60*60  
 $exp='Expires: '.gmdate('D, d M Y H:i:s',time()+$lzeit).' GMT';  
 header($exp);  
?>  

Danke für eure fachkundigen Hinweise.
Mathias

[wahsaga]

hi,

Durch zusätzliche Kompression mit mod_gzip komme ich auf nur 28kb, was eigentlich ganz ok ist.

Na ja, auch 100KB wären doch keine so große Tragik, wenn ihr Inhalt "es Wert ist", und vernünftig gecached werden darf.

Nun habe ich aber in einem guten Forum und auf einer guten Seite gelesen, dass es dabei zu Problemen kommen könne.

Ich finde hauptsächlich Aussagen bezüglich Netscape 4.

Michael Schröpl verweist allerdings auch auf zwei Artikel von Microsoft bzgl. Problemen diesbezüglich im IE 5.5 und im IE 6.0.
Allerdings wird da nicht speziell auf Javascripte Bezug genommen, sondern das bringt ihn wohl unter gewissen Umständen generell bei über HTTP komprimiert ausgelieferten Ressourcen in Verdrückung.
Schau's dir mal an, wann das Problem auftreten könnte und unter welchen Umständen - und entscheide dann, ob dir diese gewichtig genug erscheinen oder sich eher unter "Einzelschicksale" verbuchen liessen.

Sind diese Aussagen heute (2007) noch aktuell?

Technisch rückständige Dinosaurier wird's immer geben - aber wegen denen sollte nicht bis in alle Ewigkeit der Fortschritt gebremst werden.

gruß,
wahsaga

[nam]

Danke für deine Antwort.

Ich finde hauptsächlich Aussagen bezüglich Netscape 4.

Darauf - das erlaub ich mir - nehm ich keine Rücksicht mehr.
Im SelfHTML-Artikel steht aber auch:

"Viele Contentfilter entfernen einfach den Accept-Encoding-Header."
Was sind "viele Contentfilter"? - Firewalls?

Und:
"Auch reagiert die Mehrzahl der Proxies allergisch auf den wegen der Komprimierung nötigen Vary-Header. Vary führt alle Header auf, von dem diese Variante des Requests abhängt. Älteren Versionen des HTTP-Proxies Squid schalten alle Formen des Cashings ab und fordern das Dokument bei jeder Anfrage neu an - für den Website-Betreiber kaum erstrebenswert."
Gibt es diese Probleme bei moderneren Proxies noch? Ich will ja gerade die Datenmenge klein halten und aggressiv cachen - wenn dann gar nichts gecacht wird...

[Christian Seiler]

Hallo nam,

"Viele Contentfilter entfernen einfach den Accept-Encoding-Header."
Was sind "viele Contentfilter"? - Firewalls?

Firewalls im Allgemeinen nicht, aber das, was einem Privatanwender so als Firewall verkauft wird hat sowas idR. mit dabei. Allerdings: Wenn der Accept-Encoding-Header entfernt wird, wird halt schlimmstenfalls unkomprimiert übertragen, allerdings funktioniert alles noch.

Und:
"Auch reagiert die Mehrzahl der Proxies allergisch auf den wegen der Komprimierung nötigen Vary-Header. Vary führt alle Header auf, von dem diese Variante des Requests abhängt. Älteren Versionen des HTTP-Proxies Squid schalten alle Formen des Cashings ab und fordern das Dokument bei jeder Anfrage neu an - für den Website-Betreiber kaum erstrebenswert."
Gibt es diese Probleme bei moderneren Proxies noch? Ich will ja gerade die Datenmenge klein halten und aggressiv cachen - wenn dann gar nichts gecacht wird...

Das waren damals schon ältere Versionen - und der Artikel hat auch schon einige Jahre auf dem Buckel. Aktuelle (und auch schon 3 Jahre alte) Squid-Versionen verstehen Vary; ich glaube kaum, dass *noch* ältere Versionen davon noch im Einsatz sind. Der einzige Proxy, bei dem ich es je erlebt habe, dass er Vary nicht kapiert, war der Novell BorderManager vor 2 Jahren (und zwar so, dass er ihn ignoriert). Der wird jedoch höchstens in Schul- und Firmennetzen eingesetzt und dort werden meistens die gleichen Browser mit den gleichen Einstellungen verwendet, so dass das Ignorieren des Vary-Headers in diesen Fällen kein Problem darstellt. Zumal es durchaus sein kann, dass aktuelle Versionen das Problem nicht mehr haben. Ferner: So viele Seiten verwenden heute zumindest für HTML-Inhalte gzip-Komprimierung, dass ein derart kaputter Proxy im Firmennetz schnell auffallen würde, daher glaube ich nicht, dass man auf solche Spezialkonstellationen Rücksicht nehmen muss.

Ich persönlich würde gzip-Komprimierung heutzutage bedenkenlos einsetzen - auch für JavaScript-Dateien. Bei SELFHTML lasse ich die JavaScript-Dateien ja auch komprimiert übetragen (schau Dir z.B. die Header von http://forum.de.selfhtml.org/forum.js an) - und wegen so etwas hat sich bis dato noch keiner beschwert.

Viele Grüße,
Christian

[Vinzenz Mai]

Hallo Christian,

Der einzige Proxy, bei dem ich es je erlebt habe, dass er Vary nicht kapiert, war der Novell BorderManager vor 2 Jahren (und zwar so, dass er ihn ignoriert). Der wird jedoch höchstens in Schul- und Firmennetzen eingesetzt und dort werden meistens die gleichen Browser mit den gleichen Einstellungen verwendet, so dass das Ignorieren des Vary-Headers in diesen Fällen kein Problem darstellt. Zumal es durchaus sein kann, dass aktuelle Versionen das Problem nicht mehr haben.

Ich persönlich würde gzip-Komprimierung heutzutage bedenkenlos einsetzen - auch für JavaScript-Dateien. Bei SELFHTML lasse ich die JavaScript-Dateien ja auch komprimiert übetragen (schau Dir z.B. die Header von http://forum.de.selfhtml.org/forum.js an) - und wegen so etwas hat sich bis dato noch keiner beschwert.

zumal mit Felix Riesterer jemand hier recht aktiv ist, der den BorderManager zumindest beruflich nutzen muss (bzw. im Jahr 2006 beruflich genutzt hat, um präzise zu sein). Felix hätte sicher nachgefragt.

Freundliche Grüße

Vinzenz

[Orlando]

Ich persönlich würde gzip-Komprimierung heutzutage bedenkenlos einsetzen - auch für JavaScript-Dateien.

Wie sieht es mit CSS aus, hat Firefox hiermit immer noch Probleme?

Roland

[Christian Seiler]

Hallo Roland,

Ich persönlich würde gzip-Komprimierung heutzutage bedenkenlos einsetzen - auch für JavaScript-Dateien.

Wie sieht es mit CSS aus, hat Firefox hiermit immer noch Probleme?

Mir wäre nicht bekannt, dass es da jemals Probleme gegeben hätte, das ist mir vollständig neu. Ich kann nur sagen, dass die aktuellen Stylesheets für's Forum komprimiert ausgeliefert werden und sich auch diesbezüglich noch keiner beschwert hat. Ferner: Ich nutze selbst Firefox und ich habe noch nichts diesbezüglich gemerkt.

Viele Grüße,
Christian

[Orlando]

gzip-Komprimierung

Wie sieht es mit CSS aus, hat Firefox hiermit immer noch Probleme?

Mir wäre nicht bekannt, dass es da jemals Probleme gegeben hätte, das ist mir vollständig neu.

Eine Suche im Ersatzgedächtnis ergab, dass das Problem ein anderes war. Ich zitiere aus der E-Mail:

| Wenn mein Client (sowohl IE als auch FF) einen "If-Modified-Since"
| Header sendet, schickt Dein Server nicht einen 304-Header als
| Antwort, sondern einen 200 - aber ohne Content!
|
| Im IE kommte man es mit einem Refresh auch hinbiegen, aber Firefox
| verzichtet bei einem Refresh wohl nur auf die konditionalen
| Caching-Header für die Resource in der Adresszeile.

Es ging dabei um Michaels gzip_cnc.

Ich kann nur sagen, dass die aktuellen Stylesheets für's Forum komprimiert ausgeliefert werden und sich auch diesbezüglich noch keiner beschwert hat.

Das bedeutet dann wohl grünes Licht.

Roland

[Christian Seiler]

Hallo Roland,

Eine Suche im Ersatzgedächtnis ergab, dass das Problem ein anderes war. Ich zitiere aus der E-Mail:

| Wenn mein Client (sowohl IE als auch FF) einen "If-Modified-Since"
| Header sendet, schickt Dein Server nicht einen 304-Header als
| Antwort, sondern einen 200 - aber ohne Content!
|
| Im IE kommte man es mit einem Refresh auch hinbiegen, aber Firefox
| verzichtet bei einem Refresh wohl nur auf die konditionalen
| Caching-Header für die Resource in der Adresszeile.

Es ging dabei um Michaels gzip_cnc.

Ja klar, das Teil hat halt offensichtlich in diesem Punkt nicht ganz dem HTTP-Standard entsprochen. Das ist aber nur ein Softwareproblem und kein Problem mit gzip-Komprimierung selbst; wenn die Implementierung HTTP korrekt genug umsetzt (mod_gzip und mod_deflate tun das), dann stört sich der Firefox keineswegs an gzip-komprimierten Stylesheets.

Viele Grüße,
Christian