/HTTP: große Bilder runterskalieren oder lieber als Thumb laden?

[Eddie]

Hallo allerseits,

mal angenommen, ich habe auf einer Seite 50 Bilder: bei jedem davon kann der Benutzer per JavaScript zwischen der Thumb- und der Normalansicht umschalten. Für unser Beispiel sei jedes Thumbnail 10Kb groß, und jedes Bild in Normalgröße 100Kb.

Jetzt habe ich also Wahl:
a) ich lade alle Bilder sowohl als Thumb als auch in Normalgröße: dann hätte ich 100 statt 50 HTTP-Requests, und insg. Daten im Umfang von ca. 5,5 MB.
b) oder ich verwende für die Thumbs auch die Normalgröße, skaliere sie aber per CSS-styles runter. Dann hätte ich nur 50 Requests und 5000MB Daten (also hier kein großer Unterschied).

Leidet bei Variante b) die Performance/der Arbeitsspeicher des Clients? Immerhin läge ja jedes Thumbnail bei 100KB. Ich würde also vermuten, dass der Client in diesem Fall 10MB Speicher bereitstellen müsste statt 5,5MB.

Wie würdet ihr das bewerten?

Eddie

[mrjerk]

Hallo,
Wieso möchtest Du alle Bilder in der Großansicht laden? Möglicherweise will der Benutzer die gar nicht alle sehen.

Ich würde Variante a) bevorzugen, die großen Bilder aber erst "on demand" laden, wenn der User die Groß-Ansicht aufruft.

Wenn Du willst, dass das Öffnen der großen Ansicht ohne Verzögerung passiert, kannst Du ja die großen Bilder per JavaScrpt vor laden, sobald die komplette Seite gelaen ist (onload ist Dein Freund).

Ich würde aber den User nicht gleich zu Anfang mit 5 MB Daten bombardieren, da er sonst sehr lange warten muss, bis er überhaupt was sieht.

Viele Grüße,
Jörg

[Edgar Ehritt]

Hallo Eddie,

wichtig ist hier das tatsächliche Verhalten der Nutzer nicht aus den Augen zu verlieren. Im besten Fall hast Du für Dein Vorhaben eine eigene subdomain und kannst durch Log-Daten etwas Statistik betreiben. Leider ist es so ohne weiteres nicht zu beantworten, was für Dich Die Lösung ist. Wären es nur 10 bis 20 Bilder sollte jedenfalls keine thumbnails verwendet und die Bilder skaliert werden.

Laut Titel hast Du aber die eigentliche Dimension Deines Problems auch auf der HTTP-Ebene erkannt. Da kannst unter der Voraussetzung, dass alle thumbnails selben Abmaßes sind, Du einen kleinen Trick verwenden, um die Daten gleich in zweier Hinsicht zu reduzieren. Dazu schnappst Du Dir ein Grafikprogramm Deiner Wahl und packst alle thumbnails in eine einzige Datei. Plaziert wird hier ein Bild immer wieder mit clip. So werden in Deinem Beispiel zum einen aus 100 requests ein einziger, zum anderen werden aufgrund des einen großen Bildes die Kompressionsalgorithmen des gewählten Bildformats besser arbeiten und die Datenmenge wird aller Voraussicht nach geringer als die der 100 einzelnen Bilder sein.

Ohne Statistik würde ich nach zweiter Skizze vorgehen.

Gruß aus Berlin!
eddi

[Malcolm Beck´s]

مرحبا eddi

Wären es nur 10 bis 20 Bilder sollte jedenfalls keine thumbnails verwendet und die Bilder skaliert werden.

Könntest du das bitte ein wenig näher erläutern?
Wenn ich auf dieser Seite so vorgehen würde, hätte ich mal eben ein paar hundert kb auf jeder Seite, die geladen wird, wäre das nicht eher Suboptimal?

Da kannst unter der Voraussetzung, dass alle thumbnails selben Abmaßes sind, Du einen kleinen Trick verwenden,

CSS-Sprites kann man doch immer verwenden, auch wenn die Bilder unterschiedlich sind (Nachteil ist nur die Rechnerei der background-position).

mfg

[Edgar Ehritt]

Hallo Engin,

