On Mon, Apr 22, 2013 at 6:30 AM, Mathias Schindler <
mathias.schindler(a)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