On Mon, Apr 22, 2013 at 6:30 AM, Mathias Schindler < [email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