مرحبا eddi

auch als Neuköllner, muss ich gestehen, kann ich immer noch kein Arabisch. ;)

Wären es nur 10 bis 20 Bilder sollte jedenfalls keine thumbnails verwendet und die Bilder skaliert werden.

Könntest du das bitte ein wenig näher erläutern?
Wenn ich auf dieser Seite so vorgehen würde, hätte ich mal eben ein paar hundert kb auf jeder Seite, die geladen wird, wäre das nicht eher Suboptimal?

Vom Aspekt der des potenziellen overheads ist das nicht nur suboptimal. Jedoch hat es den Vorteil, dass die Bilder sofort per Klick verfügbar sind und nicht erst geladen werden müssen. So lassen sich Zeitnahe hover-Effekte realisieren. Dem gegenüber steht die Ladezeit des Dokuments, was sich erheblich verzögert. Bei Bildern von um die 1 MB halte ich das aber für vertretbar.

In wieweit das für Deine Galerie, die erheblich mehr las die gesetzte 20er-Grenze an Bildern hat, nützlich ist, müsste man sich im Detail ansehen. Jedenfalls ist mir schon mal bei den kurzen Tests aufgefallen, dass per Klick nicht nur ein großes Bild geladen wird. Dort scheint also der Gleiche Gedanke, dem Nutzer mit Geschwindigkeit zu schmeicheln, Pate der Programmierung gewesen zu sein.

Da kannst unter der Voraussetzung, dass alle thumbnails selben Abmaßes sind, Du einen kleinen Trick verwenden,

CSS-Sprites kann man doch immer verwenden, auch wenn die Bilder unterschiedlich sind (Nachteil ist nur die Rechnerei der background-position).

Du hättest dann aber im zusammengefassten Bild Bereiche, die keine Informationen für die Anzeige enthalten. Diese stellen aber auch Daten dar, die erstmal an den client gesendet werden müssen.

Gruß aus Berlin!
eddi

[Malcolm Beck´s]

مرحبا eddi

auch als Neuköllner, muss ich gestehen, kann ich immer noch kein Arabisch. ;)

Schade, dann verstehst du das hier ja gar nicht (ich eigentlich auch nicht, ist aber trotzdem Geil :)).

Jedoch hat es den Vorteil, dass die Bilder sofort per Klick verfügbar sind und nicht erst geladen werden müssen. So lassen sich Zeitnahe hover-Effekte realisieren.

Das stimmt natürlich.

Bei Bildern von um die 1 MB halte ich das aber für vertretbar.

Ich komme schon bei 200 kb für eine einzelne Seite ins Schwitzen :)
1 MB ist ja ziemlich Happig, kann man das einem Nutzer wirklich zumuten?

Dort scheint also der Gleiche Gedanke, dem Nutzer mit Geschwindigkeit zu schmeicheln, Pate der Programmierung gewesen zu sein.

Das ist bei mir eigentlich immer der Fall; es kann ja sein, dass ein Nutzer nur ein Bild in der Grossansicht sehen will.
Ich hatte es auch mal mit runter skalierten Bildern getestet, aber da ist mir die Ladezeit definitiv viel zu hoch.

CSS-Sprites

Du hättest dann aber im zusammengefassten Bild Bereiche, die keine Informationen für die Anzeige enthalten. Diese stellen aber auch Daten dar, die erstmal an den client gesendet werden müssen.

Bei CSS-Sprites liegt der Fokus wohl auch eher auf den Requests, die damit verringert werden.
Wobei, wenn man Icons hat, deren ausmasse Absolut angegeben werden können (width und height), kann man auch hier sehr gut optimieren.
http://de.selfhtml.org/css/eigenschaften/positionierung.htm#clip@title=Clip kannte ich noch nicht, das nehme ich bei Gelegenheit mal unter die Lupe.

mfg

[Edgar Ehritt]

Re:

Ich komme schon bei 200 kb für eine einzelne Seite ins Schwitzen :)
1 MB ist ja ziemlich Happig, kann man das einem Nutzer wirklich zumuten?

