nicht angemeldet
Viele Thumbnails schneller laden und darstellen
0 0 
Matthias Apsel
0 0 
TS
1 
Gunnar Bittersmann
Viele Thumbnails schneller laden und darstellen
Hej!
Seit einiger Zeit bin ich weg von Flickr und veröffentliche Photos stattdessen auf meiner eigenen Webseite https://jeena.net/photos
Das klappt auch wunderbar nur wächst die index Seite mit allen Thumbnails stetig an. Aktuell sind es 135 Thumbnails die beim ersten betreten der Seite geladen werden müssen. Die einzelnen Thumbnails sind schon relativ klein, um die 8kb, aber das absetzen von 135 HTTP requests ist wohl das was dauert, und zwar zur Zeit unglaubliche 10 Sekunden.
Die browser öffnen ja nicht 135 verbindungen parallell auf sondern nur ein paar und wenn die abgearbeitet sind kommen die nächsten und das dauert.
Meine Konkrete Frage wäre wohl nach Ansätzen wie man das Problem angehen könnte, was ich nicht will ist die Thumbnails in ein CDN hochladen. Was ich auch nicht machen will ist alle bilder in ein einziges zu packen und dann mit CSS zu positionieren, denn dann verliert man den Vorteil dass die oberen Bilder schon angezeigt werden während die unteren die noch ausserhalb des Blickfeldes sind noch geladen werden. Paging wo man manuell auf die Nächste Seite kommt will ich auch vermeiden, denn die Thumbnails können relativ gut und platzsparend scrollbar dargestellt werden.
ciao, Jeena
-
Hallo jeena,
Das klappt auch wunderbar nur wächst die index Seite mit allen Thumbnails stetig an. Aktuell sind es 135 Thumbnails die beim ersten betreten der Seite geladen werden müssen. Die einzelnen Thumbnails sind schon relativ klein, um die 8kb, aber das absetzen von 135 HTTP requests ist wohl das was dauert, und zwar zur Zeit unglaubliche 10 Sekunden. [...] Meine Konkrete Frage wäre wohl nach Ansätzen wie man das Problem angehen könnte, was ich nicht will ist die Thumbnails in ein CDN hochladen. Was ich auch nicht machen will ist alle bilder in ein einziges zu packen und dann mit CSS zu positionieren, denn dann verliert man den Vorteil dass die oberen Bilder schon angezeigt werden während die unteren die noch ausserhalb des Blickfeldes sind noch geladen werden. Paging wo man manuell auf die Nächste Seite kommt will ich auch vermeiden, denn die Thumbnails können relativ gut und platzsparend scrollbar dargestellt werden.
Naja, du hast fast alle Mechanismen abgelehnt, die man verwenden könnte. Das einzige, was IMHO jetzt noch übrig bleibt ist Caching, aber das verwendest du ja auch schon. Mir fällt da kein weiterer Mechanismus ein, wie du das beschleunigen könntest, es muss halt schon durch die Leitung kommen.
LG,
CK -
Hallo jeena,
Was ich auch nicht machen will ist alle bilder in ein einziges zu packen und dann mit CSS zu positionieren, denn dann verliert man den Vorteil dass die oberen Bilder schon angezeigt werden während die unteren die noch ausserhalb des Blickfeldes sind noch geladen werden.
Du könntest aber immer
kBilder in ein einziges packen.EDIT Du könntest deinem
.hfeednoch einpadding-bottomgeben, sodass man auch in der letzten Zeile die Beschriftungen vernünftig lesen kann.Bis demnächst
Matthias--
Signaturen sind bloed (Steel) und Markdown ist mächtig. -
Hallo Jeena
Base64 Encoder wäre noch eine Möglichkeit. Bei der Bildgröße können die jepgs auch stärker komprimiert werden.
gr qx
-
Hallo Richard,
Seit einiger Zeit bin ich weg von Flickr und veröffentliche Photos stattdessen auf meiner eigenen Webseite https://jeena.net/photos
Das klappt auch wunderbar nur wächst die index Seite mit allen Thumbnails stetig an. Aktuell sind es 135 Thumbnails die beim ersten betreten der Seite geladen werden müssen. Die einzelnen Thumbnails sind schon relativ klein, um die 8kb, aber das absetzen von 135 HTTP requests ist wohl das was dauert, und zwar zur Zeit unglaubliche 10 Sekunden.
Die browser öffnen ja nicht 135 verbindungen parallell auf sondern nur ein paar und wenn die abgearbeitet sind kommen die nächsten und das dauert.
Die Thumbs haben durchaus Größen zwischen 20kB und 45kB. Das ist bei ca. 140 Stück kein Pappenstiel mehr. 4,5MByte wollen erst einmal übertragen werden. Bei der dargestellten Größe kannst Du durchaus auf unter 5kB pro Thumb kommen und dann hast Du nur noch 700kByte. Das liest sich dann schon besser. um die ca. 1s Latenzverlust (160 requests / 8 Connections * 50ms) wirst Du nicht herum kommen.
BTW: ich habe mir das gestern Abend als Erstaufruf auf einem Tablet per WLAN und DSL 25.000 angeschaut und das Laden ging angenehm und zumutbar schnell. Ich fand sogar, dass der leicht verzögerte Aufbau der Bildergalerie ein netter Effekt ist. Aller 50ms ein Bild würde auch genügen. Und von Aufruf zu Aufruf verwürfelt.
Aber ich würde zum Betrachten mit Mobile- bzw. Touch-Device einen kleinen Link in einer Ecke des Bildes anbringen, der den Begleittext öffnet, bis man ihn bewusst wieder schließt, oder das Bild lädt.
Grüße nach SE
TS -
@@jeena
aber das absetzen von 135 HTTP requests ist wohl das was dauert, und zwar zur Zeit unglaubliche 10 Sekunden.
Mit HTTP/2 sollte sich das Problem erledigen.
Was ich auch nicht machen will ist alle bilder in ein einziges zu packen und dann mit CSS zu positionieren, denn dann verliert man den Vorteil dass die oberen Bilder schon angezeigt werden während die unteren die noch ausserhalb des Blickfeldes sind noch geladen werden.
Nicht jeder Kompromiss ist ein fauler. Zwischen einzelnen Bilddateien (also n Dateien für n Bilder) und einer Datei mit allen n Bildern liegt ja noch ⌈n/k⌉ Dateien mit jeweils k Bildern (wie Matthias schon sagte).
Wobei k = 24 ein guter Wert sein dürfte: teilbar durch 2, 3, 4, 6, 8, 12. Wenn man als Anzahl der Bilder in einer Zeile einen Teiler von k wählt (bei responsive design je nach Viewportgröße verschiedene), werden immer komplette Zeilen angezeigt und die Seite sieht beim Aufbau nicht nach Stückwerk aus.
Als progressive enhancement kann man initial nur den ersten Block laden und den Rest mit JavaScript nachladen – bei Bedarf, wenn (bzw. kurz bevor) die Zeile in den Viewport gescrollt wird.
LLAP 🖖
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Mit HTTP/2 sollte sich das Problem erledigen.
Hehe, ja, Zukunftsmusik!
Nicht jeder Kompromiss ist ein fauler. Zwischen einzelnen Bilddateien (also n Dateien für n Bilder) und einer Datei mit allen n Bildern liegt ja noch ⌈n/k⌉ Dateien mit jeweils k Bildern (wie Matthias schon sagte). Wobei k = 24 ein guter Wert sein dürfte: teilbar durch 2, 3, 4, 6, 8, 12.
Hm ja das klingt nach einem sinnvollen Kompromiss, ich werde versuchen das mal zu implementieren.
-
@@Jeena_
Mit HTTP/2 sollte sich das Problem erledigen. Hehe, ja, Zukunftsmusik!
Die Zukunft beginnt jetzt.
LLAP 🖖
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Tach,
Mit HTTP/2 sollte sich das Problem erledigen. Hehe, ja, Zukunftsmusik!
Die Zukunft beginnt jetzt.
in dieser Liste fehlen die entscheidenen Komponenten nämlich die Webserver, zumindest die drei häufigst genutzten können es noch nicht.
mfg
Woodfighter
-
-
-