Ro wrote:That's kinda of my point earlier, it doesn't change the loading time since the ORIGINAL picture is downloaded but just resized on the client side.
actually, it doesn't download the original. the small thumbnail is much smaller (in some examples - 12-20Kb) than the equivalent full size (in some examples, 120-250Kb). so it takes more CPU power on the server to preprocess the images if they are dynamically generated, or about 15% more storage because you have both the thumbnail and original, but on the throughput from the server to the client, it will be significantly lower if you're not viewing the full size images.
going with the 800px as thumbnail images will be 25Kb-100Kb and full images from 70Kb-550Kb (for example). this will consume roughly 100-500% more bandwidth than the smaller thumbnails plus roughly 25-30% more disk space.
you can verify this behavior by inspecting the thumbnail versus the full image and viewing the page source to see the different commands used to display the thumbnail versus the full image. the good performance is due to pre-caching the full image on the server to allow it to stream once the link is clicked (and you can see this behavior on photo images and a slow connection because the image not being cached locally takes time to load and render, whereas if it was the original and simply sized differently, the response would be almost instantaneous and the smaller image would have a skewed appearance due to size tags and the web clients ability to display alternative sizes).
(just a note: i build global enterprise systems for a living and we deal with exactly this type of issue on a regular basis since the latency, throughput, and storage costs + end user performance expectations are a complex balance...) one thing i can recommend strongly if you want killer performance for static page assets (images, video, etc) - Akamai. but it's more costs and some additional DNS trickery...
