nicht angemeldet
Performance beim Kacheln von kleinen Bildern
Hallo,
nehmen wir an, ich habe für meinen Seitenhintergrund ein Bild, welches ziemlich klein ist (2px*2px). Dieses muss beim Seitenaufruf vom Browser heruntergeladen werden und wird dann horizontal und vertikal gekachelt. Ich könnte das Bild auch vergrößern (20px*20px). Das Bild würde etwas größer werden, würde aber noch genau gleich aussehen, weil ich einfach das 2px*2px kleine Bild, solange nebeneinander gereiht habe, bis es 20px*20px groß ist. Nun stellt sich mir die Frage, ob der Browser nun nicht mehr so schwer schufften muss, weil er nicht so viel kacheln muss. :)
Weiß das jemand von euch?
Leider kann ich das bei mir nicht testen. (PC ist einfach zu schnell, um einen Unterschied feststellen zu können.)
-
hallo,
Nun stellt sich mir die Frage, ob der Browser nun nicht mehr so schwer schufften muss
Muß er gewiß nicht, weil kein Browser die Tippfehler beachtet, die dir unterlaufen - kein Browser weiß, was "schufften" ist. Daher kann er das gar nicht - egal, ob schwer oder leicht oder in der Mittelklasse *g*
Leider kann ich das bei mir nicht testen. (PC ist einfach zu schnell, um einen Unterschied feststellen zu können.)
Vermutlich wäre meiner ebenfalls zu schnell. Aber schaun 'mer mal: dein Hintergrundbild ist 2x2 Pixel groß. Was hast du denn dann auch noch auf der 2x2Pixel großen "Site" untergebracht?
Und wenn du es "kacheln" lassen möchtest: du weißt doch, daß dein Seitenbesucher sich erstmal _jede_ Grafik in seinen Cache holen muß. Dann ist es doch völlig wurscht, wie oft dein großartig winziges Bildchen wiederholt werden muß, der Browser deines Seitenbesuchers bedient sich seines Cache und muß dein Bildchen nicht dreitausendmal aus dem "Netz" ziehen.
Grüße aus Berlin
Christoph S.
-
hallo,
Nun stellt sich mir die Frage, ob der Browser nun nicht mehr so schwer schufften muss
Muß er gewiß nicht, weil kein Browser die Tippfehler beachtet, die dir unterlaufen - kein Browser weiß, was "schufften" ist. Daher kann er das gar nicht - egal, ob schwer oder leicht oder in der Mittelklasse *g*
Deutet das *g* noch Ironie an, oder ist Deine Antwort ein ins Lächerliche mutierter, besserwisserischer Sarkasmus? Ich weiß es nicht, jedem das Seine.
Leider kann ich das bei mir nicht testen. (PC ist einfach zu schnell, um einen Unterschied feststellen zu können.)
Vermutlich wäre meiner ebenfalls zu schnell. Aber schaun 'mer mal: dein Hintergrundbild ist 2x2 Pixel groß. Was hast du denn dann auch noch auf der 2x2Pixel großen "Site" untergebracht?
Was soll diese Fragestellung?
Und wenn du es "kacheln" lassen möchtest: du weißt doch, daß dein Seitenbesucher sich erstmal _jede_ Grafik in seinen Cache holen muß. Dann ist es doch völlig wurscht, wie oft dein großartig winziges Bildchen wiederholt werden muß, der Browser deines Seitenbesuchers bedient sich seines Cache und muß dein Bildchen nicht dreitausendmal aus dem "Netz" ziehen.
Die Frage ist alles andere als dumm. Sicherlich ist mehr Rechenaufwand nötig, zu kacheln statt einen fixen Hintergrund darzustellen. Aber der Flaschenhals ist hier nicht die Prozessorauslastung, sondern die Übertragung per http. Damit ist eine gekachelte Grafik besser, auch wenn eine größere Grafik nur einmal geladen werden müßte und dann im Cache landet und damit ohne weitere Rechenschritte aus dem Cache beliebig oft in anderen Seiten eingebunden werden kann. Die Seite wird beim ersten Mal schneller geladen, was allein schon wegen Surfer mit ISDN- oder Analog-Modems so gemacht werden sollte.
-
hallo,
Deutet das *g* noch Ironie an, oder ist Deine Antwort ein ins Lächerliche mutierter, besserwisserischer Sarkasmus?
Ja.
Die Frage ist alles andere als dumm.
Du weißt doch, daß es keine "dummen" Fragen gibt?
Aber der Flaschenhals ist hier nicht die Prozessorauslastung, sondern die Übertragung per http.
Nein, ist es nicht. Lies bitte richtig nach, was ich dir speziell zur Bedienung des Browsers aus seinem Cache geschrieben habe.
Grüße aus Berlin
Christoph S.
-
hallo,
Deutet das *g* noch Ironie an, oder ist Deine Antwort ein ins Lächerliche mutierter, besserwisserischer Sarkasmus?
Ja.
»»
Was heißt "ja"? Sarkasmus?Die Frage ist alles andere als dumm.
Du weißt doch, daß es keine "dummen" Fragen gibt?
Diese Frage - soll ich sie rhetorisch verstehen - scheint mir dumm, weil unpassend. Im übrigen gibt es aber sehr dämliche Antworten, die nur der Selbstbeweihräucherung dienen.
Aber der Flaschenhals ist hier nicht die Prozessorauslastung, sondern die Übertragung per http.
Nein, ist es nicht.
Butter bei die Fische, wieso nicht?
Lies bitte richtig nach, was ich dir speziell zur Bedienung des Browsers aus seinem Cache geschrieben habe.
Wieso mir geschrieben?
-
hallo,
Was heißt "ja"? Sarkasmus?
Nein.
Du weißt doch, daß es keine "dummen" Fragen gibt?
Diese Frage - soll ich sie rhetorisch verstehen - scheint mir dummSchade.
Aber der Flaschenhals ist hier nicht die Prozessorauslastung, sondern die Übertragung per http.
Nein, ist es nicht.
Butter bei die Fische, wieso nicht?Weil diese Übertragung für dein winziges Bildchen nur ein einzigesmal passiert - dann liegt es im Browsercache. Braucht es der Browser des Besuchers deiner Seite mehrfach, fordert er es nicht mehr über HTTP an, sondern holt es sich aus seinem Cache - falls du nicht irgendwas gezaubert hast, was diesen Umgang mit Sourcen manipiuliert.
Grüße aus Berlin
Christoph S.
-
hallo,
Was heißt "ja"? Sarkasmus?
Nein.
Gut.
Aber der Flaschenhals ist hier nicht die Prozessorauslastung, sondern die Übertragung per http.
Nein, ist es nicht.
Butter bei die Fische, wieso nicht?Weil diese Übertragung für dein winziges Bildchen nur ein einzigesmal passiert - dann liegt es im Browsercache. Braucht es der Browser des Besuchers deiner Seite mehrfach, fordert er es nicht mehr über HTTP an, sondern holt es sich aus seinem Cache - falls du nicht irgendwas gezaubert hast, was diesen Umgang mit Sourcen manipiuliert.
Ich habe ja schon beschrieben, daß es beim ersten Aufruf der Seite geladen werden muß. Das ist der Flaschenhals, durch den es je nach Größe nur langsam geht. Ein großes Hintergrundbild, viele Multimedia-Elemente, lange Ladedauer, ein überlasteter Server, weil alle Webpräsenzen des Servers nicht auf schlanke Seiten achten - und weg bin ich trotz DSL, bevor mir die tolle Seite mit tollem Hintergrundbild vollständig präsentiert wurde, und habe die schlanke Seite der Konkurrenz schon vollständig im nächsten Tab.
Nächstes Problem: Caching läßt sich abschalten, und zwar client- wie auch serverseitig per header(). Und nu'?
Der logische Schluß muß sein, große BG-Grafiken zu vermeiden. Das gilt auch heute noch trotz DSL 16000.
-
-
-
-
-
-
Moin!
nehmen wir an, ich habe für meinen Seitenhintergrund ein Bild, welches ziemlich klein ist (2px*2px). Dieses muss beim Seitenaufruf vom Browser heruntergeladen werden und wird dann horizontal und vertikal gekachelt. Ich könnte das Bild auch vergrößern (20px*20px). Das Bild würde etwas größer werden, würde aber noch genau gleich aussehen, weil ich einfach das 2px*2px kleine Bild, solange nebeneinander gereiht habe, bis es 20px*20px groß ist. Nun stellt sich mir die Frage, ob der Browser nun nicht mehr so schwer schufften muss, weil er nicht so viel kacheln muss. :)
Es entspricht realer Beobachtung, dass Browser mit Hintergrundbildern im Winzigformat mehr Arbeit haben und Dinge langsamer funktionieren, als wenn Bilder in größeren Formaten verwendet werden.
Wenn ich z.B. ein Streifen-Hintergrundbild (vertikal oder horizontal) erstelle, lege ich das Bild üblicherweise 8 oder 16 Pixel breit an (8 Pixel ist die Breite einer Kompressionseinheit im JPEG-Format, auch wenn ich GIF oder PNG verwende - was anderes als Vielfache von 8 sind nur nötig, wenn das Bild das erfordert, weil z.B. ein 10 Pixel breites Muster dargestellt werden muß), und entsprechend so hoch, wie nötig.
Im Gegensatz zum denkbaren 1x1px-Hintergrund hat ein Browser bei einem 8x8px-Hintergrund 64 mal weniger Bilder zu kacheln. Das macht sich bei langsameren Rechnern durchaus bemerkbar, vor allem auch beim Scrollen oder bei Animationen. Noch größere Bildformate sind logischerweise entsprechend ressourcenschonender, allerdings muß man das gegenüber der Dateigröße abwägen.
- Sven Rautenberg
--
"Love your nation - respect the others." -
hi,
nehmen wir an, ich habe für meinen Seitenhintergrund ein Bild, welches ziemlich klein ist (2px*2px). Dieses muss beim Seitenaufruf vom Browser heruntergeladen werden und wird dann horizontal und vertikal gekachelt. Ich könnte das Bild auch vergrößern (20px*20px). Das Bild würde etwas größer werden, würde aber noch genau gleich aussehen, weil ich einfach das 2px*2px kleine Bild, solange nebeneinander gereiht habe, bis es 20px*20px groß ist. Nun stellt sich mir die Frage, ob der Browser nun nicht mehr so schwer schufften muss, weil er nicht so viel kacheln muss.
Ja.
Einen wirklichen Beleg kann ich dir dafür nicht liefern - aber meiner subjektiven Erfahrung nach ist dem so. (Opera reagiert in der Hinsicht besonders heftig, insb. wenn auch noch Alphatransparenz hinzukommt.)
Macht sich dann auf etwas schwächeren Rechnern oftmals auch insb. beim Scrollen bemerkbar.Den angesprochenen "Flaschenhals" bei der HTTP-Übertragung kannst du absolut vernachlässigen.
Dein 2*2px-Bild kann maximal vier unterschiedlich farbige Pixel haben, also 4*24 Bit (Farbtiefe) = 4 * 3 Byte = 24 Byte an reinen Bildinformationen.
Nehmen wir da mal noch 1 KB an Grundinformationen des Bildformates und sonstigen Meta-Daten hinzu, und noch mal pauschal 1 KB für den reinen HTTP-Request, sind wir bei ca. 2 KB.
Wenn du jetzt ein 20*20px-Bild nimmst, sind das ((20*20)-(2*2)) * 3 = 1188 Byte mehr - aber noch ohne Komprimierung. Wenn du ein 2*2px großes Motiv einfach nur durch Wiederholung auf 20*20px Größe bringst, lässt sich das ziemlich gut komprimieren - es dürften also effektiv vermutlich nur ein paar Dutzend Byte an Bildinformation übrigbleiben.
Die paar Byte machen aber bei einem HTTP-Request den Kohl nicht fett.
Die Rechenleistung, die der Browser zum Nebeneinanderlegen des Bildmotivs braucht, aber u.U. schon eher.Deshalb würde ich auch eher noch ein größeres Bild draus machen, 100*100 oder meinetwegen auch 200*200px.
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }