On Mon, Apr 22, 2013 at 6:30 AM, Mathias Schindler < mathias.schindler@gmail.com> wrote:
Which one is larger (given an empty cache)? One single big file containing the thumbnails or one small HTML file and individual thumbnail files (that includes possible overhead in the TCP/IP packages for both scenarios)?
For very small images, HTTP headers can indeed overwhelm the actual data; that's why we use embedded data URIs in styles a lot, which tend to have very small icons and such.
For typical photo thumbnails there's less relative overhead, but it's still a bunch of extra files to fetch.
There are a couple disadvantages to using data URIs for largish inline images such as photo thumbs though:
* browser can't render all the text layout before downloading the images; images are forced to load at their inline positions. * increased memory usage -- DOM is going to contain the full base64 data URI, whereas a separate image file would only store a small link and go into disk cache. This may be an issue on memory-constrained devices such as smartphones and tablets. * I'm not actually sure how disk caching works with data URIs. :) They may just eat up RAM as long as the page is opened, even when not shown onnscreen.
I love the idea of using more compact image formats when available, but doing the negotiating makes things more complicated. Maybe edge-side includes can rig something up, maybe their overhead would kill the cache servers. Dunno. :)
Another possibility is to preferably load images on view/section expansion via JavaScript, which can potentially give you a chance to query the format compatibility in client JS and avoid any HTTP-level negotiation. (And also doesn't load any images until you need them.) Things to think about...
-- brion