nicht angemeldet
Hi Kai,
Server ohne mod_gzip gibt es bei mir nicht,
wir mußten es letzte Woche für einen Virtual Host
abschalten, weil dem Kunden Drucken mit Netscape 4
wichtiger war als Faktor 3 an Traffic ... ;-(
wer mich bittet einen Apache zu installieren, kriegt
das Teil gleich mit - man wird es spätestens, wenn
man dann für denjenigen die Website testen soll
selber genießen :)
Mit oder ohne "Vary:"-Header?
http://www.schroepl.net/_download/mod_gzip-1.3.19.1b.zip - sei nett zu den Proxies ...
.js -> Script auch für Netscape 4
.dom -> Script läuft eh in Netscape 4 nicht und geht auch gleich durch mod_gzip.
Ah - sehr praktisch.
Muß ich glatt mal bei uns im Büro vorschlagen.
Ob soetwas auch für CSS-Dateien Sinn macht weiß ich
nicht, diese haben nicht so oft endlose Reihen von
fast identischen Anweisungen - zumindest bei mir
beginnt 1/3 der Zeilen mit 'document.getElement'.
Rechne mal durch, ob Du den Kleinkram nicht besser
serverseitig includen willst. Je kleiner die Datei
und je schlechter die Konfiguration der Browser der
Besucher, desto besser ist das Includen.
Dann kannst Du alles komprimieren (auch für Netscape 4,
siehe aber oben) und HTTP-Zugriffe sparen.
an der Page
Da gilt zunächst einmal, dass man redundante Angaben
vermeiden sollte.
Wenn Du Seiten gzip-komprimiert auslieferst, machen
viele Redundanzen nur noch sehr wenig aus (der kom-
primiert auch seeeehr lange Strings nach Ähnlichkeit
auf 1 Byte herunter).
Große CSS-Dateien mit sich ständig wiederholenden
langen Attributnamen müßten davon stark profitieren.
unnütze Datei - auch darüber CSS-Dateien über SSI
gleuch in der Datei einzuarbeiten kann man normal
nachdenken,
Ich mache gute Erfahrungen damit.
bei meinen üblichen CSS-Dateien ist daran aber nur
zu denken, wenn die Datei kombrimiert rausgehen
(2KB sind bei mir Untergrenze, derzeit arbeite ich
an einer für eine Mozilla-Distribution, wo mich auch
10KB nicht wundern würden ;)
Wenn man die Benutzer erziehen könnte, ihre Browser
auf kooperatives Caching einzustellen ... gerade bei
stabilen CSS-Dateien darfst Du Expires-Header senden,
welche die Datei auf Tage oder Wochen im Browser-Cache
festnageln würden, ohne sinnlose 304-Requests ... ein
paar Tage vor dem nächsten Groß-Release schaltet man
diese Header dann vorübergehend ab, um die Caches zu
"säubern".
Grundsätzlich ich jede Datei zu vermeiden, die nicht
unbedingt nötig ist (man denke an die berüchtigten
Tipps große Bilder zu zerstückeln *schauder*)
Yep.
Auch interessant ist der Unterschied zwischen
http://seite/ordner und http://seite/ordner/ - wer
derartige URLs öfter durch den Validator jagt kennt
die Meldung - das erstere Redirected auch das zweite
-> auch hier kann also (wenn auch nur minimal) zeit
eingespart werden
So etwas findet bei mir der Links-Checker (Xenu), der
auf meinem PC über die gesamte Site drüber läuft, bevor
ich größere Änderungen hochlade.
Wiederum Entlastung des Browsers ist, wenn man
Bildern eine Größe gibt. Zwar sind heutige Broser
hier nicht mehr so problematisch, dass sie mit der
darstellung warten, bis die Grafik da ist,
allerdings beschleunigt ein nötiger Reflow das ganze
auch nicht gerade...
Das findet bei mir der in meinem Editor integrierte
CSE-Validator. Von dessen ca. 150 Prüf-Funktionen
habe ich nur ganz wenige abgeschaltet ...
Viele Grüße
Michael