Bei den üblichen 2000 kBit Verträgen ist das binnen 4 Sekunden auf der Platte. Aber auch wenn es länger dauert - das Dokument an sich ist bis dahin schon längst gerendert und wird angezeigt. Nur die Bilder trudeln nach und nach ein.

Ich hatte es auch mal mit runter skalierten Bildern getestet, aber da ist mir die Ladezeit definitiv viel zu hoch.

Wenn man will, kann man auch per Javascript einen Ladebalken basteln, um den Nutzer, sozusagen, bei der stetig wachsenden Stange zu halten.

Bei CSS-Sprites liegt der Fokus wohl auch eher auf den Requests, die damit verringert werden.
Wobei, wenn man Icons hat, deren ausmasse Absolut angegeben werden können (width und height), kann man auch hier sehr gut optimieren.
http://de.selfhtml.org/css/eigenschaften/positionierung.htm#clip@title=Clip kannte ich noch nicht, das nehme ich bei Gelegenheit mal unter die Lupe.

Bei 20 Bildern sind das grob 12 kB, die allein für HTTP-Header draufgehen. (HTTP ist tatsächlich ein sehr klatsch- und tratschsüchtiges Protokoll, was bloß noch von XML-Protokollen übertroffen wird, die sich zudem auf HTTP draufsatteln.) Rechnet man dann ein thumbnail zu 2,5 kB und ein großes Bild zu 60 kB (was über den Daumen gepeilt auf Deine Galerie zutrifft), würde man nach meinem Vorschlag nur dann plus machen, wenn ein Nutzer _alle_ Bilder betrachtet. Wie geschrieben, hat man das Transfervolumen im Blick, ist das alles andere als sinnvoll.

Wenn man aber bedenkt, dass das Skalieren von Bildern in Flash oder auch in SVG ganz normal ist, ist der sinnlose Frevel allgegenwärtig.

Es gibt aber auch noch einen anderen Aspekt, denn ich mir aufgehoben hatte: Moderne Server und Browser nutzen pipelining. Dabei werden mehrere request, ohne den response abzuwarten, hintereinander gesendet werden. Das spart etwas Zeit beim Laden der Bilder in der TCP-Schicht, als wenn man (z. B. per Klick) jedes Bild einzeln beim Server nachfragt.

Gruß aus Berlin!
eddi

[Malcolm Beck´s]

مرحبا

Bei 20 Bildern sind das grob 12 kB, die allein für HTTP-Header draufgehen.

Ich erstelle die Thumbs mittels imagemagick und einer Batch-Datei, dass laut Manual die Header grösstenteils entfernt.
Wie könnte ich das messen?

Rechnet man dann ein thumbnail zu 2,5 kB und ein großes Bild zu 60 kB (was über den Daumen gepeilt auf Deine Galerie zutrifft), würde man nach meinem Vorschlag nur dann plus machen, wenn ein Nutzer _alle_ Bilder betrachtet.

Das ist meistens der Fall, wenn ich mir die Logs so ansehe (meistens, nicht immer). Wobei besagte Seite aber auch nicht so stark besucht ist, dass es nicht ins Gewicht fällt.

Moderne Server und Browser nutzen pipelining. Dabei werden mehrere request, ohne den response abzuwarten, hintereinander gesendet werden.

Moderne Browser machen das ja so weit ich weiss Automatisch, wie kann ich aber feststellen, ob mein Server das macht? Gibt es eine möglichkeit, bei gemietetem Webspace das herauszufinden?

mfg

[ChrisB]

Hi,

Bei 20 Bildern sind das grob 12 kB, die allein für HTTP-Header draufgehen.

Ich erstelle die Thumbs mittels imagemagick und einer Batch-Datei, dass laut Manual die Header grösstenteils entfernt.

Edgar spricht von den HTTP-Headern, die beim Anfordern des Bildes vom Webserver anfallen.

Du meinst ganz andere "Header".

MfG ChrisB

[Edgar Ehritt]

Re:

Bei 20 Bildern sind das grob 12 kB, die allein für HTTP-Header draufgehen.
Ich erstelle die Thumbs mittels imagemagick und einer Batch-Datei, dass laut Manual die Header grösstenteils entfernt.
Wie könnte ich das messen?

