Website zu langsam ?

[player2000]

Hi,
ich wollte hier im Forum mal fragen, ob ihr meine website (www.sgd-dresden.de) zu langsam findet und was ich vor allem verbessern könnte (also gesehn an der Ladezeit) ? Wäre es ratsamer, die gesamte Page ins PHP zu übersetzen ? Würde das die Ladezeit verküzen ?

Danke schonmal

[Fabian Transchel]

Hallo player2000,

ich wollte hier im Forum mal fragen, ob ihr meine website (www.sgd-dresden.de) zu langsam findet und was ich vor allem verbessern könnte (also gesehn an der Ladezeit) ? Wäre es ratsamer, die gesamte Page ins PHP zu übersetzen ? Würde das die Ladezeit verküzen ?

Bitte tu dir (und allen anderen, die dich hier lesen) etwas gutes und schau dir die </faq/> an.

Zu deiner Frage: Ich (DSL) finde, die Seite ist im gelben Bereich, da ich ca. 6 Sekunden warten musste, bis die ersten _Inhalte_ erkennbar waren. Für Analog- und ISDN-User ist das allerdings allermeistens schon zu viel.

Die Seite liegt auf einem T-Online-Server, somit ist die Ladezeit daran gemessen top. (Ein anderer Server ist natürlich u.U. schneller.)

Verstehe was PHP tut, dann weißt du, dass PHP nichts mit der Größe der Seite zu tun hat, und auch nicht damit, wie schnell diese durch das Netz ausgeliefert wird.

Grüße aus Barsinghausen,
Fabian

[player2000]

Ich danke erstmal allen, ja, das es vor allem an den bildern liegt war mir so gut wie klar, nur wie bekomm ich die bilder in eine geeignete Größe ? also kennt jemand ein gutes komprimiererprogramm ?
ich hab das zur zeit immer mit photoshop gemacht, aber da wird die qualität ziemlich mieß und trotzdem sind die bilder eigermaßen groß.

Ach ja, könnte mir dann auch gleich jemand sagen, wo ich einen schnelleren server als t-online finde ? Danke.

[Michael Schröpl]

Hi player2000,

wie bekomm ich die bilder in eine geeignete Größe ? also kennt jemand ein gutes komprimiererprogramm ?

das liegt nicht am Programm - es liegt an der Qualität der Bilder.

JPEG ist eine verlustbehaftete Komprimierung. Aber Du kannst Dir an dieser Stelle Verlust leisten.
Lade Dein Hintergrundbild mal mit einem beliebigen Graphikprogramm (ich würde PaintShop Pro nehmen), speichere es mit verschiedenen Komprimierungswerten ab und vergleiche, ob bzw. wie sehr die Qualität nachläßt. Meine Schätzung: Du wirst mit weniger als 10 KB noch zufrieden sein.

Wieso ist "pauli.gif" kein JPEG? Solche Farbübergänge kriegst Du mit GIF nie sinnvoll hin. Allerdings würde ich dieser Graphik auch generell keinen Hintergrund geben - so etwas müßtest Du mit Deinem Hintergrundbild alleine lösen und hier nur noch die nichttransparenten Teile drüber legen.
Anschließend darfst Du noch darüber nachdenken, ob 256 Farben sein müssen oder ob 16 nicht auch reichen (bei meinem Konvertierungsversuch litt das Aussehen beträchtlich, anscheinend weil Du so viele ähnliche Gelbtöne verwendet hast - vielleicht wäre ein erneutes Einscannen mit nur 16 Farben sinnvoller?); auch ein Versuch, diese Datei als PNG abzuspeichern, könnte sich lohnen (das Bild wurde bei mir 20% kleiner).

"naechstes.gif" wäre mit 16 Farben nur ein Drittel so groß wie bisher, ohne deutlich schlechter auszusehen; PNG bringt hier allerdings nichts mehr zusätzlich.

Viele Grüße
      Michael

[rainer groth]

Hallo player2000,

...also kennt jemand ein gutes komprimiererprogramm ?
ich hab das zur zeit immer mit photoshop gemacht, aber da wird die qualität ziemlich mieß und trotzdem sind die bilder eigermaßen groß.

1. Adobe Photoshop (PS) ist IMHO eine vorzuegliche Wahl fuer den Print-Bereich (dort ist Adobe gross geworden) und fuers Screendesign - um Grafiken fuers WWW zu optimieren, taugt es IMO nicht.

Mit dieser Meinung stehe ich nicht alleine - u.a. deshalb gibt es mit Photoshop (AFAIK seit Version 6.0) Adobe ImageReady (IR) dazu, ein Produkt, dass zur 'Web-Optimierung' entwickelt wurde.

Hinweis:
IR laesst sich z.B. aus PS ueber den Menuepunkt 'Datei'-'Fuer Web speichern' aufrufen...
dort laesst sich in der '2fach'- bzw. '4-fach'-Ansicht Original und optimierte Version vergleichen etc.
Wichtig: verschiedene Einstellungen versuchen.
Weiterer Tipp: RTFM, also in der Online-Hilfe nachschauen :-)

2. Direkt fuer den Online-Bereich (also ohne Druckvorstufen-Alleskoenner) gibt es von Macromedia (ja, das sind die mit Dreamweaver und Flash) Fireworks (FW).

Mit FW sollen und koennen Grafiken fuers WWW erstellt und optimiert werden (natives Dateiformat ist uebrigens .png).

3. Adobe-Produkte kosten (viele) Euros - Macomedia-Produkte kosten (viele) Euros). Welche Produktlinie verwendet wird, wird davon abhaengen, mit welcher GUI man/frau gewohnt ist, zu arbeiten.

4. Es gibt unzaehlige Produkte, die mindestens so gut wie IR oder FW in der Lage sind, Webgrafik-Formate zu erzeugen - darunter auch sehr kostenguenstige (z.B. GIMP).

5. Fuer eine wirkliche 'Web-Optimierung' (also: Verringerung der Datenmenge ohne sichtbare Qualitaetsverluste), wird es IMHO IMMER noetig sein, 'Spezialisten' einzuspannen - also Produkte, die dies (und meistens NUR dies) gut koennen.

Mein persoenlicher Favorit ist seit laengerem der 'ImageOptimizer' von http://www.xat.com/ - ich gehe aber davon aus, dass es noch etliche aehnliche Produkte gibt, die aehnliches leisten...

gruesse
rainer groth

[Michael Schröpl]

Hi player2000,

ich wollte hier im Forum mal fragen, ob ihr meine website (www.sgd-dresden.de) zu langsam findet und was ich vor allem verbessern könnte (also gesehn an der Ladezeit) ?

Opera 7 zählt beim Laden der Startseite über 120 KB (und produziert zu allem Überfluß auch noch einen JavaScript-Fehler). Kein Wunder bei einer Seite, die praktisch nur aus zwei Bildern besteht.

Wäre es ratsamer, die gesamte Page ins PHP zu übersetzen ? Würde das die Ladezeit verküzen?

Wenn die Ausgabe der entsprechenden PHP-Skripte identisch ist mit den bereits existierenden HTML-Seiten, dann wäre die Übertragungsdauer beider (identischer) Dokumentgruppen (inklusive identischer HTTP-Header - dies wird bei der PHP-Lösung sogar schlechter, wenn Du nicht entsprechend gegensteuerst) natürlich auch identisch. Zusätzlich jedoch würde eine dynamische Berechnung dieser Ausgaben Deinen Server belasten und damit die Auslieferung _aller_ Seiten (etwas) verlangsamen.

Allerdings ist dieser Teil der Analyse de facto irrelevant. Deine Bilder erschlagen alles - überlege Dir, wie Du diesen Anteil des Traffic möglichst gering halten kannst. (Insbesondere beim Hintergrundbild darfst Du mit der Qualität drastisch herunter gehen, ohne daß dies dem Betrachter sonderlich auffallen wird - da ist ein Faktor von 10 oder mehr durchaus noch drin.)

Zu Feinkeiten wie caching-freundlichen HTTP-Headern oder komprimierter Seitenübertragung können wir immer noch kommen, sobald der Modem-Benutzer die Ladedauer Deiner Startseite ertragen kann ... (also bei Faktor 4-5 weniger als bisher)

