nicht angemeldet
Tuning-Tricks jeder Art...
hi
Ich bin mal interessiert, wie ihr so eure Seiten auf Tempo bringt, eine Fähigkeit, die ja ganz offensichtlich nicht sehr weit verbreitet ist :)
Serverseitig
Server ohne mod_gzip gibt es bei mir nicht, 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 :)
..ich habe bei mir übrigens 2 Arten von JavaScript-Dateien:
.js -> Script auch für Netscape 4
.dom -> Script läuft eh in Netscape 4 nicht und geht auch gleich durch mod_gzip.
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'..
an der Page
Da gilt zunächst einmal, dass man redundante Angaben vermeiden sollte.
Verschachtelte Tabellen sind auch übel, hier aber vor allem, weil _jeder_ Browser da zäh wird, Netscape 4 ganz extrem.
Die "kleinen blind-GIFs, die der Browser ja sowieso im Cache hat" sind sicherlich heiße Kandidaten für mehr gebrauchte Bandbreite, wie überhaupt jeder unnütze Datei - auch darüber CSS-Dateien über SSI gleuch in der Datei einzuarbeiten kann man normal nachdenken, 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 ;) 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*)
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
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...
so, das wären meine Tricks.
Wer hat noch ein paar auf Lager? Oder hab' ich irgendwo Mist geschrieben?
Grüße aus Bleckede
Kai
-
hallo!
Serverseitig
- mod_gzip
an der Page
- redundante Angaben vermeiden
- verschachtelte Tabellen sind auch übel
- Die "kleinen blind-GIFs
- Grundsätzlich ich jede Datei zu vermeiden, die nicht unbedingt nötig ist
- Redirected [vermeiden]
- Bildern eine Größe [geben]
Wer hat noch ein paar auf Lager?
ein gott sei dank langsam aussterbender fehler hinsichtlich der schnelligkeit der übertragung ist zweifellos das kommentieren.
außerdem sollte man metaangaben nur auf autor, beschreibung und drei, vier stichwörter beschränken.
listen als listen setzen, nicht als bild-text-konstrukte oder mit blinden tabellen. generell ist valider quelltext fast schon ein garant für kleinere dateien, zumindest ein paar hundert byte pro datei kann man sparen. ebenso tabellen auf div umstellen.
sinnvolle graphikformate wählen, auch png und jpeg gelegentlich auf 256 farben setzen.
alles kleine dinge, aber das summiert sich.
emu
[...]-
hi
ein gott sei dank langsam aussterbender fehler hinsichtlich der schnelligkeit der übertragung ist zweifellos das kommentieren.
du meinst die Romane in manchen Dateien? ;)
außerdem sollte man metaangaben nur auf autor, beschreibung und drei, vier stichwörter beschränken.
jup! Alle anderen Regeln werden nie oder nur von wenigen unbedeutenden Suchmaschinen ausgewertet - gilt leider auch für DC-Angaben ;(
listen als listen setzen, nicht als bild-text-konstrukte oder mit blinden tabellen.
...?
Ich kann mich da an einiges gruseliges errinnern - vielleicht hat sich noch nicht rungesprochen, dass es list-style-image gibt...generell ist valider quelltext fast schon ein garant für kleinere dateien, zumindest ein paar hundert byte pro datei kann man sparen. ebenso tabellen auf div umstellen.
Tabellen-Bandwürmer können auch valide sein - 3 Postings weiter unten ist ein Code, der zwar weitgehend valide, aber extrem aufgebasen ist.
sinnvolle graphikformate wählen, auch png und jpeg gelegentlich auf 256 farben setzen.
Ich habe sogar schon BMP-Bilder gesehen, also wohl durchaus erwähnenswert....
Grüße aus Bleckede
Kai
[der Seine CSS-Datei doch nur auf 3,4KB gebracht hat, davon 400Byte Netscape4-Würgarounds, die allerdings nur das gröbste abfangen]
-
Hi Emu,
ein gott sei dank langsam aussterbender fehler
hinsichtlich der schnelligkeit der übertragung ist
zweifellos das kommentieren.ich habe im Büro solche Dateien, in denen 'Romane'
stehen. Beispielsweise Entwurfsentscheidungen für
bestimmte Browser oder ähnliches.Aber ich habe eben auch ein Perl-Skript, welches diese
Dateien "übersetzt", also alles entfernt, was ich auf
dem Zielserver später nicht brauche ... beispielsweise
Leerzeichen am Zeilenanfang und -Ende ... das kennt
sogar ein Meta-Zeichen für "verschmelze diese beiden
aufeinanderfolgenden Zeilen nahtlos", so daß ich
Tabellen auf Lesbarkeit formatieren kann, ohne mir
dabei zusätzliche whitespaces einzuhandeln ...Viele Grüße
Michael
-
Hi Kai,
ich weiss nicht, ob 'ne Handvoll Bits und Bytes angesichts der heute zur Verfuegung stehenden Techniken wie DSL, Kabelmodem, Wireless ueber Satellit ueberhaupt noch gross ins Gewicht fallen. Leider habe ich keinerlei Statistiken ueber die weltweite Verbreitung dieser Techniken gefunden, um mir ein Bild machen zu koennen und meine Aussage zu untermauern.
Als "Tip" vielleicht noch etwas aus dem Datenbankbereich (duerfte aber eigentlich auf der Hand liegen):
Niemals Bilder oder Riesentexte direkt in der Datenbank ablegen. Statt dessen einen Suchindex anlegen und nur die Links zu den entsprechenden Dateien in die Datenbank aufnehmen.
HTH
Uwe-
hi
ich weiss nicht, ob 'ne Handvoll Bits und Bytes angesichts der heute zur Verfuegung stehenden Techniken wie DSL, Kabelmodem, Wireless ueber Satellit ueberhaupt noch gross ins Gewicht fallen.
sichermich keine "handvoll Bits und Bytes", allerdings wenn das Verhältnis 1:10 oder so ist, fällt das auf. Auf meinen Server [wo auch immer der gerade sein mag..] befindet sich eine Hardware-Datenbank mit teilweise sehr langen Tabellen. Zumindest über ISDN waren diese sehr sehr zäh ohne mod_gzip, trotz ansonsten sehr kompaktem HTML-Code. Mit war dann plötzlich über ISDN das möglich, wofür sonst DSL voll ausgelastet ist! Leider werden die Seiten wohl immer fetter und die Leitungen kommen kaum hinterher, so dass alles selbst mit bester Anbindung nur gleich schnell bleibt :(
Leider habe ich keinerlei Statistiken ueber die weltweite Verbreitung dieser Techniken gefunden, um mir ein Bild machen zu koennen und meine Aussage zu untermauern.
imho nur in den "westlichen Industrienationen" überhaupt nennenswert existent.
Niemals Bilder oder Riesentexte direkt in der Datenbank ablegen. Statt dessen einen Suchindex anlegen und nur die Links zu den entsprechenden Dateien in die Datenbank aufnehmen.
gibt es Leute, die sowas machen?
Grüße aus Bleckede
Kai
-
Hallo,
Niemals Bilder oder Riesentexte direkt in der Datenbank ablegen.
Warum eigentlich nicht?
Statt dessen einen Suchindex anlegen und nur die Links zu den entsprechenden Dateien in die Datenbank aufnehmen.
So ist ein Zugriff auf die Datenbank UND das Dateisystem notwendig. Ob das immer soviel schneller ist?
Gruss
MichaelB-
Hi Michael,
Statt dessen einen Suchindex anlegen und nur die
Links zu den entsprechenden Dateien in die
Datenbank aufnehmen.
So ist ein Zugriff auf die Datenbank UND das
Dateisystem notwendig. Ob das immer soviel schneller
ist?der Zugriff auf das Dateisystem ist bestimmt schneller,
als große Datenmengen durch das SQL-Interface zu quälen
und dann womöglich noch formatieren zu müssen.Viele Grüße
Michael
-
-
Hi Kai,
ich weiss nicht, ob 'ne Handvoll Bits und Bytes angesichts der heute zur Verfuegung stehenden Techniken wie DSL, Kabelmodem, Wireless ueber Satellit ueberhaupt noch gross ins Gewicht fallen. Leider habe ich keinerlei Statistiken ueber die weltweite Verbreitung dieser Techniken gefunden, um mir ein Bild machen zu koennen und meine Aussage zu untermauern.
Als "Tip" vielleicht noch etwas aus dem Datenbankbereich (duerfte aber eigentlich auf der Hand liegen):
Niemals Bilder oder Riesentexte direkt in der Datenbank ablegen. Statt dessen einen Suchindex anlegen und nur die Links zu den entsprechenden Dateien in die Datenbank aufnehmen.
HTH
UweUps, jetzt trau ich mich was (so sicher bin ich mir nämlich nicht bei der Programmierei ;o) )
- Ich verknüpfe gerne eine css Datei mit allen Seiten. Das hat den Vorteil, dass ich bei Änderungen (z.B. Linkfarbe) nur einmal ändern muss und nicht 50 oder mehr Dateien. Und natürlich das ich nur eine Datei brauche. Verflixt, spart das auch Bandbreite, oder muss das Teil jedes mal übertragen werden? Eigentlich doch nicht, da sie am Cache ist.
Bilder:
- Ich schraube gerne bei Bildern herum. d.h. jpg Qualität soweit runter, das das Motiv immer noch gut zu erkennen ist. Zur Sicherheit schaue ich mir ein Foto auch immer nochmal gerne als Gif oder png an. Glätten ist auch gut, genauso das Einschalten der Funktion, das das Bild mit der Übertragung immer schärfer wird. Bei Gifs müssen es nicht immer 256 Farben sein. Meist reichen weniger. Bei Buttons schaue ich immer ob es auch harte Übergänge tun.
HTML:
- Ich hörte ja mal, das Tabellen überhaupt nicht zum Layouten einer Seiten verwand werden sollen. Mach trotzdem ;o). Sowenig verschachteln wie möglich (hat Kai ja schon geschrieben). Ich benutze DW, schaue aber trotzdem nochmal durch ob ich was zusammenfassen kann (meist kann ich). Keine Seite über 60-80 kBit, lieber weniger dafür Seiten teilen. Aufzählungen kann ma auch schön mit Standardmitteln erreichen - denke nicht das es immer ein Gif sein muss.
-Ordentliche Kundenberatung ist auch nicht zu verachten. Ist mir schon oft passiert, das jemand eine Wegbeschreibung haben will und mit einer gescannten Falkkarte kommt -natürlich als bmp in 2000 x 2000.
Tja, mehr fällt mir jetzt im moment nicht ein. Ausserdem muss ich mich rasieren. Meine Freundin hat sich schon beschwert. ;o)
Stefan
-
Moin!
HTML:
Keine Seite über 60-80 kBit, lieber weniger dafür Seiten teilen.Das würde ich nicht sagen.
Ok, die Startseite sollte schnell geladen sein - mehr als 60 KByte (nicht Bit ;) ) ist im gelben Bereich, mehr als 100 KByte ist im roten Bereich.
Aber wenn eine Unterseite einen langen, zusammenhängenden Text enthält, den ich komplett lesen will, dann ist nichts nerviger, als zwischendurch ständig "weiter" klicken zu müssen. Man verliert so auch Benutzerfreundlichkeit, denn ich kann nicht mal eben schnell wieder hochscrollen, um nochmal was nachzuschauen, sondern muss vor- und zurückklicken.
Und auch das Ausdrucken dürfte so schwierig werden. Wenns dumm kommt, dann ist eine dieser Mehrfachseiten genau 1,1 Papierseiten lang (der letzte Satz und die Copyrightzeile müssen auf die nächste Seite). Ein Ausdruck am Stück würde viele fast leere Seiten sparen.
- Sven Rautenberg
-
Hallo!
Aber wenn eine Unterseite einen langen, zusammenhängenden Text enthält, den ich komplett lesen will, dann ist nichts nerviger, als zwischendurch ständig "weiter" klicken zu müssen. Man verliert so auch Benutzerfreundlichkeit, denn ich kann nicht mal eben schnell wieder hochscrollen, um nochmal was nachzuschauen, sondern muss vor- und zurückklicken.
Dann nimm doch flash, das kann streamen ;-)
Grüße
Andreas -
Ok, die Startseite sollte schnell geladen sein - mehr als 60 KByte (nicht Bit ;) )
äh, ja. ;o)
ist im gelben Bereich, mehr als 100 KByte ist im roten Bereich.
Ack
...um nochmal was nachzuschauen, sondern muss vor- und zurückklicken.
Ja, das ist die Crux bei jedem Projekt.
... Ein Ausdruck am Stück würde viele fast leere Seiten sparen.
Kann ich nichts hinzufügen
- Sven Rautenberg
Stefan
-
-
hi
<bitte keine Fullquotes, danke>
- Ich verknüpfe gerne eine css Datei mit allen Seiten. Das hat den Vorteil, dass ich bei Änderungen (z.B. Linkfarbe) nur einmal ändern muss und nicht 50 oder mehr Dateien. Eigentlich doch nicht, da sie am Cache ist.
schon, aber auch ein Vergleich mit dem Cache muss erfolgen -> also wenn die Datei winzig klein ist, wie man es immer noch sehr oft sieht, da nur die a:hover-Regeln dort stehen, macht es keinen Sinn mehr. Oder man schiebt das DIng über SSI in die HTML-Datei
- Ich hörte ja mal, das Tabellen überhaupt nicht zum Layouten einer Seiten verwand werden sollen. Mach trotzdem ;o). Sowenig verschachteln wie möglich (hat Kai ja schon geschrieben). Ich benutze DW, schaue aber trotzdem nochmal durch ob ich was zusammenfassen kann (meist kann ich). Keine Seite über 60-80 kBit, lieber weniger dafür Seiten teilen.
7,5-10KByte? jo, das kommt hin. Es gibt ja ofters Studien, wie lange ein Surfer es so aushält, dabei kann man aber auch selbst mal sein Glück versuchen die lange man es so aushält, bis es nervt, dabei ist meine Erfahrung, dass man normal bis zu 10Sekunden erträgt, wenn man sich aber durch Forem klickt, ist jede Millisekunde wichtig.
-Ordentliche Kundenberatung ist auch nicht zu verachten. Ist mir schon oft passiert, das jemand eine Wegbeschreibung haben will und mit einer gescannten Falkkarte kommt -natürlich als bmp in 2000 x 2000.
Die kann man idr. aber Problemlos umwandeln und dann nachbearbeiten... (naja, oder man legt eine Ebene drüber wo dann die wichtigen Straßen reinkommen und kickt die zugrundeliegende Bildebene).
Grüße aus Bleckede
Kai
-
hi
... mehr. Oder man schiebt das DIng über SSI in die HTML-Datei
Das macht durchaus Sinn, aber bei mir steht in der Regel mehr al a:hover drin. Aber die SSI Lösung hat auch was.
Die kann man idr. aber Problemlos umwandeln und dann nachbearbeiten... (naja, oder man legt eine Ebene drüber wo dann die wichtigen Straßen reinkommen und kickt die zugrundeliegende Bildebene).
Leider ist oft auch die Qualität des Scans so bescheiden, dass ich mir einen Wolf nachbearbeiten kann. Ich verweise da gerne auf Map24 und bau das dann ein. Ist zwar nicht mehr Bandbreiten schonend, macht aber einen besseren Eindruck bei den Usern der Seiten.
Grüße aus Bleckede
Kai
-
Hi Kai,
- Das hat den Vorteil, dass ich bei Änderungen
(z.B. Linkfarbe) nur einmal ändern muss und
nicht 50 oder mehr Dateien. Eigentlich doch
nicht, da sie am Cache ist.
schon, aber auch ein Vergleich mit dem Cache muss
erfolgen
... es sei denn, der Browser kommt zum Ergebnis, daß er
besser gar nicht fragen sollte.
Sendest Du Aufbewahrungsfristen? (Expires, Cache-Control)Viele Grüße
Michael - Das hat den Vorteil, dass ich bei Änderungen
-
-
Tach auch,
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
Leider weiss ich nicht mehr wo, aber ich meine irgendwo gelesen zu haben dass Deine erste Variante eine hoehere Belastung fuer den Server erzeugt. Grund waere dass er bei der ersten Variante nach einem file sucht (was es dann nicht gibt) und dann erst nach dem Verzeichnis sucht um das default file auszugeben. Beim zweiten geht er direkt zu dem Verzeichnis. Ob das stimmt weiss ich nicht, vielleicht koennen ja mal die Serverexperten Ihre Meinung dazu abgeben?
Gruss,
Armin-
Hi Armin,
Leider weiss ich nicht mehr wo, aber ich meine
irgendwo gelesen zu haben dass Deine erste Variante
eine hoehere Belastung fuer den Server erzeugt.
Grund waere dass er bei der ersten Variante nach
einem file sucht (was es dann nicht gibt) und dann
erst nach dem Verzeichnis sucht um das default file
auszugeben. Beim zweiten geht er direkt zu dem
Verzeichnis.es geht dabei nicht nur um die Last auf dem Server -
es wird sogar ein Redirect zurück zum Client gesendet,
der dann einen neuen (korrkgierten) Request senden
muß (sonst würden nämlich im Client relative Links
nicht korrekt funktionieren).Dazu gibt es einen FAQ-Eintrag in der Apache-Doku:
http://httpd.apache.org/docs/misc/FAQ.html#set-servernameViele Grüße
Michael-
Hi Michael,
es geht dabei nicht nur um die Last auf dem Server -
es wird sogar ein Redirect zurück zum Client gesendet,
der dann einen neuen (korrkgierten) Request senden
muß (sonst würden nämlich im Client relative Links
nicht korrekt funktionieren).Dazu gibt es einen FAQ-Eintrag in der Apache-Doku:
http://httpd.apache.org/docs/misc/FAQ.html#set-servernameVielen Dank fuer die Erklaerung, sehr interessant.
Gruss,
Armin
-
-
-
Hallo,
Die "kleinen blind-GIFs, die der Browser ja sowieso im Cache hat"
sind sicherlich heiße Kandidaten für mehr gebrauchte Bandbreite,...weiß nicht, ob Du es nicht schon damit sagen wolltest (vulgo: ob ich Dich nicht falsch verstanden habe), aber "ich" (oder "man") benutze, wenn überhaubt, nur ein blindes Gif. Das ist ein Pixel mal ein Pixel groß und würde beim weglassen wirklich kaum eine schlechte Ladegeschwindigkeit retten. Das kann man dann so oft benutzen, wie man möchte, die Dimensionen gibt man im image Tag an. Kostet keine weitere Ladezeit.
Ansonsten möchte ich die Wichtigkeit einer Optimierung nicht grundsätzlich in Frage stellen, nur auch mal im Raum stellen, daß man eine Seite, gerade was Grafiken angeht, auch nicht kaputtoptimiren sollte. Es geht in erster Linie (und das sollte man immer im Auge behalten!) NICHT darum, daß eine Seite möglichst schnell angezeigt wird, sondern daß Besucher aus Langeweile nicht wieder weg gehen. Das ist ein Unterschied. Besucher, so habe ich die Erfahrung gemacht, sind in bestimmten Fällen sehr wohl gewillt, relativ lange zu warten. Dazu gehört allerdings eine nichttechnische Optimierung der Seite. Deswegen sind mir folgende Optimierungen fast wichtiger als das schrauben an ein paar Bytes:
-
vor langsamen Seiten den besucher gebührend neugierig machen und "in die Seite einbinden"
-
den "vor den fetten Seiten" geschalteten Seiten einer überzeugende Qualität geben
-
Den Besuchern das Gefühl geben, für das Warten auch was bekommen zu haben.
-
Bei Bildpräsentationen immer Vorschaumöglichkeiten und Wahlmöglichkeiten bieten.
-
Wenn es geht, dem Besucher schon was während der Ladezeit bieten.
....und letztendlich auch mal den Mut haben, auf ungeduldigere Besucher zu verzichten und damit den geduldigeren etwas zu geben. (Vielleicht sogar die ladezeit als "interesse-filter" verstehen?)
Diese "Vorschläge" passen kaum auf alle Anwendungsbereiche des Netzes, ich weiß. Ich weiß ja auch, daß es vielfältige Möglichkeiten gibt, Information zu vermitteln ;-)))
Chräcker
-
hi
...weiß nicht, ob Du es nicht schon damit sagen wolltest (vulgo: ob ich Dich nicht falsch verstanden habe), aber "ich" (oder "man") benutze, wenn überhaubt, nur ein blindes Gif. Das ist ein Pixel mal ein Pixel groß und würde beim weglassen wirklich kaum eine schlechte Ladegeschwindigkeit retten. Das kann man dann so oft benutzen, wie man möchte, die Dimensionen gibt man im image Tag an. Kostet keine weitere Ladezeit.
genau da ist der Fehler:
Diese Viecher, die man ja oft nicht nur einmal, sondern 10 oder 20 mal in der Seite findet, werden alle beim Server einzeln abgefragt "hi Server, darf ich meine Version aus dem Cache benutzen?" "ja, darfst du" "ok, mach' ich"... und damit ist so mancher scheinbare Vorteil durch geringe Dateigrößen weg.Es geht in erster Linie (und das sollte man immer im Auge behalten!) NICHT darum, daß eine Seite möglichst schnell angezeigt wird, sondern daß Besucher aus Langeweile nicht wieder weg gehen.
die üblich gehtst du mal wieder davon aus, dass jede Seite eine multimediale Präsentation ist. Die meisten sind aber nur dazu da, um textbasierende Informationen grafisch aufbereitet weiterzugeben.
Grüße aus Bleckede
Kai
-
Hallo,
[blinde Gifs] Kostet keine weitere Ladezeit.
genau da ist der Fehler:
Diese Viecher, die man ja oft nicht nur einmal, sondern 10 oder 20 mal in der Seite findet, werden alle beim Server einzeln abgefragtNein, das stimmt nicht. Wenn dasselbe Bild auf einer Seite mehrfach vorkommt,
wird dieses nur einmal geladen. Weitere Abfragen finden nicht statt. Im
besonderen also auch keine Abfrage, ob das Bild im Cache noch aktuell ist.
Ein solches Verhalten wäre ja auch sehr nachteilig.Erst beim Reload der Seite wird geguckt, ob die Bilddatei im Cache noch
aktuell ist, und wenn nicht, ggf. neu geladen. Auch dies geschieht nur
einmal.Ich habe dies soeben mit einer HTML-Seite, auf der sich über 1100 mal dasselbe
Bild befindet, im Mozilla 1.1, IE 5.5, NS 4.8 und Opera 6.05 getestet. Beim
Reload werden weniger als 500 Byte Traffic erzeugt (immernoch überraschend
viel, finde ich), also kann gar nicht 1100 mal überprüft werden, ob das Bild
im Cache noch frisch ist.Du kannst dir die Test-Seite hier angucken: http://slyh.de/selfhtml/blindgif-test.html
Gruß
Slyh-
hi
Beim Reload werden weniger als 500 Byte Traffic erzeugt
nagut, dann nicht :)
interessant allerdings, dass damit also das Abfragen einer einzigen Datei schon 250 Byte sind (der Test besteht ja aus 2 Dateien) - dann kann man sich mal vorstellen, was die kleinen 10Byte-"Optimierungen" so bringen...Grüße aus Bleckede
Kai
-
Hi Slyh,
[blinde Gifs] Kostet keine weitere Ladezeit.
genau da ist der Fehler:
Diese Viecher, die man ja oft nicht nur einmal,
sondern 10 oder 20 mal in der Seite findet,
werden alle beim Server einzeln abgefragt
Nein, das stimmt nicht. Wenn dasselbe Bild auf einer
Seite mehrfach vorkommt, wird dieses nur einmal
geladen. Weitere Abfragen finden nicht statt.manchmal doch.
Einige Browser machen nämlich parallel mehrere HTTP-
Requests (bei Opera kann man sogar einstellen, wie-
viele). Die eliminieren nicht vorher jedes redundante
Bild aus der Liste. Ich könnte Dir Apache-Logs zeigen,
da wird Dir schlecht von ...Ein solches Verhalten wäre ja auch sehr nachteilig.
Es _ist_ sehr nachteilig.
Wenn ein Besucher 80+% aller HTTP-Requests mit Status
304 beantwortet bekommt, dann ist das nicht wirklich
schön - zumal er diesen Wert bei "automatisch" auf etwa
5% senken könnte, also drei Viertel aller Zugriffe
einsparen ... ;-(Ich habe dies soeben mit einer HTML-Seite, auf der
sich über 1100 mal dasselbe Bild befindet, im
Mozilla 1.1, IE 5.5, NS 4.8 und Opera 6.05 getestet.Jeweils mit welcher Caching-Strategie? Stell mal
"immer prüfen" ein ... :-(Beim Reload werden weniger als 500 Byte Traffic
erzeugt (immernoch überraschend viel, finde ich),Ich fände 500 Bytes Traffic für die Summe zweier
HTTP-plus TCP-Header toll, kann mir aber nicht vor-
stellen, daß Du im Schnitt mit deutlich weniger als
1000 Bytes auskommen wirst.Viele Grüße
Michael
-
-
Hallo,
genau da ist der Fehler:
oh, danke, daß wuste ich nicht.... ja, dann verbrauchen die natürlich etwas Zeit....
wie üblich gehtst du mal wieder davon aus, dass jede Seite eine
multimediale Präsentation ist.aber nein, und Du wirst auch immer wieder von mir lesen, daß es meiner Meinung nicht *eine* Nutzungsart des Internets gibt. Weder als Multimediaplattform noch eben als html-Textbereich. Die offenheit, die die Techniker immer gerne im bezug auf die Zugangssoftware legen, klage ich eben auch immer für die Nutzungsmöglichkeit dieser verbundenen Computer ein. Und wenn bei einer Verbreitung eines Browsers von 10% die Berücksichtigung dieses Browsers eingefordert wird, dann fordere ich auch die Berücksichtigung der Informationsseiten in die "Lehre des Seitenerstellens" ein, die nach Deiner meinung nach unter 50% liegen. (Aber sicherlich höher als 10%....)
Die meisten sind aber nur dazu da, um textbasierende Informationen
grafisch aufbereitet weiterzugeben.Die frage wäre eher, was sucht der gemeine Konsument des netzes, in meinem Falle der deustchsprachige Konsument des Netzes, und da halte ich es eher für ausgewogen. Aber auch diese Frage ist müssig, denn es steht immer, bei jeder Fütterung des netzes mit Information, der Mensch im Vordergrund ist.
Und dann sollte es sich endlich mal in den Köpfen durchsetzen, daß es sogar noch mehr gibt außer "multimediale Präsentation"en und "textbasierende Informationen". Es gibt die verschiedensten Arten von Informationsvermittlung. Nicht jeder Computergestützen Informationsvermittlung "tut" eben ein reiner Blick auf die Ladezeit wirklich gut. Und nicht immer ist es nötig.
Chräcker
-
hi
Nicht jeder Computergestützen Informationsvermittlung "tut" eben ein reiner Blick auf die Ladezeit wirklich gut. Und nicht immer ist es nötig.
ein reiner tut imho nie gut (schließlich ist eine kompirmierte TXT-Datei ohne Absätze das kompakteste, was geht...), es ging mir allerdings bei diesem Thread darum, dass es wohl kaum eine Seite gibt, wo man nicht über irgendwelche Optimierungen oder über mod_gzip massiv Ladezeit sparen kann. Sicherlich wird sich auch der Leser einer Multimedia-Präsentation* nicht beschweren, wenn die Seite statt nach 2 Minuten schon nach 15-20 Sekunden komplett da ist.
*) ja, mir ist klar, dass es zwischen deinen Stempelseiten und heise eine ganze Menge Abstufungen gibt in Sachen Multimedia-Anteil
Grüße aus Bleckede
Kai
-
Hallo,
ein reiner tut imho nie gut (schließlich ist eine kompirmierte
TXT-Datei ohne Absätze das kompakteste, was geht...),ah, Labsahl für meine Augen, und ja, habe ich also auch jetzt verstanden ;-)...
*) ja, mir ist klar, dass es zwischen deinen Stempelseiten und heise
eine ganze Menge Abstufungen gibt in Sachen Multimedia-Anteiloh, aber das ist nicht wirklich jetzt wichtig, ich hoffe doch, daß meine Seite eher zwischen den bunten-multimediaseiten und heise steht, meinentwegen weiter Richtung multimedia-präsentation, aber doch nicht ganz aussen ;-))) (das aber nur für meine Eitelkeit jetzt....)
Chräcker
-
-
Hallo Chräcker,
genau da ist der Fehler:
oh, danke, daß wuste ich nicht.... ja, dann
verbrauchen die natürlich etwas Zeit....und nicht nur "etwas".
Fangen wir mal damit an, daß Dein "blind gif" zwar
etwa 50 Bytes auf Deiner Platte belegt, aber mit einem
HTTP-Header von 400 bytes angefordert und einem wei-
teren von 300 bytes ausgeliefert wurde (beides noch
sehr optimistisch gerechnet - etwas TCP-Overhead käme
nämlich auch noch dazu).
Schon sind es 300+400+50=750 bytes und damit um Faktor
15 mehr, als Du erwartet hast.Und jetzt laß dieses Bild tatsächlich 20 mal pro Doku-
ment nachgefragt werden! Daß in diesem Falle dann die
eigentlichen Daten nur einmal übertragen werden, macht
so gut wie nichts aus. Nun haben wir also einmal 750
und 19 * 700 bytes, gibt summa summarum 14050 Bytes.Das teilen wir jetzt durch die 50 Bytes des Original-
GIF und stellen fest, daß die Kosten um Faktor 281
höher liegen als die Dateigröße! Aua, aua, aua ...Man müßte den Benutzern mit Riesenbuchstaben "stelle
Deinen Cache kooperativ ein" auf den Bildschirm malen -
wenn man es als Server denn irgendwie erkennen könnte!Aber im Gegensatz zu komprimier-unwilligen Clients, die
man an ihrem fehlenden HTTP-Header "Accept-Encoding"
erkennen kann (Du erinnerst Dich an meine "bunte"
Seite, ja?), sieht man einem einzelnen unnötigen
Cache-Validierungs-Request nicht an, daß er unnötig
war. Erst wenn ein Benutzer nachweislich 80+% aller
Zugriffe mit HTTP-Status 304 macht (ich habe solche
Pappenheimer auf der Serverfarm ...), sieht man in
seinem Logfile, daß er offenbar etwas verkehrt macht.
Aber wie erreicht man diesen Benutzer?Log Dich mal auf Deinem Server ein, laß ein "tail -f"
auf Dein access_log laufen, pipe ein "grep" für Deine
IP-Adresse dahinter, und dann surfe mal mit verschie-
denen Caching-Einstellungen des Browsers über Deine
Seiten ...Viele Grüße
Michael-
Hallo!
Und jetzt laß dieses Bild tatsächlich 20 mal pro Doku-
ment nachgefragt werden! Daß in diesem Falle dann die
eigentlichen Daten nur einmal übertragen werden, macht
so gut wie nichts aus. Nun haben wir also einmal 750
und 19 * 700 bytes, gibt summa summarum 14050 Bytes.ist das so? Meines Wissens wird ein und dieselbe Resource in einem html-dokument nur 1 mal angefordert, egal wie oft sie verwendet wird! Wäre mir in meinen Logs zumindest noch nie aufgefallen! Und mit 750 Byte könnte ich ganz gut leben, dafür bräuchte selbst ein Modem gerade mal 1/10 Sekunde (2 Richtungen, obwohl das hier nichts bringt, da es definitiv nacheinander passiert)
Grüße
Andreas-
Hi Andreas,
Und jetzt laß dieses Bild tatsächlich 20 mal pro Doku-
ment nachgefragt werden! Daß in diesem Falle dann die
eigentlichen Daten nur einmal übertragen werden, macht
so gut wie nichts aus. Nun haben wir also einmal 750
und 19 * 700 bytes, gibt summa summarum 14050 Bytes.ist das so? Meines Wissens wird ein und dieselbe Resource in einem
html-dokument nur 1 mal angefordert, egal wie oft sie verwendet wird!das kommt auf den Browser an, und vor allem auf dessen Cache-
Konfiguration. Wenn der Benutzer "validate always" eingestellt hat,
solltest Du vom schlimmsten ausgehen, das Deine Phantasie Dir eingibt;
nutzt er "automatic", dann glaubt er den HTTP-Headern des Servers
(falls dieser denn mal welche sendet ...)
Das macht etwa einen Unterschied von Faktor 5 bei den Requests aus
(im Mittel über den gesamten Server).Viele Grüße
Michael
-
-
-
-
-
-
Hallo,
an der Page
Da gilt zunächst einmal, dass man redundante Angaben vermeiden sollte.also keine </td> und </tr>.
Verschachtelte Tabellen sind auch übel, hier aber vor allem, weil _jeder_ Browser da zäh wird, Netscape 4 ganz extrem.
(Sorry, aber stell deinen N4 mal vernünftig ein und teste das mal auf Windows)
Schwierig werden m.E. eher Verschachtelungen von verschachtelten Tabellen
mit divs und CSS.Wiederum Entlastung des Browsers ist, wenn man Bildern eine Größe gibt
Scheint -auch NN4- aber nichts zu bringen, also offenbar nur vermeidbare Redundanz.
Grüsse
Cyx23
-
Hallo,
Wiederum Entlastung des Browsers ist, wenn man Bildern eine
Größe gibtScheint -auch NN4- aber nichts zu bringen, also offenbar nur
vermeidbare Redundanz.wunderschön, zeigt es doch genau das, was ich meine: für wehn optimieren wir denn? Für die Maschinen oder für den Menschen?
Nehmen wir mal an, ein Brower zeigt ein Bild mit höhen-breitenangaben genauso schnell an wie ohne. Dann könnte man für die Übertragungszeit und um noch ein ützel weniger bytes zu berbrauchen, diese Angaben wirklich weg lassen. Die technikfixierten mit dem Taschenrechner im Kopf wirds freuen. Aber den Menschen kaum. Denn der muß nun für eine anständig übertragene Seite solange warten, bis der browser das ganze Bild einmal bekommen hat um dann herauszufinden, wie hoch und breit es ist und um dann endlich die einzelnen Elemente einer Seite richtig zu positionieren. Solange sieht der Mensch nämlich nur hüpfende Texte, die sich erst am Platz des iamge-platzhalters orientieren und nachdem die Bilder dann soweit da sind noch mal an ihrer letztendlichen Position rutschen. Bis dahin lohnt sich also, will man Kopfschmerzen vermeiden, der Blick auf die hereintrudelnde Seite nicht.
Deswegen gehören, bis auf wenige Ausnahmen, höhen und beitenangaben immer in ein image-Tag. Dem Menschen vor dem Monitor am Ende der Leitung zuliebe....
Chräcker
-
Hallo,
wunderschön, zeigt es doch genau das, was ich meine: für wehn optimieren wir denn? Für die Maschinen oder für den Menschen?
Nehmen wir mal an, ein Brower zeigt ein Bild mit höhen-breitenangaben genauso schnell an wie ohne. Dann könnte man für die Übertragungszeit und um noch ein ützel weniger bytes zu berbrauchen, diese Angaben wirklich weg lassen. Die technikfixierten mit dem Taschenrechner im Kopf wirds freuen. Aber den Menschen kaum. Denn der muß nun für eine anständig übertragene Seite solange warten, bis der browser das ganze Bild einmal bekommen hat um dann herauszufinden, wie hoch und breit es ist und um dann endlich die einzelnen Elemente einer Seite richtig zu positionieren. Solange sieht der Mensch nämlich nur hüpfende Texte, die sich erst am Platz des iamge-platzhalters orientieren und nachdem die Bilder dann soweit da sind noch mal an ihrer letztendlichen Position rutschen. Bis dahin lohnt sich also, will man Kopfschmerzen vermeiden, der Blick auf die hereintrudelnde Seite nicht.
mir sind solche unangenehmen Effekte allerdings sehr deutlich bei Mozilla
aufgefallen, m.E. aber mehr mit CSS als mit <img> zusammenhängend.
Auf manchen Seiten scheint das Nachjustieren der Elemente und Rumgerutsche
überhaupt nicht mehr aufhören zu wollen.Grüsse
Cyx23
-
-
hi
also keine </td> und </tr>.
Geschmackssache, theoretisch hast du recht, praktisch meinte ich ganz andere Platzfresser
(Sorry, aber stell deinen N4 mal vernünftig ein und teste das mal auf Windows)
Wenn du jetzt auch das noch bezweifelst, machst du dich lächerlich, dass die Performance von Verschachtelten Tabellen eines der größten Probleme in Netscape 4 ist (bin übrigens schon über Seiten gestolpert, wo er deswegen fast hängt, unter _jedem_ System), sehen sogar die Leute bei Netscape - nicht umsonst ist einer der Tests bei Mozilla eine massiv verschachtelte Tabelle.
Scheint -auch NN4- aber nichts zu bringen, also offenbar nur vermeidbare Redundanz.
Netscape 4 wartet nach meiner Erfahrung dann so lange, bis das Bild da ist mit der Anzeige. -> wenn das Bild gar auf einem externen und langsamen Server liegt (hallo Counter-Fans!), kann es auch mal eine Minute dauern, bis man was sieht, gleiches in Opera.
In Mozilla, MSIE, konqueror hüpfen dann "nur" die einzelnen Elemente durch die Gegend, was weder schön aussieht, noch der Benutzbarkeit der Seite falls man abbricht oder die Bilder gar nicht lädt nutzt, noch die Performance erhöht.Grüße aus Bleckede
Kai
-
Hallo,
(Sorry, aber stell deinen N4 mal vernünftig ein und teste das mal auf Windows)
Wenn du jetzt auch das noch bezweifelst, machst du dich lächerlich, dass die Performance von Verschachtelten Tabellen eines der größten Probleme in Netscape 4 ist (bin übrigens schon über Seiten gestolpert, wo er deswegen fast hängt, unter _jedem_ System), sehen sogar die Leute bei Netscape - nicht umsonst ist einer der Tests bei Mozilla eine massiv verschachtelte Tabelle.
hast du mal die URL der Testtabelle?
Grüsse
Cyx23
-
hi
hast du mal die URL der Testtabelle?
/res/samples/test6.html in jedem (?) Mozilla-Ordner. Mozilla passt die Tabelle an, sobald der Resize-Vorgang zuende ist, konqueror dabei, Amaya und Opera eben falls sporaisch dabei - Netscape 4 zeichnet die Tabelle komplett neu, wenn der Resize vorbei ist, was mehrere Sekunden weißen Screen bedeutet!
Grüße aus Bleckede
Kai
-
Hallo,
hast du mal die URL der Testtabelle?
/res/samples/test6.html in jedem (?) Mozilla-Ordner. Mozilla passt die Tabelle an, sobald der Resize-Vorgang zuende ist, konqueror dabei, Amaya und Opera eben falls sporaisch dabei - Netscape 4 zeichnet die Tabelle komplett neu, wenn der Resize vorbei ist, was mehrere Sekunden weißen Screen bedeutet!
zunächst mal überhaupt kein weisser Screen, und keine mehrere Sekunden!
Es gibt eine kurze Pause vorm Aufbau der zweiten Tabelle, die ganze Seite
dauert unter 1,5 Sekunden. IE 6 macht es ähnlich, aber fixer als der NN4.Es ist aber keine Website, es ist kein aussagefähiger Vergleich, da eine
nahezu leere Tabelle mit so komplexer Struktur einen extremen Sonderfall
darstellt.
Ich hab hier schonmal einen Geschwindigkeitstest JavaScript, IE5 kontra
u.a. NN4, gelesen, da war IE5 angeblich schneller als z.B. NN4, nur hatte
NN4 in der Zeit der Scriptabarbeitung schon die Seitenstruktur angelegt,
der Test war nicht aussagefähig, und die Seite komplett darstellen
inklusive Test-Script konnte der NN4 damals erheblich schneller als
andere Browser, schneller auch als der IE5 oder 5.5.
Jetzt zeigt sich hier dass Mozilla eine überkomplexe Tabellenstruktur ohne
Inhalt schnell -Gratulation- aufbauen kann, am Beispiel einer nur 5 kB
umfassenden Datei.
Es wäre übertrieben den Vergleich zum intelligenten Idioten zu machen,
aber die Seite des Selfforum zeigt NN4 schneller als Mozilla an, genauso
eine übliche wenig verschachtelte Tabelle von 400kB, es ist also eine etwas
einseitige Begabung bei Mozilla. Auf jeden Fall könnte man nun noch
gezielter fragen warum dann der Mozilla so langsam ist, zumal sich das
tendenziell verschärft wenn zukünftig tatsächlich auf Websites eher weniger
Tabellen zum Einsatz kommen sollten.Grüsse
Cyx23
-
hi
Es wäre übertrieben den Vergleich zum intelligenten Idioten zu machen,
aber die Seite des Selfforum zeigt NN4 schneller als Mozilla an, genauso
eine übliche wenig verschachtelte Tabelle von 400kB, es ist also eine etwas
einseitige Begabung bei Mozilla.das Selfforum ist hier in beiden gleich schnell da, spätestens bei einem Blick auf die Seite kommt dann das Todesurteil für Netscape4:
<img src="http://mywebpage.netscape.com/KaiL%20tuX/nn4.png" border=0 alt="">
(das graue da oben ist übrigens die gerade abgeschaltete Personal Toolbar, den Platzt kriegt man erst beim Restart zurück.) Die sinnlosen Buttons für "Shop", "Security" und der beim letzten mal auf einen 404er Führende "my Netscape" lassen sich übrigens nicht abschalten.Grüße aus Bleckede
Kai
-
Hallo,
Es wäre übertrieben den Vergleich zum intelligenten Idioten zu machen,
aber die Seite des Selfforum zeigt NN4 schneller als Mozilla an, genauso
eine übliche wenig verschachtelte Tabelle von 400kB, es ist also eine etwas
einseitige Begabung bei Mozilla.das Selfforum ist hier in beiden gleich schnell da, spätestens bei einem Blick auf die Seite kommt dann das Todesurteil für Netscape4:
mywebpage.netscape.com/KaiL%20tuX/nn4.pngdie Sch..Wartezeit auf den Server mit dem png??
(das graue da oben ist übrigens die gerade abgeschaltete Personal Toolbar, den Platzt kriegt man erst beim Restart zurück.) Die sinnlosen Buttons für "Shop", "Security" und der beim letzten mal auf einen 404er Führende "my Netscape" lassen sich übrigens nicht abschalten.
Was soll mir dieses Bild sagen, ausser dass es unter Linux oder BeOs gemacht wurde?
Vielleicht bin jetzt schon in Aufbruchstimmung, oder die nervende
Warterei auf das Bild -der server mywebpage.netscape.com ist offenbar
eine sehr sehr zähe Adresse- machts, aber worum geht es hier?Den Platz der gerade abgeschalteten Personal Toolbar gibts bei mir sofort
frei unter Netscape 4, den Button MyN.. gibts gar nicht, und einiges
lässt sich auch in der prefs.js von Netscape 4 einstellen, mag vielleicht
nicht alles allgemein bekannt sein.
Die security Info gibts auch beim Mozilla auch, rechts unten, also??Grüsse
Cyx23
-
hi
die Sch..Wartezeit auf den Server mit dem png??
nein, die Schriftdarstellung, die unter aller Sau ist. Sind Netscape 4 User da schon abgestumpft?
Grüße aus Bleckede
Kai
-
Hallo,
die Sch..Wartezeit auf den Server mit dem png??
nein, die Schriftdarstellung, die unter aller Sau ist.
meinst du das ernst oder langweilst du dich bereits und spielst
mit den Luinuxschriften rum?Jedenfalls kann ich die Schrift nicht nachvollziehen, die
Schrift ist normalerweise bei Netscape 4 ähnlich wie bei Mozilla.
Allgemein finde ich dabei die Darstellung des Nestcape 4 deutlich
angenehmer als bei Mozilla, das liegt aber auch an der häufigen
Rutscherei der Seiten beim Mozilla.Vielleicht solltest du dir Netscape 4.8 mal unter Windows anschauen,
du hast jedenfalls auf dem Screenshot eine etwas merkwürdige Schrift,
die muss ja irgendwo auf deinem System sein. So schaut das normalerweise
nicht aus, oder ist dir das merkwürdige png total vermatscht? Dann
musst du mir mal das Filterplugin verraten.Grüsse
Cyx23
-
hi
meinst du das ernst oder langweilst du dich bereits und spielst
mit den Luinuxschriften rum?nein, so sieht Netscape 4 unter Linux immer aus. Wo er diese Krankheit von einer Schriftart gefunden hat, interessiert mich allerdings auch nicht besonders, weil es eben nur einer von vielen Gründen ist, warum ich das Ding nicht benutzen würde.
Grüße aus Bleckede
Kai
-
Moin,
nein, so sieht Netscape 4 unter Linux immer aus.
So sieht Netscape 4 unter Linux _nicht_ immer aus. Die Schriftart hast du dir selber zuzuschreiben, bei mir ist (ohne dass ich die Einstellung geändert hätte) eine andere. Auch der Platz der Personal Toolbar wird sofort geräumt.
Die Geschwindigkeit bei der Forumsanzeige kann ich ohne Stoppuhr nicht vergleichen. Netscape gewinnt ein paar subjektive Punkte dadurch, dass er die Überschrift sofort anzeigt, Mozilla allerdings ein paar, weil er schon rendert, während er noch lädt, allerdings zeigt er deutlich länger einen weissen Schirm.
--
Henryk Plötz
Grüße von der Ostsee
-
-
-
-
-
-
-
-
-
-
-
Hi,
mir fielen noch für dynamische Seiten ein paar Sachen ein:
1. Wenn möglich Serverseitiges cachen von dymamischen Seiten, ich mache das in einem Redaktionssystem so, dass nach redaktionellen Änderungen sämtliche Seiten serverseitig erzeugt werden und als statisches HTMl abgelegt werden, statt bei jedem Aufruf per PHP neu generiert zu werden.
2. Bei dynamischen Seiten mit Datenbankanbindung möglichst Datenbankinteraktionen sparen, vieles kann man mit einem SQL Statement machen, was viel schneller ausgeführt wird, als wenn man Daten von der DB holt, in PHP o.ä. verarbeitet, um Ergebnisse wieder zurückzuschreiben oder so.
3. Überhaupt bewusst überlegen beim programmieren, wo man was ausführt (client, webserver, datenbankserver), und welche aktionen wieviel Leistung brauchen.
Gruss
Marko
-
hi
- Wenn möglich Serverseitiges cachen von dymamischen Seiten, ich mache das in einem Redaktionssystem so, dass nach redaktionellen Änderungen sämtliche Seiten serverseitig erzeugt werden und als statisches HTMl abgelegt werden, statt bei jedem Aufruf per PHP neu generiert zu werden.
dazu fällt mir auch gerade noch einer ein: nur die Seiten durch den PHP-Parser jagen, wo der auch was zu tun hat - eine beliebte Unsitte ist gleich jede Datei .php zu nennen...
Grüße aus Bleckede
Kai
-
Hi Kai,
dazu fällt mir auch gerade noch einer ein: nur die
Seiten durch den PHP-Parser jagen, wo der auch was
zu tun hat - eine beliebte Unsitte ist gleich jede
Datei .php zu nennen...... oder *.html durch SSI zu jagen ... :-(
Viele Grüße
Michael
-
-
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 werdenSo 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 -
Hi
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'..
Wenn dich soviele 'document.getElement' stören, kannst du ja folgendes machen:
gE=document.getElement;
gE('bla')...Gruss
Dr. Lecter