ChrisB hatte ja schon darauf hingewiesen, dass wir hier vermutlich von unterschiedlichen Headern reden. Um Header in den Grafikdateien auszulesen, reicht bereits ein einfacher Texteditor aus. Automatisiert auf dem Server kann z. B. die exif-Erweiterung PHPs genutzt werden. Es gibt aber auch noch andere Werkzeuge. Näheres kann Dir hier Wikipedia bzw. exif.org vermitteln.

Rechnet man dann ein thumbnail zu 2,5 kB und ein großes Bild zu 60 kB (was über den Daumen gepeilt auf Deine Galerie zutrifft), würde man nach meinem Vorschlag nur dann plus machen, wenn ein Nutzer _alle_ Bilder betrachtet.
Das ist meistens der Fall, wenn ich mir die Logs so ansehe (meistens, nicht immer). Wobei besagte Seite aber auch nicht so stark besucht ist, dass es nicht ins Gewicht fällt.

Daher ist ja mein Tipp bei überschaubarer Anzahl von Bildern, auf thumbnails zu verzichten. ;)

Moderne Server und Browser nutzen pipelining. Dabei werden mehrere request, ohne den response abzuwarten, hintereinander gesendet werden.
Moderne Browser machen das ja so weit ich weiss Automatisch, wie kann ich aber feststellen, ob mein Server das macht? Gibt es eine möglichkeit, bei gemietetem Webspace das herauszufinden?

Wenn der Apache als Webserver genutzt wird, kannst Du davon ausgehen, dass pipelining unterstützt wird. Speziell testen kann man das mit folgendem Script:

#!/home/eddi/bin/php  
<?php  
$host="localhost";  
$port=80;  
  
if($c=stream_socket_client("tcp://$host:$port",$e_no,$e_msg,5)){  
  
	$host=($port==80)?$host:$host.':'.$port;  
  
	fwrite($c,"GET / HTTP/1.1\r\n");  
	fwrite($c,"Host: $host\r\n");  
	fwrite($c,"Connection: keep-alive\r\n");  
	fwrite($c,"\r\n");  
	fwrite($c,"GET / HTTP/1.1\r\n");  
	fwrite($c,"Host: $host\r\n");  
	fwrite($c,"Connection: close\r\n");  
	fwrite($c,"\r\n");  
	fpassthru($c);  
}  
?>

Gruß aus Berlin!
eddi

[Malcolm Beck´s]

مرحبا

Automatisiert auf dem Server kann z. B. die exif-Erweiterung PHPs genutzt werden. Es gibt aber auch noch andere Werkzeuge. Näheres kann Dir hier Wikipedia bzw. exif.org vermitteln.

Danke für die Links. Exif kannte ich noch nicht, werde bei der nächsten Gelegenheit mal die exif_thumbs unter die Lupe nehmen, die sehen Interessant aus.
Stehe derzeit so unter Zeitdruck, dass ich kaum zum Antworten hier komme.

Daher ist ja mein Tipp bei überschaubarer Anzahl von Bildern, auf thumbnails zu verzichten. ;)

Die Grösse der Thumbs ist so gering, dass ich der versuchung unterlegen bin :)
Imagemagick ist Geil, ich habe mit keinem Programm so kleine Thumbs hingekriegt, daher lasse ich es wohl vorerst. Zumal die erstellung mit meiner Batch-Datei Sekunden dauert und die Qualität für die Grösse sehr gut ist.

Wenn der Apache als Webserver genutzt wird, kannst Du davon ausgehen, dass pipelining unterstützt wird. Speziell testen kann man das mit folgendem Script:

Danke für das Script, nur, was hat das hier nun zu bedeuten?
Auf meiner Lokalen Maschine bekomme ich

HTTP/1.1 302 Found  
Date: Wed, 17 Mar 2010 02:09:39 GMT  
Server: Apache/2.2.14 (Win32) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l mod_autoindex_color mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.1  
Location: http://localhost/xampp/  
Content-Length: 0  
Keep-Alive: timeout=5, max=100  
Connection: Keep-Alive  
Content-Type: text/html  
  
HTTP/1.1 302 Found  
Date: Wed, 17 Mar 2010 02:09:39 GMT  
Server: Apache/2.2.14 (Win32) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l mod_autoindex_color mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.1  
Location: http://localhost/xampp/  
Content-Length: 0  
Connection: close  
Content-Type: text/html