Viele Grüße
      Michael

[rainer groth]

Hallo,

Seitengrösse insgesamt (in Bytes): 9628
Theoretische Ladezeit bei Modem 28.8 kps (in Sek.): 2.67
Theoretische Ladezeit bei ISDN 64 kps (in Sek.): 1.20
(Quelle: http://de.webmasterplan.com/ - Ladezeit-Check)

IMHO solltet Ihr ueberlegen, mit einigen Euros werbefreien (!) Webspace anzumieten.

gruesse
rainer groth

[Heiner]

Hallo,

Die lange Ladezeit liegt an der Frametechnologie. Die erzeugt einen unnötig hohen Overhead, da zig Dateien geladen werden muss, jede ins Internetprotokoll verpackt. Ich schlage Dir vor auf Frames ganz zu verzichten. Frames haben sicher ihre Anwendungen, bei gestaltungslastigen Seiten ist es aber fraglich, ob sie da sinnvoll sind.

Du kannst das ganze auch tabellarisch aufbauen, etwa mit div oder table-Elementen (wobei letzteres unter Webgestaltern als unelegant empfunden wird).

Teste Deine Seiten immer auch mit dem w3c-Validator: http://validator.w3.org/.

PHP dürfte an der Geschwindigkeit nix ändern, höchstens zu Deinen Ungunsten, wenn Du einen langsamen Wirtrechner hast.

Grüße
Heiner

[Fabian Transchel]

Hallo Heiner,

Die lange Ladezeit liegt an der Frametechnologie. Die erzeugt einen unnötig hohen Overhead, da zig Dateien geladen werden muss, jede ins Internetprotokoll verpackt. Ich schlage Dir vor auf Frames ganz zu verzichten. Frames haben sicher ihre Anwendungen, bei gestaltungslastigen Seiten ist es aber fraglich, ob sie da sinnvoll sind.

Was ist ein Internetprotokoll?

Du kannst das ganze auch tabellarisch aufbauen, etwa mit div oder table-Elementen (wobei letzteres unter Webgestaltern als unelegant empfunden wird).

Och nö *g* Bitte keine Diskussion jetzt...

Teste Deine Seiten immer auch mit dem w3c-Validator: http://validator.w3.org/.

PHP dürfte an der Geschwindigkeit nix ändern, höchstens zu Deinen Ungunsten, wenn Du einen langsamen Wirtrechner hast.

Ist das der Angriff der Germanisten? Wirtrechner habe ich nie gehört ;-)
(Ja, ich kann mir wohl denken, was du meinst...)

Grüße aus Barsinghausen,
Fabian

[Heiner]

Was ist ein Internetprotokoll?

Mal was von TCP/IP gehört (-:

[Andreas Korthaus]

Hi Fabian!

Was ist ein Internetprotokoll?

Solltest Du eigentlich wissen: http://www.google.de/search?q=Internetprotokoll *SCNR*, im Prinzip ist die Aussage auch nicht ganz falsch, naja, im Prinzip, vielleicht ein wenig mit den Protokollen durcheinander gekommen ;-)

Du kannst das ganze auch tabellarisch aufbauen, etwa mit div oder table-Elementen (wobei letzteres unter Webgestaltern als unelegant empfunden wird).

Und die erzeugen keinen "Overhead"? Hast aber insofer Recht dass durch Frames mehr HTTP-Request notwendig werden, was sich auch beim Caching bemerkbar macht.

Teste Deine Seiten immer auch mit dem w3c-Validator: http://validator.w3.org/.

Das ist ein guter Vorschlag!

PHP dürfte an der Geschwindigkeit nix ändern, höchstens zu Deinen Ungunsten, wenn Du einen langsamen Wirtrechner hast.

Ist das der Angriff der Germanisten? Wirtrechner habe ich nie gehört ;-)

Nicht? Hm, naja, ich auch nicht ;-)

Naja wie schon gesagt wurde, das Problem sind die Bilder, alleine die 3 größten Bilder haben zusammen über 130 KB. Wie lange es bei einem Modem mit 5 KB/Sekunde dauert  kann man ja ggfs. unter Zuhilfenahme eines Taschenrechners herausbekommen ;-)

Grüße
Andreas

[Heiner]

vielleicht ein wenig mit den Protokollen durcheinander gekommen ;-)

Inwiefern? TCP/IP -> IP=Internetprotokoll!

Und die erzeugen keinen "Overhead"? Hast aber insofer Recht dass durch Frames mehr HTTP-Request notwendig werden, was sich auch beim Caching bemerkbar macht.

Je mehr Dokumente angefordert werden müssen, desto größer wird auch der Verwaltungsaufwand für das Protokoll.

Heiner

[Andreas Korthaus]

Hi!

vielleicht ein wenig mit den Protokollen durcheinander gekommen ;-)

Inwiefern? TCP/IP -> IP=Internetprotokoll!

Du hast zwar auch Recht, es entsteht zusätzlicher Overhead auch durch IP, aber der HTTP-Overhead fällt im allghemeinen erheblich mehr ins Gewicht. Außerdem kann man nicht so einfach sagen, dass bei einer Aufteilung in Frames pro Frame und Frameset je ein IP-Paket mehr geschickt wird, da diese Pakete in Ihrer Größe begrenzt sind, und so kann es sein dass wenn die Daten alle in einer Datei stehen fast genauso viele IP-Pakete erzeugt werden müssen - mal so rein theoretisch. Außerdem werden die IP-Pakete normalerweise noch fragmentiert, bei DSL(bei pppoE) darf ein Paket z.B. nur maximal ca. 1500 Byte lang sein, d.h. am Ende zählt der IP Overhead fast nichts mehr, es kommt nur auf die zu übermittelnde Datenmenge an, da jedes Fragment soweiso mit einem kompletten IP-Header versehen wird. Der HTTP-Header eines Requests hat im Gegensatz zu 20 Byte eines IP oder auch TCP-Headers z.B. bei einem standardmäßig konfigurierte Mozilla mal schnell 400-500 Bytes, dazu kommt noch der Response-Header des Webservers. Das dumme dabei ist, die Internetseite einmal runtergeladen ist und sich im Cache des Browsers befindet, dann kann der Server bei einem Request des Browsers mit einen 304 Response Code antworten, was soviel bedeutet wie "Seite nicht geändert", und der Browser holt sich die Datei aus dem eigenen Cache. Nur wenn der Browser sich die Datei aus dem Cache holt, wird (normalerweise) pro Recource ein Request fällig, bei einer einzigen HTML-Seite mit z.B. 2 Bildern und einer Javascript-Datei 4 Requests, dasselbe in einem Frameset mit 5 Frames sind das mindestens 5 Requests mehr. Außerdem werden die Requests normalerweise nacheinander und nicht nebeneinander ausgeführt, also dauert das auch entsprechend länger.

Je mehr Dokumente angefordert werden müssen, desto größer wird auch der Verwaltungsaufwand für das Protokoll.

Ja, aber vor allem für das HTTP-Protokoll.

Viele Grüße
Andreas

[Michael Schröpl]

Hallo Andreas,

Das dumme dabei ist, die Internetseite einmal runtergeladen ist und sich im Cache des Browsers befindet, dann kann der Server bei einem Request des Browsers mit einen 304 Response Code antworten, was soviel bedeutet wie "Seite nicht geändert", und der Browser holt sich die Datei aus dem eigenen Cache.

viel sinnvoller ist es, wenn der Browser überhaupt nicht fragt, sondern die Seite sofort aus dem Cache holt. Denn bei einer Graphik von z. B. 20 Bytes ein Frage-Antwort-Spiel von fast 1000 Bytes abzuwickeln, ob diese Graphik übertragen werden soll oder nicht, das kann's nicht sein - dessen sind aber viele Webmaster gar nicht bewußt.
Nur: Dafür müssen beide Seiten arbeiten (der Server die richtigen HTTP-Header mitsenden, und der Browser so konfiguriert sein, daß er diesen glaubt - letzteres ist immerhin teilweise der Defaultwert).

Außerdem werden die Requests normalerweise nacheinander und nicht nebeneinander ausgeführt

Das ist abhängig vom Browser - bei Opera ist es sogar konfigurierbar. 4 parallele Requests sollte ein vernünftiger Browser aber schaffen.

Viele Grüße
      Michael

[Andreas Korthaus]

Hi Michael!

viel sinnvoller ist es, wenn der Browser überhaupt nicht fragt, sondern die Seite sofort aus dem Cache holt.

Ja, klar! Ich habe das aber noch nicht gemacht, und dafür braucht man AFAIK auch noch das Apache-Module mod_expires, oder? Außerdem - was wenn Du eine Datei dann dochmal geändert hast? OK, man könnte die HTML-Seite nicht vom Browser cachen lassen, und in diesem Fall zur Not den Link... einfach ändern. Denn die Gefahr besteht ja durchaus, dass das man bevor der Browser wieder das Dokument neu anfordert, bereits was wicjziges ändern möchte, einen fatalen Fehler korrigiren will... daher würde ich HTML wohl grundsätzlich nicht cachen lassen. Anders natürlich bei Javascripten, Grafiken, CSS...

Denn bei einer Graphik von z. B. 20 Bytes ein Frage-Antwort-Spiel von fast 1000 Bytes abzuwickeln, ob diese Graphik übertragen werden soll oder nicht, das kann's nicht sein.

Nur: Dafür müssen beide Seiten arbeiten (der Server die richtigen HTTP-Header mitsenden, und der Browser so konfiguriert sein, daß er diesen glaubt - letzteres ist immerhin teilweise der Defaultwert).

Außerdem werden die Requests normalerweise nacheinander und nicht nebeneinander ausgeführt

Das ist abhängig vom Browser - bei Opera ist es sogar konfigurierbar. 4 parallele Requests sollte ein vernünftiger Browser aber schaffen.

Ich meinte damit eigentlich das "chunking" was - wenn ich das richtig verstanden habe - bedeitet, dass der Browser die Pakete nicht nacheinander abfragt und in der Richtigen Reihenfolge empfängt, sondern dass die Daten parallel  ggfs. auch in falscher Reihenfolge gesendet werden, nur kann das nicht jeder Server, wenn ich das z.B. mit Mozilla bei google anstelle, bekomme ich da immer einen ziemlich bunten Seitensalat zurück ;-)

Grüße
Andreas

[Michael Schröpl]

Hi Andreas Korthaus,

Ja, klar! Ich habe das aber noch nicht gemacht, und dafür braucht man AFAIK auch noch das Apache-Module mod_expires, oder?

wenn Du HTTP/1.0 unterstützen willst (und statische Seiten auslieferst, also keine Skripte hast, die ihre Header selbst erzeugen), dann ja. Für HTTP/1.1 mit "Cache-Control" mußt Du nicht mit dem Datum herum rechnen - da würde schon mod_headers reichen.

Außerdem - was wenn Du eine Datei dann dochmal geändert hast?

Den Charakter seiner Seiten muß man natürlich schon verstehen.
Ich habe für Bilder sehr viel höhere Caching-Perioden eingestellt als für HTML-Seiten; und vor einem Releasewechsel unserer Serverfarm schalte ich diese Caching-Unterstützung in der Tat ein paar Tage lang ab, um die Caches unterer Kunden zu "säubern".

Denn die Gefahr besteht ja durchaus, dass das man bevor der Browser wieder das Dokument neu anfordert, bereits was wicjziges ändern möchte, einen fatalen Fehler korrigiren will... daher würde ich HTML wohl grundsätzlich nicht cachen lassen.

Das Forum hier läßt sogar seine Hauptdatei 60 Sekunden lang cachen - man muß halt wissen, was man tun will.

Außerdem werden die Requests normalerweise nacheinander und nicht nebeneinander ausgeführt
Das ist abhängig vom Browser - bei Opera ist es sogar konfigurierbar. 4 parallele Requests sollte ein vernünftiger Browser aber schaffen.
Ich meinte damit eigentlich das "chunking" was - wenn ich das richtig verstanden habe - bedeitet, dass der Browser die Pakete nicht nacheinander abfragt und in der Richtigen Reihenfolge empfängt, sondern dass die Daten parallel ggfs. auch in falscher Reihenfolge gesendet werden

Hm - da kenne ich mich auch nicht wirklich aus. Mein Wissensstand ist, daß man Chunking wohl vor allem dann braucht, wenn man die Ausgabe derartig inkrementell erzeugt, daß man zu Beginn der Ausgabe eben noch nicht weiß, welche "Content-Length" man in den HTTP-Header hätte schreiben müssen. HTTP enthält halt keine Klammerstruktur, mit welcher der Sender dem Empfänger mitteilen kann, daß das Paket fertig ist; entweder macht man so etwas über die Content-Length, oder eben darüber, daß der Client mit chunks fertig werden können muß.

nur kann das nicht jeder Server, wenn ich das z.B. mit Mozilla bei google anstelle, bekomme ich da immer einen ziemlich bunten Seitensalat zurück ;-)

Ups - jetzt weiß ich gar nicht, was Du meinst. Vielleicht bist Du gerade beim Thema "persistente Übertragung" (keep-alive)? Das ist wieder ganz was anderes (mehrere HTTP-Requests innerhalb einer TCP/IP-Verbindung) und würde zu Deiner Thematik viel besser passen ...

Viele Grüße
      Michael

[Andreas Korthaus]

Hallo Michael!

wenn Du HTTP/1.0 unterstützen willst (und statische Seiten auslieferst, also keine Skripte hast, die ihre Header selbst erzeugen), dann ja. Für HTTP/1.1 mit "Cache-Control" mußt Du nicht mit dem Datum herum rechnen - da würde schon mod_headers reichen.

Hm. HTTP/1.1, welche Clients können das nicht? Die 4er? Aber mit <meta> Tags im Dokument hjat das doch nicht viel Sinn, oder würdest Du denen bzw. den Browsern bzgl. dessen Befolgung genauso vertrauen wie HTTP-Headern?

Außerdem - was wenn Du eine Datei dann dochmal geändert hast?

Den Charakter seiner Seiten muß man natürlich schon verstehen.
Ich habe für Bilder sehr viel höhere Caching-Perioden eingestellt als für HTML-Seiten; und vor einem Releasewechsel unserer Serverfarm schalte ich diese Caching-Unterstützung in der Tat ein paar Tage lang ab, um die Caches unterer Kunden zu "säubern".

Mein "Problem", ich habe keine festen HTML-Seiten, sondern das ganze ist _sehr_ dymanisch. Auf manchen Seite ändert sich die Ausgabe bei jedem Reload, und bei anderen kann sie sich zumindest jederzeit ändern. Das ist mir zu riskant, das werde ich wohl lieber nicht cachen. Anders ist es wie gesagt bei Grafiken, Javascripten und CSS.
Und da lässt sich bestimmte ne ganze Menge machen, teilweise habe ich 4 Javascript-Links, 2 CSS-Links und unzählige kleine Grafiken auf der  Seite(btw. - wenn ein Recourcenname in einer HTML-Datei mehrmals vorkommt wird doch nur _ein_ Request gestartet, oder?), jedemnfalls ist hier sicher viel Potential!

Kann ich eigentlich auch bestimmte Javascript-Dateien vom Caching ausnehmen, wenn ich das serverseitig konfiguriere?

Denn die Gefahr besteht ja durchaus, dass das man bevor der Browser wieder das Dokument neu anfordert, bereits was wichtiges ändern möchte, einen fatalen Fehler korrigiren will... daher würde ich HTML wohl grundsätzlich nicht cachen lassen.

Das Forum hier läßt sogar seine Hauptdatei 60 Sekunden lang cachen - man muß halt wissen, was man tun will.

Ist das immer noch so? Ne Zeit lang hatte man das gemerkt, im MOment merke ich davon nichts! Wenn ich einen Beitrag poste uidn sofort danach die Hauptseite aufrufe gibt es da nie eien Verzögerung, also sind entweder meien Caching-Einstellungen nicht korrekt, oder es gibt  keine Header, aber das lässt sich ja kontrollieren... Aha, zumindest im /-Bereich gibt es die Header noch. Komisch...

