Ladezeitenoptimierung: GZIP / CSS & JS Optimizer

groe

lo0l
ID: 134786
L
26 April 2006
224
16
Hi,

da ich immer wieder davon lese und mir Gedanken mache, es auch zu verwenden, wollte ich mal fragen, ob ihr Erfahrungen mit der GZip-Kompression von PHP habt, die sämtlichen Traffic, der so generiert wird erstmal komprimiert. Gibts da irgendwas zu beachten? Wie siehts mit der Kompatibilität und der Serverauslastung aus?

Außerdem wollte ich mich erkundigen, was ihr von CSS & JS Optimizern haltet, die einem zwar teils komplett die Lesbarkeit zerstören aber dafür doch die Größe stark reduzieren können (https://javascriptcompressor.com/, https://flumpcakes.co.uk/css/optimiser/, o.ä.). Die Lesbarkeit ist ja eig. irrelevant wenn nicht sogar erwünscht - man muss sich halt zusätzlich auch den Original Sourcecode aufheben und jedes mal vorm Releasen durch so nen Compressor laufen lassen. Aber sind die denn mit allen Browsern kompatibel - gibts da keine Probleme?

Danke schonmal.

LG groe
 
Stylesheets und JavaScripts ändern sich normalerweise nicht, d.h. werden vom Browser im Cache gehalten. Ich kann mir nicht vorstellen, dass solche "Optimierungen" sonderlich viel bringen.
 
Und gzip ist auch eher negativ. Heute haben die meisten eh DSL, da macht es gespürt kein unterschied ob man 10kb oder 15kb durch die Leitung jagt. Dafür frisst es bei jedem Auftruf zusätzlich Ressourcen und es gibt ein Punkt an dem genau das gegenteil vom gewünschten passiert, es wird lagsamer und das unter Umständen massiv. Also würde ich bei dynamischen Seiten eher die Finger von lassen.
 
Stylesheets und JavaScripts ändern sich normalerweise nicht, d.h. werden vom Browser im Cache gehalten. Ich kann mir nicht vorstellen, dass solche "Optimierungen" sonderlich viel bringen.
Ja es wird im cache gehalten, jedoch wird bei jedem request noch eine Anfrage an den Server gestellt ob die lokale Kopie der Datei noch aktuell ist, sprich du hast 12 Monate alte CSS-Files online, und trotzdem wird bei jedem Seitenaufruf vom Client nochmal gefragt ob die Datei aktuell ist, da würde dann ein Expires-Header mehr Sinn machen als ne gzip-Komprimierung, groe ;)

Und gzip ist auch eher negativ. Heute haben die meisten eh DSL, da macht es gespürt kein unterschied ob man 10kb oder 15kb durch die Leitung jagt. Dafür frisst es bei jedem Auftruf zusätzlich Ressourcen und es gibt ein Punkt an dem genau das gegenteil vom gewünschten passiert, es wird lagsamer und das unter Umständen massiv. Also würde ich bei dynamischen Seiten eher die Finger von lassen.
ja ich gebe dir teilweise Recht ;)
Aber bei statischen Inhalten und gerade in der heutigen Zeit bei großen JavaScript-Files (protoype, scriptacolus, dojo) macht dies doch deutlich Sinn.
Aber da kann man sich streiten, das gebe ich zu ;)
 
Ja es wird im cache gehalten, jedoch wird bei jedem request noch eine Anfrage an den Server gestellt ob die lokale Kopie der Datei noch aktuell ist, [...]
Der Traffic für einen Request plus anschließendem Auslesen der Kopfzeilen macht aber nicht viel aus.
 
Der Traffic für einen Request plus anschließendem Auslesen der Kopfzeilen macht aber nicht viel aus.

100% ACK, jedoch bedeutet es weniger Serverlast, wenn diese unnötige Anfrage an den Server erst gar net gestellt wird.
Was meinste wie sich das klamm-Forum hier freuen wird wenn es nicht für jeden Foren-Beitrag nochmal 50 (!!!) Anfragen bekommt und jedesmal antworten muss, hey, deine gecachte Datei ist noch aktuell.
Das sind 50 HTTP-Anfragen pro Seitenaufruf, ich habe eben mal die Dateien gezählt, das ist doch schon eine Menge.
 
100% ACK, jedoch bedeutet es weniger Serverlast, wenn diese unnötige Anfrage an den Server erst gar net gestellt wird.
Schon klar, aber das ist ja hier keine Alternative.

Die Frage war, ob diese Optimierer was bringen und die setzen ja noch weiter hinten an und optimieren die Größe, wenn die Datei ständig komplett gezogen werden muss. Im Gegensatz dazu ist 50x Nachfragen mit 304 als Antwort allemal besser.

Du hast aber natürlich Recht, dass das Optimum ist, wenn der Client erst gar nicht fragt.
 
Aber bei statischen Inhalten und gerade in der heutigen Zeit bei großen JavaScript-Files (protoype, scriptacolus, dojo) macht dies doch deutlich Sinn.
Aber da kann man sich streiten, das gebe ich zu ;)

Nein da bin ich einer meinung mit dir. Ich hab nicht ohne grund dynmaische Seiten geschreiben. Ich bin bloss nicht weiter drauf eingegangen, weil ich nicht weiß wie man das am sinnvollsten realisieren soll... im idealfall müssten die gzip Version gecacht werden.

ice-breaker schrieb:
Was meinste wie sich das klamm-Forum hier freuen wird wenn es nicht für jeden Foren-Beitrag nochmal 50 (!!!) Anfragen bekommt und jedesmal antworten muss, hey, deine gecachte Datei ist noch aktuell.
Da gibts optimierungs potenziall ;) Yahoo hat da mal was schönes gemacht... die haben eine handvoll Icons in einen Datei gepackt und dann mittels CSS ausgegeben. Schon allein bei 10 Icons spart man sich bei jedem Aufruf 9 Requests und das eigentliche Anzeigen der Seite im Browser geht auch schneller. Würde sich für ein Teil der Board Grafiken bestimmt auch gut eignen...
 
Da gibts optimierungs potenziall ;) Yahoo hat da mal was schönes gemacht... die haben eine handvoll Icons in einen Datei gepackt und dann mittels CSS ausgegeben. Schon allein bei 10 Icons spart man sich bei jedem Aufruf 9 Requests und das eigentliche Anzeigen der Seite im Browser geht auch schneller. Würde sich für ein Teil der Board Grafiken bestimmt auch gut eignen...


Sowas habe ich auch schon mal gesehen, aber noch nicht gesehen wie das genau geht. Naja hatte mir das auch nciht so genau angeguckt...
 
Ihr meint sowas ?

edit:
Billy's Browser scheint mal wieder nix damit anfangen zu können :LOL:
 
Okay, scheint wohl wirklich das geringste auszumachen, das runterladen der Files. Mir war allerdings das GZip-Prinzip neu und luke meinte auch, er verwendet es, wenn ich mich nicht irre.

Mehrere Icons in einem File kenn ich z.B. auch von MySpace: Die verwenden da wohl eine Grafik und zeigen aber per CSS immer nur einen Teil von an.
 
Mir war allerdings das GZip-Prinzip neu und luke meinte auch, er verwendet es, wenn ich mich nicht irre.
Jupp, tut er:
Response Headers - https://www.klamm.de/for.......2618893 schrieb:
Date: Sat, 19 Jan 2008 16:48:08 GMT
Server: Apache
Cache-Control: private
Pragma: private
Keep-Alive: timeout=10, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=ISO-8859-1
Content-Encoding: gzip
Content-Length: 22447

200 OK
Mehrere Icons in einem File kenn ich z.B. auch von MySpace: Die verwenden da wohl eine Grafik und zeigen aber per CSS immer nur einen Teil von an.
Das is ja clever.
 
Da gibts optimierungs potenziall ;) Yahoo hat da mal was schönes gemacht... die haben eine handvoll Icons in einen Datei gepackt und dann mittels CSS ausgegeben. Schon allein bei 10 Icons spart man sich bei jedem Aufruf 9 Requests und das eigentliche Anzeigen der Seite im Browser geht auch schneller. Würde sich für ein Teil der Board Grafiken bestimmt auch gut eignen...

Jup ich muss sagen, Yahoo macht da wirklich momentan sehr viel, haben bei mir sehr viel Ansehen gewonnen.
Von den Mitarbeitern da das MySQL-Optimierungsbuch bei O'Reilly, dann Webseitenoptimierung im Frontend wo sie YSlow für gebastelt haben, ja, die sind schon top.
 
na einfach per background-position verschieben. ;)
da ja die grafiken meist als background-image genutzt werden.

nutze ich bei www.klammlinks.de bei den links wenn man mit der maus drüber geht. ;) der pfeil vorne drann ...
 
Über JS? Das wird in CSS mittels :hoover gemacht ;)
Der Browser lädt aber nicht vor.

Dieser Effekt is z.B. auf meiner Webseite zu beobachten, dass die Hover-Grafik nicht sofort da is, wenn der Mauszeiger drüber is.

Dieser Verschiebetrick mit nur einer Grafik würde das verhindern, da die Grafik zu diesem Zeitpunkt schon geladen is.