Was läuft Online schief?

mfg

[Edgar Ehritt]

Re:

Daher ist ja mein Tipp bei überschaubarer Anzahl von Bildern, auf thumbnails zu verzichten. ;)

Die Grösse der Thumbs ist so gering, dass ich der versuchung unterlegen bin :)

Siehst Du, da hast Du wieder einen ganz anderen Aspekt ausfindig gemacht, an den ich gar nicht mal gedacht habe, die eingebetteten thumbnauls zu nutzen.

Danke für das Script, nur, was hat das hier nun zu bedeuten?

#!/home/eddi/bin/php  
<?php  
$host="localhost";  
$port=80;  
  
if($c=stream_socket_client("tcp://$host:$port",$e_no,$e_msg,5)){  
  
        $host=($port==80)?$host:$host.':'.$port;  
  
        fwrite($c,"GET / HTTP/1.1\r\n");  
        fwrite($c,"Host: $host\r\n");  
        fwrite($c,"Connection: keep-alive\r\n");  
        fwrite($c,"\r\n");  
  
        # Erster request:  
  
        # GET / HTTP/1.1  
        # Host: dj-tut.de  
        # Connection: keep-alive  
  
        fwrite($c,"GET / HTTP/1.1\r\n");  
        fwrite($c,"Host: $host\r\n");  
        fwrite($c,"Connection: close\r\n");  
        fwrite($c,"\r\n");  
  
        # Zweiter request:  
  
        # GET / HTTP/1.1  
        # Host: dj-tut.de  
        # Connection: close  
  
        fpassthru($c);  
  
        # Erst jetzt werden alle Daten vom Server ausgelesen, während man bei  
        # gewöhnlichen requests eine Anfrage senden würde, sofort den response  
        # auslesen würde und die Verbindung schließen würde.  
}  
?>

Was läuft Online schief?

Auch dort ist alles in Ordnung. Wie unter http://dj-tut.de/infgone.php zu sehen ist, werden zwei HTTP-Header-Blöcke und die ausgelieferten Dokumente bezogen. Local hast Du im Unterschied dazu für die abgefragte Ressource "/" eine Weiterleitung auf http://localhost/xampp/ eingerichtet, die von keinem Dokument begleitet wird (HTTP-Header "Content-Length: 0" des jeweiligen response). Es sind also nur die Beiden HTTP-Header-Blöcke zu sehen.

Gruß aus Berlin!
eddi

[Malcolm Beck´s]

مرحبا

Siehst Du, da hast Du wieder einen ganz anderen Aspekt ausfindig gemacht, an den ich gar nicht mal gedacht habe, die eingebetteten thumbnauls zu nutzen.

:)
Interessant wäre jetzt aber noch zu wissen, wie man es anstellt, dass die eigenen Bilder Intern ein Thumb anlegen.
Ich habe eine kleine Testseite angefertigt.
http://dj-tut.de/sc-dir/z/exif_thumb.php
http://dj-tut.de/sc-dir/z/exif_thumb.php?n-code -- Das Script

Bild 1 (Döner) stammt Frisch von Fotolia, Bild 2 habe ich mit einer Nikon DSLR geschossen, wobei in Bild 2 kein Thumb gespeichert ist, nur, wo oder wie stellt man das ein?

die von keinem Dokument begleitet wird (HTTP-Header "Content-Length: 0" des jeweiligen response). Es sind also nur die Beiden HTTP-Header-Blöcke zu sehen.

Danke für die Erklärung, jetzt sehe ich zumindest den Unterschied -- wirklich Schlau werde ich daraus aber trotzdem nicht.

mfg

[Edgar Ehritt]

Re:

Interessant wäre jetzt aber noch zu wissen, wie man es anstellt, dass die eigenen Bilder Intern ein Thumb anlegen.

Im Internet habe ich öfters vom exifer gelesen. Aber es scheint eine ganze Reihe von Werkzeugen für Windoof zu geben.

Bild 1 (Döner) stammt Frisch von Fotolia, Bild 2 habe ich mit einer Nikon DSLR geschossen, wobei in Bild 2 kein Thumb gespeichert ist, nur, wo oder wie stellt man das ein?

Du kannst ja Appetithäppchen servieren. ;)

die von keinem Dokument begleitet wird (HTTP-Header "Content-Length: 0" des jeweiligen response). Es sind also nur die Beiden HTTP-Header-Blöcke zu sehen.
Danke für die Erklärung, jetzt sehe ich zumindest den Unterschied -- wirklich Schlau werde ich daraus aber trotzdem nicht.

Naja, es ging ja darum, ob Dein Server pipelining unterstützt. Würde er es nicht tun, würde er nicht mehrere requests pro Verbindung bearbeiten. Wie aber zu sehen ist, sendet er zwei response zurück.

Gruß aus Berlin!
eddi

[Malcolm Beck´s]

مرحبا

Im Internet habe ich öfters vom exifer gelesen. Aber es scheint eine ganze Reihe von Werkzeugen für Windoof zu geben.

Die ersten gehversuche waren schon mal nichts.
Danke jedenfalls für den Link, ich werde mir das mal näher ansehen (sobald ich meine 7 Baustellen fest im Griff habe, dann auch wieder genauer) -- Evtl. stolpere ich mit dem neuen Begriff ja auch bei einer mir bekannten Software über dieses Feature.

Bild 1 (Döner)
Du kannst ja Appetithäppchen servieren. ;)

Ich mag's Deftig, ich liefere direkt ganze Pakete  ;)

Naja, es ging ja darum, ob Dein Server pipelining unterstützt.

Das hatte ich dir von vorn herein geglaubt, ich hatte mich nur gefragt, ob es da was PHP-Internes gibt, so wie sapi_name. Ich finde es immer Interessant, wenn ich von Features lese, nach denen ich so nie suchen würde, oder darauf kommen würde, danach zu suchen.

mfg

[Eddie]

Hallo allerseits,

nur um das ein wenig zu spezifizieren, weil das glaubich nicht ganz klar war:

a) ich habe keinen Einfluss darauf, wieviele _unterschiedliche_ Bilder auf einer Seite erscheinen, das bestimmen meine Nutzer. Es geht also um 0 bis vielleicht 20 Bilder (im Normalfall), aber es gibt auch Fälle mit wesentlich mehr Bildern.
b) ich überarbeite ein bestehendes System, bei dem die Nutzer bisher standardmäßig die Normalgröße ihrer Bilder sehen. Das heißt: im Bearbeitungsmodus bekommen Sie die Bilder ähnlich angezeigt, wie später ihre Leser. Ein Bild in Normalgröße liegt realistischerweise bei ca. 50-80 KB, das finde ich ok. Gab auch nie Klagen, "above the fold" ist ja ruckzuck da, der Rest kann ruhig länger laden...
c) die Thumbnails kommen erst jetzt dazu, weil ich den Usern eine Möglichkeit bieten will, ihre Bilder zugunsten der Übersichtlichkeit permanent auszublenden (nur im Bearbeitungsmodus).

Eure Vorschläge habe ich mir sehr genau durchgelesen, finde sie auch gut. Das mit den CSS-Sprites (oder clip, kannte ich nicht) hatte ich mir auch bereits überlegt. Allerdings ist das eine sehr dynamische Geschichte: wir sprechen hier von vielen tausend Dateien, die permanent aktualisiert werden müssten (nämlich bei jeder Benutzeränderung), und die wegen der Positions- und Größenangaben auch eine Repräsentation in der Datenbank bräuchten. Das ist im Augenblick ein Overhead, den ich mir nicht leisten kann. Ist also leider Zukunftsmusik :-(

Darum geht es für mich tatsächlich nur um die Frage
"Traffic-Overload durch doppelte Requests" oder "Client-Overload durch eigentlich zu große Dateien bei Thumbnails"?

Unabhängig davon werde ich mir jetzt mal Gedanken machen, ob ich zumindest diejenigen Thumbs, die garnicht angezeigt werden (also in Normalansicht) erst bei Bedarf nachlade - also genau das umgekehrte Verhalten der Beispielgallerie. Das wär ja schonmal was...

Eddie