Ich meinte damit eigentlich das "chunking" was - wenn ich das richtig verstanden habe - bedeitet, dass der Browser die Pakete nicht nacheinander abfragt und in der Richtigen Reihenfolge empfängt, sondern dass die Daten parallel ggfs. auch in falscher Reihenfolge gesendet werden

Hm - da kenne ich mich auch nicht wirklich aus. Mein Wissensstand ist, daß man Chunking wohl vor allem dann braucht, wenn man die Ausgabe derartig inkrementell erzeugt, daß man zu Beginn der Ausgabe eben noch nicht weiß, welche "Content-Length" man in den HTTP-Header hätte schreiben müssen. HTTP enthält halt keine Klammerstruktur, mit welcher der Sender dem Empfänger mitteilen kann, daß das Paket fertig ist; entweder macht man so etwas über die Content-Length, oder eben darüber, daß der Client mit chunks fertig werden können muß.

Ich muss gestehen ich habe es vergessen wie das genau funktioniert hatte, und leider kann ich das mit meinem Mozilla Firebird auch nicht  mehr einstellen. Es gab da aber definitiv 2 Einstellmöglichkeiten, einmal keep-alive, und einmal "chunked Irgendwas". Ich bin anscheinend auch etwas zu blöd mal ne anständige Dokumentation zu Mozilla online zu finden.

nur kann das nicht jeder Server, wenn ich das z.B. mit Mozilla bei google anstelle, bekomme ich da immer einen ziemlich bunten Seitensalat zurück ;-)

Ups - jetzt weiß ich gar nicht, was Du meinst. Vielleicht bist Du gerade beim Thema "persistente Übertragung" (keep-alive)? Das ist wieder ganz was anderes (mehrere HTTP-Requests innerhalb einer TCP/IP-Verbindung) und würde zu Deiner Thematik viel besser passen ...

Das kenne ich und das meine ich sicher nicht. Es ging glaueb ich grob darum, dass ohne chunked encoding nach einem Request imme rgewartet wird, bis die Anwort vollständig da ist, bei chunked encoding ist das egal, da kann nach dem ersten Request sofort der nächste gestartet werden, ohne warten zu müssen dass eine Antwort auf den ersten eingegangen ist. Dafür wird es jetzt schwieriger die Antworten des Servers zuzuprdnen, dass müssen Server und Client unterstützen. Zumindest so in die Richtung ging das, ich habe es mal eingeschaltet weil ich es eigentlich effektiv fand, aber leider haben dann einige Seiten wie Google eben verrückt gespielt, die Bilder waren z.B. total verzerrt oder ganz komisch.... da hat dann irgendwas nicht so gfeklappt wie es sollte. Vielleicht ist es auch ein Mozilla-Problem gewesen.

Aber zu einem anderen Thema, was hier vielleicht auch ganz gut hinpasst. Wie oben beschrieben sind alle HTML-Seite dymanisch, also die Ausgabe von PHP-Scripten. Hier verwende ich eien globale Einstellung das jede Ausgabe von PHP gzip-komprimiert ausgegeben wird. Was jetzt aber nicht komprimiert wird, sind die Javascripte(die teilweise auch etwas größer sind), und die CSS-Dateien. Wie komprimiere ich diese jetzt am besten? Oft werden die eh nicht verändert, die Frage ist, ob es Sinn macht mod_gzip zu installieren, obwohl ich es nur für die Verhältnismäßig wenigen Dateien brauche. 2 Variante wäre mit Content-Negotiation zu arbeiten, d.h. ich erstelle manuell auch ...js.gz und ...css.gz Dateien, die ich dann mit "options multiview" in der httpd.conf des Apachen entsprechend ausgeben lasse. Noch eine Variante wäre es, die Komprimierung der HTML-Ausgabe der PHP-Scripte nicht PHP, sondern mod_gzip zu überlassen, was haltet Ihr davon? Eigentlich wäre das ja nicht nötig, also müsste der Weg mit PHP und kpl. ohne mod_gzip der effektivere sein, oder?

Viele Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Aber mit <meta> Tags im Dokument hjat das doch nicht viel Sinn, oder würdest Du denen bzw. den Browsern bzgl. dessen Befolgung genauso vertrauen wie HTTP-Headern?

nein, würde ich nicht. Ein Proxy-Server ist kein Browser und wird HTML-Dokumente nicht parsen.

Mein "Problem", ich habe keine festen HTML-Seiten, sondern das ganze ist _sehr_ dymanisch. Auf manchen Seite ändert sich die Ausgabe bei jedem Reload, und bei anderen kann sie sich zumindest jederzeit ändern. Das ist mir zu riskant, das werde ich wohl lieber nicht cachen. Anders ist es wie gesagt bei Grafiken, Javascripten und CSS.

Meine Expires-Definitionen sind sehr spezifisch pro MIME-Type. Für HTML liegen sie eher im Stundenbereich, für Graphiken eher im Bereich von Wochen ...

Und da lässt sich bestimmte ne ganze Menge machen, teilweise habe ich 4 Javascript-Links, 2 CSS-Links und unzählige kleine Grafiken auf der  Seite

Hast Du mal durchgerechnet, ob es sich rechnet, das Zeug einzubinden und komprimiert auszuliefern?

btw. - wenn ein Recourcenname in einer HTML-Datei mehrmals vorkommt wird doch nur _ein_ Request gestartet, oder?)

Hm ... das wird wohl auf den Browser ankommen. Es wäre zu hoffen, daß dieser selbst bei paralleler Anforderung der Ressourcen nichts doppelt abholt.

Kann ich eigentlich auch bestimmte Javascript-Dateien vom Caching ausnehmen, wenn ich das serverseitig konfiguriere?

Natürlich. (<FilesMatch> etc.)

Denn die Gefahr besteht ja durchaus, dass das man bevor der Browser wieder das Dokument neu anfordert, bereits was wichtiges ändern möchte, einen fatalen Fehler korrigiren will... daher würde ich HTML wohl grundsätzlich nicht cachen lassen.
Das Forum hier läßt sogar seine Hauptdatei 60 Sekunden lang cachen - man muß halt wissen, was man tun will.
Ist das immer noch so?

HTTP response headers received from server:
[ 17] HTTP/1.1 200 OK
[ 16] Server: Apache
[ 35] Cache-Control: public, max-age=60
[ 37] Date: Mon, 28 Jul 2003 09:19:00 GMT
[ 40] Expires: Mon, 28 Jul 2003 09:20:00 GMT
[ 46] Last-Modified: Mon, 28 Jul 2003 09:16:41 GMT
[ 19] Connection: close
[ 45] Content-Type: text/html; charset=ISO-8859-1
[ 26] X-Pad: avoid browser bug
[  2]

Ich muss gestehen ich habe es vergessen wie das genau funktioniert hatte, und leider kann ich das mit meinem Mozilla Firebird auch nicht  mehr einstellen. Es gab da aber definitiv 2 Einstellmöglichkeiten, einmal keep-alive, und einmal "chunked Irgendwas". Ich bin anscheinend auch etwas zu blöd mal ne anständige Dokumentation zu Mozilla online zu finden.

Ich kann mir nicht vorstellen, daß es Sinn macht, chunking im Browser einzustellen. Apache verwendet das bei SSI und CGI!

Das kenne ich und das meine ich sicher nicht. Es ging glaueb ich grob darum, dass ohne chunked encoding nach einem Request imme rgewartet wird, bis die Anwort vollständig da ist, bei chunked encoding ist das egal, da kann nach dem ersten Request sofort der nächste gestartet werden, ohne warten zu müssen dass eine Antwort auf den ersten eingegangen ist.

Der Browser stellt doch sowieso parallele Requests, und die meisten davon werden nicht "chunked" beantwortet werden. Also ist "warten" die absolute Ausnahme.

Was jetzt aber nicht komprimiert wird, sind die Javascripte(die teilweise auch etwas größer sind), und die CSS-Dateien. Wie komprimiere ich diese jetzt am besten?
Oft werden die eh nicht verändert, die Frage ist, ob es Sinn macht mod_gzip zu installieren, obwohl ich es nur für die Verhältnismäßig wenigen Dateien brauche.

Wie oben schon erwähnt: Rechne durch, ob es besser ist, das Zeug in PHP zu includen und dann gleich mit zu komprimieren, oder ob Du den separaten Caching-effekt haben willst.
Das Problem bei der Berechnung ist, daß Du Annahmen über die durchschnittliche Caching-Strategie Deiner Besucher brauchst - diese erhältst Du aus der HTTP304-Quote Deiner Zugriffe, _nachdem_ Du alles mit optimalen Expires-Headern versorgt hast ... je niedriger dieser Quote ist, um so besser ist Caching gegenüber Include+gzip.

2 Variante wäre mit Content-Negotiation zu arbeiten, d.h. ich erstelle manuell auch ...js.gz und ...css.gz Dateien, die ich dann mit "options multiview" in der httpd.conf des Apachen entsprechend ausgeben lasse.

Das ist halt aufwändig zu pflegen. (Es sei denn ... siehe unten.)

Noch eine Variante wäre es, die Komprimierung der HTML-Ausgabe der PHP-Scripte nicht PHP, sondern mod_gzip zu überlassen, was haltet Ihr davon?

mod_gzip 1.3.26.1a beherrscht _beide_ von Dir vorher beschriebenen Methoden und könnte Dir die statischen *.gz-Dateien automatisch herstellen und aktualisieren ... (Christians Implementierung!)

Eigentlich wäre das ja nicht nötig, also müsste der Weg mit PHP und kpl. ohne mod_gzip der effektivere sein, oder?

Es gibt schon Gründe für die Existenz von mod_gzip - trotz mod_deflate 2.0 ...

Viele Grüße
      Michael

[Andreas Korthaus]

Hi!

Meine Expires-Definitionen sind sehr spezifisch pro MIME-Type. Für HTML liegen sie eher im Stundenbereich, für Graphiken eher im Bereich von Wochen ...

mangels mod_expires habe ich mal den Apachen (jetzt 1.3.28) neu übersetzt mit dem Modul, ich brauchte nämlich auch noch ein paar andere Dinge.

Jetzt habe ich folgende Einstellungen:

ExpiresByType image/jpeg "access plus 14 days"
    ExpiresByType image/gif "access plus 14 days"
    ExpiresByType application/x-javascript "access plus 7 days"
    ExpiresByType text/css "access plus 7 days"

Das mal als erstes. Ich denke ich mache CSS noch kürzer, vielleicht Bilder noch länger.

Was anderes habe ich nicht, wie gesagt ist der HTML-Output von PHP komplett dynamisch. Aber es ist wirklich unglaublich was sich dadurch die Geschwindigkeit verändert,ich spare mit 10-20 Requests pro Seite! Nur das erste mal dauert es länger als früher.

Hast Du mal durchgerechnet, ob es sich rechnet, das Zeug einzubinden und komprimiert auszuliefern?

Das wäre natürlich eien interessante Alternative. Denn beim Komprimieren von JS... bekomme ich Probleme mit älteren Browsern. Oder kann ich abhängig vom Browser(ich weiß...) z.B. beim Netscape 4 verhindern dass der die Komprimierte Version des Javascriptes bekommt?

Die Sache ist nur, dass ich es eigentlich gar nicht so oft brauche, d.h. wenn es eh nur einmal die Woche runtergelanden wird ist das sicher der schnellste Weg, nur wie gesagt, das einmalige Laden dauert ein bisschen länger.

Kann ich eigentlich auch bestimmte Javascript-Dateien vom Caching ausnehmen, wenn ich das serverseitig konfiguriere?

Natürlich. (<FilesMatch> etc.)

Ah ja! Danke!

Was jetzt aber nicht komprimiert wird, sind die Javascripte(die teilweise auch etwas größer sind), und die CSS-Dateien. Wie komprimiere ich diese jetzt am besten?
Oft werden die eh nicht verändert, die Frage ist, ob es Sinn macht mod_gzip zu installieren, obwohl ich es nur für die Verhältnismäßig wenigen Dateien brauche.

Wie oben schon erwähnt: Rechne durch, ob es besser ist, das Zeug in PHP zu includen und dann gleich mit zu komprimieren, oder ob Du den separaten Caching-effekt haben willst.

Gut wäre sowohl komprimiert als auch gecached!

Das Problem bei der Berechnung ist, daß Du Annahmen über die durchschnittliche Caching-Strategie Deiner Besucher brauchst - diese erhältst Du aus der HTTP304-Quote Deiner Zugriffe, _nachdem_ Du alles mit optimalen Expires-Headern versorgt hast ... je niedriger dieser Quote ist, um so besser ist Caching gegenüber Include+gzip.

Ja, der Wert war _sehr_ hoch bei mir, mal sehen wie sich das jetzt entwickelt! Im prinzip müsste er jetzt auf 0 sinken, da ich alles außer PHP-Output cache!

2 Variante wäre mit Content-Negotiation zu arbeiten, d.h. ich erstelle manuell auch ...js.gz und ...css.gz Dateien, die ich dann mit "options multiview" in der httpd.conf des Apachen entsprechend ausgeben lasse.

Das ist halt aufwändig zu pflegen. (Es sei denn ... siehe unten.)

Ist bei 10 Dateien aber wohl ein vertretbarer aufwand, und vermutlich recht performant.

Noch eine Variante wäre es, die Komprimierung der HTML-Ausgabe der PHP-Scripte nicht PHP, sondern mod_gzip zu überlassen, was haltet Ihr davon?

mod_gzip 1.3.26.1a beherrscht _beide_ von Dir vorher beschriebenen Methoden und könnte Dir die statischen *.gz-Dateien automatisch herstellen und aktualisieren ... (Christians Implementierung!)

Ja, davon habe ich gehört, ich habe ers mir heute auch nochmal angesehen, vielleicht baue ich es auch noch ein. Ist halt die Frage ob sich das für die paar wenigen Dateien lohnt. Mit multiview könnte ich ja glaueb ich wirklich USer-Agent abhängig .gz Ausliefern, udn ich habe keinen "on-the-fly Overhead", ist mir im Moment am sympatischsten.

Eigentlich wäre das ja nicht nötig, also müsste der Weg mit PHP und kpl. ohne mod_gzip der effektivere sein, oder?

Es gibt schon Gründe für die Existenz von mod_gzip - trotz mod_deflate 2.0 ...

Ja, die Frage ist, ob sich das auch für die HTML-Ausgabe der PHP-Scripte lohnt. Ich verwende zu zeit wie gesagt eine PHP-Funktione die die Ausgabve puffert und am Ende komprimiert ausgibt. Da hätte ich vermutlich auch von mod_gzip keine Vorteile, oder?

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

ExpiresByType image/jpeg "access plus 14 days"
    ExpiresByType image/gif "access plus 14 days"
    ExpiresByType application/x-javascript "access plus 7 days"
    ExpiresByType text/css "access plus 7 days"

Yep, so ähnlich sieht das bei mir auch aus.

Was anderes habe ich nicht, wie gesagt ist der HTML-Output von PHP komplett dynamisch. Aber es ist wirklich unglaublich was sich dadurch die Geschwindigkeit verändert,ich spare mit 10-20 Requests pro Seite! Nur das erste mal dauert es länger als früher.

Dann hast Du Deinen Browser schon mal richtig konfiguriert. ;-)
Vergleiche auch langfristig, wie sich die HTTP-304-Quote dadurch ändert. (Bei auf "automatisch" konfigurierten Browsern sollte sie von über 30% auf unter 10% der Requests sinken.)

Hast Du mal durchgerechnet, ob es sich rechnet, das Zeug einzubinden und komprimiert auszuliefern?
Das wäre natürlich eien interessante Alternative. Denn beim Komprimieren von JS... bekomme ich Probleme mit älteren Browsern. Oder kann ich abhängig vom Browser(ich weiß...) z.B. beim Netscape 4 verhindern dass der die Komprimierte Version des Javascriptes bekommt?

Ja - über Analyse des UserAgent. In mod_gzip ist das bereits eingebaut; bei Apache selbst kannst Du über mod_setenvif bedingt Environment-Variablen setzen und bei der Ausgabekomprimierung darauf reagieren (so würde man das mit Apache 2 und mod_deflate lösen). Bei Einbinden in PHP hast Du das Problem nicht mehr, weil Du ja nur noch ein HTML-Dokument komprimierst - und das kann Netscape 4 im Wesentlichen (solange der Besucher es nicht drucken will ...).

Wie oben schon erwähnt: Rechne durch, ob es besser ist, das Zeug in PHP zu includen und dann gleich mit zu komprimieren, oder ob Du den separaten Caching-effekt haben willst.
Gut wäre sowohl komprimiert als auch gecached!

Wenn Du Netscape 4 ignorierst, kannst Du beides kombinieren. Ist Netscape 4 wichtig, dann mußt Du Dich entscheiden zwischen separater Übertragung (caching-freundlich) und Einbinden (komprimierbar).

Ja, der Wert war _sehr_ hoch bei mir, mal sehen wie sich das jetzt entwickelt! Im prinzip müsste er jetzt auf 0 sinken, da ich alles außer PHP-Output cache!

Ab und zu läuft auch Deine 14-Tage-Periode ab. 5% ist schon ganz okay.

Ja, davon habe ich gehört, ich habe ers mir heute auch nochmal angesehen, vielleicht baue ich es auch noch ein. Ist halt die Frage ob sich das für die paar wenigen Dateien lohnt. Mit multiview könnte ich ja glaueb ich wirklich USer-Agent abhängig .gz Ausliefern, udn ich habe keinen "on-the-fly Overhead", ist mir im Moment am sympatischsten.

mod_gzip kann genau das ebenfalls.

Ja, die Frage ist, ob sich das auch für die HTML-Ausgabe der PHP-Scripte lohnt. Ich verwende zu zeit wie gesagt eine PHP-Funktione die die Ausgabve puffert und am Ende komprimiert ausgibt. Da hätte ich vermutlich auch von mod_gzip keine Vorteile, oder?

PHP-Ausgaben wirst Du sogar besser komprimieren als mod_gzip, weil Du "gzip -9" verwendest, mod_gzip aber nur "gzip -6". (In mod_deflate ist das konfigurierbar.)

mod_gzip's Stärke ist es, Lösungen für alle Probleme aus einer Hand zu liefern ... deshalb ist es ein solches Monster-Modul.

Viele Grüße
      Michael

[Michael Schröpl]

... kleiner Nachtrag:

Ja, die Frage ist, ob sich das auch für die HTML-Ausgabe der PHP-Scripte lohnt. Ich verwende zu zeit wie gesagt eine PHP-Funktione die die Ausgabve puffert und am Ende komprimiert ausgibt. Da hätte ich vermutlich auch von mod_gzip keine Vorteile, oder?
PHP-Ausgaben wirst Du sogar besser komprimieren als mod_gzip, weil Du "gzip -9" verwendest, mod_gzip aber nur "gzip -6". (In mod_deflate ist das konfigurierbar.)

d. h. PHP komprimiert etwa 1% besser - bei deutlich höherer verursachter CPU-Last.

Viele Grüße
      Michael

[Andreas Korthaus]

Hi Michael!

PHP-Ausgaben wirst Du sogar besser komprimieren als mod_gzip, weil Du "gzip -9" verwendest, mod_gzip aber nur "gzip -6". (In mod_deflate ist das konfigurierbar.)

Woher weißt Du das? Also dass php gzip -9 verwendet? in  http://www.php.net/manual/en/ref.zlib.php steht dass der Standard von zlib.output_compression_level "-1" lautet. So ganz verstehe ich nur die Angaben nicht - was bedeutet jetzt -1? Werden die Werte alle negativ angegeben? ICh habe auch was gelesen dass PHP standardmäßig level 4 verwendet, aber das war von irgendeinem Anwender.

d. h. PHP komprimiert etwa 1% besser - bei deutlich höherer verursachter CPU-Last.

Es würde mich sehr wundern wenn die das machen würden. Gerade bei on-the-fly Komprimierung(und das ist alles was passiert) wäre das genaue Gegenteil viel günstiger. Naja, sonst stelel ich es halt ein, mit:

zlib.output_compression_level=-4

oder

zlib.output_compression_level=-6

Oder was meinst Du?

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

PHP-Ausgaben wirst Du sogar besser komprimieren als mod_gzip, weil Du "gzip -9" verwendest, mod_gzip aber nur "gzip -6". (In mod_deflate ist das konfigurierbar.)
Woher weißt Du das? Also dass php gzip -9 verwendet?

auf der mod_gzip-Mailingliste hat mal jemand Messungen gemacht und seine PHP-Komprimierung mit mod_gzip und mod_deflate verglichen. (Das Ergebnis der Diskussion war, daß in mod_deflate der Parameter eingebaut wurde, der den zuvor festen Wert von "gzip -1" konfigurierbar machte.)

in  http://www.php.net/manual/en/ref.zlib.php steht dass der Standard von zlib.output_compression_level "-1" lautet. So ganz verstehe ich nur die Angaben nicht - was bedeutet jetzt -1?

switches für die UNIX command line werden üblicherweise mit "-" eingeleitet, um sie von "richtigen Parametern" (Dateinamen etc.) unterscheiden zu können.

d. h. PHP komprimiert etwa 1% besser - bei deutlich höherer verursachter CPU-Last.
Es würde mich sehr wundern wenn die das machen würden. Gerade bei on-the-fly Komprimierung(und das ist alles was passiert) wäre das genaue Gegenteil viel günstiger.

Die "-6" von mod_gzip ist das Ergebnis ausgiebiger Tests in Sachen trade-off zwischen Effekt und CPU-Last (sagt Kevin Kiley, der Autor von mod_gzip).
Ich habe selbst mal eine Testreihe gemacht (mit einer Handvoll Dateien) und muß sagen, daß Stufe 1 auch schon sehr gut ist, daß aber bis etwa Stufe 4-6 noch ein paar Prozent herauszuholen sind. Darüber dann kaum mehr etwas, bei dennoch stark steigender CPU-Last. Auf einem Server, der sehr viele dynamische Seiten generieren muß, wäre Stufe 1 durchaus eine Überlegung wert.

Viele Grüße
      Michael

[Andreas Korthaus]

Hi Andreas,

PHP-Ausgaben wirst Du sogar besser komprimieren als mod_gzip, weil Du "gzip -9" verwendest, mod_gzip aber nur "gzip -6". (In mod_deflate ist das konfigurierbar.)
Woher weißt Du das? Also dass php gzip -9 verwendet?

auf der mod_gzip-Mailingliste hat mal jemand Messungen gemacht und seine PHP-Komprimierung mit mod_gzip und mod_deflate verglichen. (Das Ergebnis der Diskussion war, daß in mod_deflate der Parameter eingebaut wurde, der den zuvor festen Wert von "gzip -1" konfigurierbar machte.)

Also kann man das in mod_deflate jetzt konfigurierbar? mod_gzip nicht? Udn wie haben die udn PHP sich denn im Vergleich geschlagen?

switches für die UNIX command line werden üblicherweise mit "-" eingeleitet, um sie von "richtigen Parametern" (Dateinamen etc.) unterscheiden zu können.

Stimmt, aber leider weiß ich jetzt nicht wirklich was ich bei PHP angeben muss, aber da frage ich vermutlich den falschen ;-)

Die "-6" von mod_gzip ist das Ergebnis ausgiebiger Tests in Sachen trade-off zwischen Effekt und CPU-Last (sagt Kevin Kiley, der Autor von mod_gzip).

nur finde ich das ist viel zu individuell, der eine hat ein Problem mit der CPU(z.B. Self-Server, würde es wohl was bringen das hier auf -1 herabzusetzen?), der nächste eher mit dem Traffic.

Ich habe selbst mal eine Testreihe gemacht (mit einer Handvoll Dateien) und muß sagen, daß Stufe 1 auch schon sehr gut ist, daß aber bis etwa Stufe 4-6 noch ein paar Prozent herauszuholen sind. Darüber dann kaum mehr etwas, bei dennoch stark steigender CPU-Last. Auf einem Server, der sehr viele dynamische Seiten generieren muß, wäre Stufe 1 durchaus eine Überlegung wert.

Mal schaun. Aber wie gesagt, ich denke ich mache da manull, da es wirklich nur die paar Dateien sind. Ich werde das so machen:

ich schreibe mir ein Tool, PHP oder Shell-Script, welches in den beiden Verzeichnissen für CSS und JS alle Dateien mit den .gz-Versionen vergleicht, also im Prinzip vergleiche ich für jede Datei ihren MD5-Hash mit dem MD5-Hash der Datei im entsprechenden gz-Archiv, müsste doch gehen, oder(kann man direkt an diesen Hash kommen)? Wenn die sich halt unterscheiden wird die gz-Datei neu erstellt. Sollte ich hierbei gzip -9 verwenden? Wäre mit von der Performance egal, eher auf Client Seite, oder merkt der keinen Unterschied ob er ein -1 oder -9 Archiv entpackt? Vermutlich schon, oder? Vielleicht nehme ich auch -4 oder -6.

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

auf der mod_gzip-Mailingliste hat mal jemand Messungen gemacht und seine PHP-Komprimierung mit mod_gzip und mod_deflate verglichen. (Das Ergebnis der Diskussion war, daß in mod_deflate der Parameter eingebaut wurde, der den zuvor festen Wert von "gzip -1" konfigurierbar machte.)
Also kann man das in mod_deflate jetzt konfigurierbar?

Ja. ;-)

mod_gzip nicht?

Auch richtig.

Udn wie haben die udn PHP sich denn im Vergleich geschlagen?

PHP war knapp besser als mod_gzip und deutlich besser als das alte mod_deflate (deshalb haben wir angenommen, daß es "gzip -9" sein muß, ohne Rücksicht auf die CPU-Belastung). Danach habe ich im mod_deflate-Source die Stelle mit der "-1" gefunden ...

Die "-6" von mod_gzip ist das Ergebnis ausgiebiger Tests in Sachen trade-off zwischen Effekt und CPU-Last (sagt Kevin Kiley, der Autor von mod_gzip).
nur finde ich das ist viel zu individuell, der eine hat ein Problem mit der CPU(z.B. Self-Server, würde es wohl was bringen das hier auf -1 herabzusetzen?), der nächste eher mit dem Traffic.

Der Self-Server macht etwas viel Schlaueres: Er komprimiert alle statischen Dokumente nur einmal! (Für diesen Zweck hat Christian ja die gzip_cnc-Logik in mod_gzip 1.3.26.1a implementiert.)
Lediglich bei den CGI-Anwendungen macht sich die gzip-Qualitätsstufe bemerkbar - und dort ist "-6" eben ein vernünftiger Kompromiß.

ich schreibe mir ein Tool, PHP oder Shell-Script, welches in den beiden Verzeichnissen für CSS und JS alle Dateien mit den .gz-Versionen vergleicht, also im Prinzip vergleiche ich für jede Datei ihren MD5-Hash mit dem MD5-Hash der Datei im entsprechenden gz-Archiv, müsste doch gehen, oder(kann man direkt an diesen Hash kommen)?

Wir haben dies über das Last Modification Date gelöst (in mod_gzip ebenso wie in gzip_cnc).

Sollte ich hierbei gzip -9 verwenden?

Ja (gzip_cnc macht das per Default so), weil Du die statischen Dateien sehr oft liest, aber nur einmal komprimierst). (Mein gzip_cnc-Log zeigt mir, daß die Rate der Zugriffe, die eine erneute Komprimierung erfordern, in der Größenordnung von 2% lag - your mileage may vary.)

merkt der keinen Unterschied ob er ein -1 oder -9 Archiv entpackt?
Vermutlich schon, oder?

Nein, der Client spult lediglich eine Decodierungstabelle ab. (Bei besserer Komprimierung geht das Dekomprimieren also sogar schneller!)
Die CPU-Last auf Serverseite hängt dagegen stark davon ab, wie intensiv der Komprimierer nachdenkt, um die _optimale_ Codierung zu finden - dafür gibt es unterschiedlich "teure" Algorithmen.

Viele Grüße
      Michael

[Andreas Korthaus]

Hi!

Wir haben dies über das Last Modification Date gelöst (in mod_gzip ebenso wie in gzip_cnc).

Oh Gott, ja ;-)

Grüße
Andreas

[Michael Schröpl]

Hi Heiner,

Je mehr Dokumente angefordert werden müssen, desto größer wird auch der Verwaltungsaufwand für das Protokoll.

richtig - aber völlig unabhängig davon, wieviele Dokumente tatsächlich exisieren.

Ein Vorteil von Frames ist ja gerade, daß sie bezüglich Caching sehr viel effizienter sein können (geeignete Kooperation zwischen Server und Browser vorausgesetzt) als eine immer wieder gleiche Navigation, die mit jeder Nutzseite immer wieder neu gesendet werden muß.

Viele Grüße
      Michael

[Siechfred]

Hi,

ich wollte hier im Forum mal fragen, ob ihr meine website (www.sgd-dresden.de) zu langsam findet und was ich vor allem verbessern könnte (also gesehn an der Ladezeit)?

Ich habe mal den hier befragt:
http://de.webmasterplan.com/cgi-local/router.cgi?l=de&p=wmpde&s=opt_load

Ergebnis:
Summe der Größe aller Elemente: 147.798 bytes
Deine Speed-Killer dürften sein:
logo100.jpg : 35.220 bytes
news.htm : 22.222 bytes

Außerdem solltest du dringend die von dir verwendeten Grafiken optimieren, denn die sind in Summe mehr als 75 kB groß.

Viele Grüße
Torsten

[btsv fan]

moin,

ich optimiere nur mit dem weboptimierer von photoshop. ab jetzt wirds supjetiv: *ist der beste !*

verzichte auf gif und verwende .png !

vergleiche deine bilder im .jpg und .png format, du wirst überascht sein.

ein layout ohne frames/tabellen wird schneller geladen. wie wäre es mit css 'boxen'?

viele grüße

Frau Luchte

ps. 4:1 ist mein tipp, wir sehen uns in braunschweig !

[player2000]

hi,

danke für die tipps, bei mir ist aber irgendwie das .png viel größer als das .gif Format.

oh gott, css-boxen, du meinst ich soll auf der page überhaupt keine <table>-tags nehmen ?
mit den frames ist mir ja nun klar, werd ich wohl wegmachen

ach ja, mein tipp fürs spiel ein 1:2, man sieht sich

[at]

Hallo.

oh gott, css-boxen, du meinst ich soll auf der page überhaupt keine <table>-tags nehmen ?

Nein, er meinte, du sollst deine Hände zu Fäusten ballen und so lange vor das CSS schlagen, bis die Seiten endlich schneller werden ;-)
MfG, at

[Andreas Korthaus]

Hi!

danke für die tipps, bei mir ist aber irgendwie das .png viel größer als das .gif Format.

Wie/womit optimierst Du denn die Bilder? Vielleicht auch mal JPG versuchen, das ist bei solchen Bildern oft besser als GIF, aber auch nicht besser als PNG. Normalerweise kannst Du beim SPeichern die Qualität herabsetzen, da,mit musst Du halt rumspielen, bis Du Deine optimale Dateigröße bei möglichst guter Qualität erreichst, den Kompromiss musst Du selbst beurteilen.

oh gott, css-boxen, du meinst ich soll auf der page überhaupt keine <table>-tags nehmen ?

Das wird sicher nicht viel an der Ladegeschwindigkeit ändern, die Bilder sind 10 mal größer als die HTML-Seite, die Bilder sind Dein Problem!
Wobei Tabellen soewieso nicht wirklich für Design-Zwecke gedacht sind, naja, hat aber wie gesagt wenig mit der Ladezeit zu tun.

mit den frames ist mir ja nun klar, werd ich wohl wegmachen

Das ist in jedem Fall sicher kein Fehler, aber auch nicht der große Wurf Richtung Performance.

Grüße
Andreas

[player2000]

also das mit dem png müsst ihr mir nochma erklären, bei jedem versuch die datei in eine png-datei zu verwandelt, wird png größer als gif oder jpg
ach ja, ich spiecher einfach im photoshop die datei unter png
mein erstes problem ist ja der hintergrund, es ist derzeit ne jpg-datei die etwas größer als 50 kb ist, was denkt ihr, was für ne größe ist da drin ?

[Andreas Korthaus]

Hi!

also das mit dem png müsst ihr mir nochma erklären, bei jedem versuch die datei in eine png-datei zu verwandelt, wird png größer als gif oder jpg
ach ja, ich spiecher einfach im photoshop die datei unter png
mein erstes problem ist ja der hintergrund, es ist derzeit ne jpg-datei die etwas größer als 50 kb ist, was denkt ihr, was für ne größe ist da drin ?

Naja, ich bin da nicht ganz so optimistisch wie Michael, Du verwendest einfach zu speicherintensive Grafiken, die lassen sich einfach nicht wirklich klein kriegen, zumindest nicht ohne merklich Schlieren oder sowas auf dem Bild zu haben. Du hast Photoshop? Da hast Du oben unter Datei -> Für Web speichern, da musst Du probieren, da siehst Du direkt wie die verkleinerte Version aussieht. Wähle hier jpeg oder png, und verändere rechts den Schieber für die Qualität, solange bis Du einen guten Kompromiss gefunden hast. Und ich würde Michels Tipps befolgen. Alles auf ein Bild zu bringen ist sehr schlecht für die Komprimierung. Aber wenn das Designs so bleiben soll wie es jetzt ist, wirst Du nicht an akzeptable Ladezeiten für ein 56K Modem gelangen. Wenn man da mal 10 Sekunden Ladezeit ansetzt, müsstest Du unter 50 KB kommen, insgesamt, und das ist mit Sichereit nicht möglich. Das Problem sind die vielen Details und Übergänge der Bilder. Auf alle Fälle solltest Du es versuchen, denn deu aktuelle Ladezeit ist inakzeptabel für ein Modem. Oder würdest Du über 30 Sekunden(im günstigsten Fall!) auf eine Seite warten?

Grüße
Andreas

[Siechfred]

Hi,

mein erstes problem ist ja der hintergrund, es ist derzeit ne jpg-datei die etwas größer als 50 kb ist, was denkt ihr, was für ne größe ist da drin ?

Keine Ahnung, aber wenn es dir hilft, dann kannst du zumindest PNG und GIF transparent machen, das spart schon mal bei der Dateigröße. Die fehlende Hintergrundfarbe kannst du dann via background-color festlegen.

Viele Grüße
Torsten

[Christian Seiler]

Hallo Siechfred,

Keine Ahnung, aber wenn es dir hilft, dann kannst du zumindest PNG und GIF transparent machen, das spart schon mal bei der Dateigröße.

Aber definitiv nicht. Du brauchst immernoch einen Paletteneintrag für die Pixel, die alle transparent sein sollen. Da steht dann meist eine Dummy-Farbe drin. Zudem musst Du dann noch die Information abspeichern, dass diese Dummy-Farbe transparent ist. Folglich braucht eine Datei mit Transparenz mehr Platz als eine Datei ohne; es sei denn, in der Datei ohne liegen mehrere Bytes nur für diese Information 'brach'. (wie das jeweils ist, weiß ich nicht, es ist über 5 Jahre her, dass ich ein Dokument zum GIF-Format gelesen habe und die PNG-Spec habe ich mir noch nie angeschaut) Ergo: Die Datei mit der Transparenz ist mindestens genauso groß, wenn nicht gar größer.

Viele Grüße,
Christian

[Siechfred]

Hi Christian,

Aber definitiv nicht. [...]

Deine Erklärung klingt plausibel. Ich habe jedoch genau diesen Effekt praktisch beobachtet. Ich erstelle meine Grafiken generell als Bitmap und mache sie dann mit dem ULead Smartsaver webtauglich. Wenn ich einen transparenten Bereich festlege, verkleinert sich in der Vorschau die Dateigröße. Keine Ahnung warum, ist aber so. Speichere ich die zwei Versionen mit identischen Einstellungen, eine transparent, eine nicht, ist die transparente Datei kleiner.

Dieses Phänomen (?) ist sowohl bei GIF als auch bei PNG zu beobachten, wobei im GIF-Format die Einsparung etwas größer ist als bei PNG.

Viele Grüße
Torsten

[Christian Seiler]

Hallo Torsten,

Ich erstelle meine Grafiken generell als Bitmap und mache sie dann mit dem ULead Smartsaver webtauglich. Wenn ich einen transparenten Bereich festlege, verkleinert sich in der Vorschau die Dateigröße. Keine Ahnung warum, ist aber so. Speichere ich die zwei Versionen mit identischen Einstellungen, eine transparent, eine nicht, ist die transparente Datei kleiner.

Ich kenne das Programm nicht, mit dem Du die Bilder erstellst, aber kann es sein, dass dieses Programm *immer* eine Farbe für Transparenzen reserviert? Und dass diese nun einfach ausgenutzt wird und daher die Datei kleiner wird? Bei mir sind transparente PNGs nämlich immer etwas größer als nicht-transparente PNGs.

Viele Grüße,
Christian

[Siechfred]

Hi Christian,

Ich kenne das Programm nicht, mit dem Du die Bilder erstellst, aber kann es sein, dass dieses Programm *immer* eine Farbe für Transparenzen reserviert? Und dass diese nun einfach ausgenutzt wird und daher die Datei kleiner wird? Bei mir sind transparente PNGs nämlich immer etwas größer als nicht-transparente PNGs.

Es wäre gut möglich, dass dieses Phänomen dem SmartSaver eigen ist. Leider habe ich auf die Schnelle nirgendwo etwas dazu gefunden, ich werde mal noch ein wenig stöbern. Aus der GIF-Doku (http://www-user.tu-chemnitz.de/~mad/Software/doc/gif89a.html) jedenfalls werde ich diesbezüglich nicht so recht schlau, was aber durchaus an meinen mangelnden Fachenglischkenntnissen liegen kann.

Viele Grüße
Torsten

[Michael Schröpl]

Hallo Christian,

kann es sein, dass dieses Programm *immer* eine Farbe für Transparenzen reserviert? Und dass diese nun einfach ausgenutzt wird und daher die Datei kleiner wird? Bei mir sind transparente PNGs nämlich immer etwas größer als nicht-transparente PNGs.

"pauli.gif" aus dem aktuellen Beispiel, mit Paintshop Pro 4.x als PNG abgespeichert:
a) Transparent für Farbe 15: 8274 Bytes
b) Transparent für Farbe  0: 8259 Bytes
c) Keine Transparenz-Informationen speichern: 8246 Bytes
Ich bin überrascht - ich hätte auch erwartet, daß sich die Dateigröße nicht ändert.

Viele Grüße
      Michael

[player2000]

so, ich habe mal einiges geändert, was sagt ihr nun zur ladegeschwindigkeit ?

[Michael Schröpl]

Hi player2000,

so, ich habe mal einiges geändert, was sagt ihr nun zur ladegeschwindigkeit ?

mit Opera 7 fällt die Optik der Seiten nun völlig auseinander.

Und Mozilla zeigt mir folgenden Text an (eine Service-Meldung von T-Online!):

Das Dokument konnte nicht gefunden werden.

Bitte überprüfen Sie Ihren URL Hinweis :

Bei Dateinamen wird auf Groß- und Kleinschreibung unterschieden

We are sorry, but the private homepage server could not find the file you asked for.

Please check the URL to ensure that the path is correct.

Deshalb kann ich die nun ggf. kleineren Graphiken mit meinem Lieblings-Browser nicht mehr im Detail analysieren. Ja, so ist das nun mal, wenn man seine Besucher belügt und Framesets zum tarnen der eigentliche Domain dazwischen schaltet ...

Deine ganzen PopUp-Boxen mit der häßlichen Werbung drin habe ich übrigens ausgefiltert.

Viele Grüße
      Michael

[player2000]

Ja, so ist das nun mal, wenn man seine Besucher belügt und Framesets zum tarnen der eigentliche Domain dazwischen schaltet ...

na die kurze domain ist auf jeden fall einfacher einzugeben und zu merken als die lange t-online-domain ...

wäre denn das problem mit opera und mozilla verschwunden, wenn ich die lange domain anzeigen lassen würde ?
Was könnt ich sonst machen ?