nicht angemeldet
Hi Stefan,
Selbst wenn der Browser also lediglich prüfen
würde, ob die in seinem Cache vorliegende Datei
aktuell ist, würde das schon mehr kosten, als
den CSS-Code immer wieder komprimiert zu
übertragen!
*ähem* wir sprechen hier nicht von einer einzelnen
Datei, sondern von einer Website. Selbst wenn man
es niedrig ansetzt, wird sich ein Besucher wohl
schon drei Seiten anschauen und da wird dann genau
einmal die CSS-Datei angefordert.
Je nachdem, wie sein Browser konfiguriert ist.
Soll heißen, umso mehr HTML-Dateien vom Besucher
angefordert werden, die diese CSS-Datei
referenzieren, umso größer wird der Vorteil dieser
Lösung.
Das ist richtig.
Dazu kommt noch, dass eventuell nur ein 304 an den
Browser geschickt wird, wenn sie die CSS-Datei nicht
verändert hat.
Und genau dieser angebliche 0-Byte-Request mit HTTP-
Status 304 ist bereits _größer_ als die komprimierte
Auslieferung des CSS-Codes!
Wenn also jemand 10 Seiten abruft, die ein und
diesselbe CSS-Datei einbinden, so werden später
genau 11 Einträge im Logfile stehen.
Oder 20, von denen 11 den Status 200 und 9 den Status
304 haben.
Und es ist _unmöglich_, den Fall der nur 11 Einträge
zu haben, ohne den Browser gezielt von der Prüfung des
Cache-Inhaltes abzuhalten! Dies geht nur
a) durch Browser-Konfiguration "check never" bzw.
"check once per session" oder
b) durch Browser-Konfiguration "automatic" _und_
Senden von HTTP-Headern mit Aufbewahrungfrist
der Datei innerhalb des Cache, was so gut wie
niemand tut. (Außer gzip_cnc, beispielsweise. ;-)
Es kann natürlich sein, dass in Einzelfällen
Browser so eigenartig konfiguriert sind, dass sie
zehnmal die CSS-Datei anfordern, aber der Normalfall
ist sowas nicht ;-)
Doch, das ist der Normalfall!
Deshalb hat das Self-Portal ja 40% (!) HTTP-304-Requests:
http://webalizer.teamone.de/selfhtml/usage_200205.htm
Meine eigene Domain, bei der ich aggressiv Expires-
Header sende, hat 'nur' 10-15% 304er-Responses.
Im konkreten Fall ist natürlich noch zu
berücksichtigen, dass Du einzelne CSS-Dateien
unkomprimiert auslieferst, während CSS direkt
in HTML-Dateien mit komprimiert wird.
Daß selbst 304er-Requests größer sind als eine gut
komprimierte eingebundene CSS-Datei, habe ich ja
bereits dargelegt. Bei einer CSS-Datei von 300 Bytes
ist der 304er-Request bereits um Faktor 10 schlechter!
Und erkläre mir bitte, wie Du guten Gewissens CSS-
Dateien separat komprimiert ausliefern willst, solange
die Browser-Implementierungen in diesem Falle derartig
fehlerhaft sind. Die Kröte machst Du damit beispiels-
weise nicht glücklich ...
Allgemein dürfte die Trennung von HTML- und CSS-
Dateien weniger Traffic verursachen.
Ich behaupte nach wie vor das Gegenteil.
Wenn Du diese Behauptung pauschal aufstellst,
dann ist sie falsch.
Nicht falscher als Deine. ;-)
weiter oben beschrieben. Auf
http://de.selfhtml.org/
beispielsweise schauen die meisten Besucher
etliche HTML-Seiten an, da wäre es grober Unfug,
die CSS-Definitionen jedesmal einzeln mit
reinzuschreiben.
Eine externe CSS-Datei, die in fast allen Fällen
genau einmal während eines Besuches angefordert
und geladen wird, ist da sinnvoller.
Ja, aber sie wird eben tatsächlich in sehr vielen
Fällen immer wieder angefordert. Und schon sehr wenige
Fälle würden das Gleichgewicht kippen lassen, denn
eine 300-Bytes-CSS-Datei kostet bei explizitem Zugriff
einfach dreizehnmal so viel wie bei komprimierter Mit-
Auslieferung.
Deine Besucher konfigurieren ihre Browser einfach
nicht optimal - und ob Du Expires-Header sendest, das
ist ja auch erst noch die Frage.
solange man keine Frames verwendet (ich suche nach
wie vor nach einer sinnvollen Anwendungsmöglichkeit,
wo sie auch die bessere Alternative gegenüber einer
Noframes-Lösung darstellen),
Du darfst gerne www.schroepl.net mit seinen über 1000
Dokumenten auf eine frames-lose Variante umschreiben,
die bitte schön ohne SSI funktionieren sollte ...
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael