On 2012-12-31, at 10:41 AM, Sherif Ramadan <theanomaly...@gmail.com> wrote:
> > > > On Mon, Dec 31, 2012 at 1:25 PM, Stewart Lord <ste...@ambitious.ca> wrote: > > > On 2012-12-30, at 10:07 PM, Sherif Ramadan <theanomaly...@gmail.com> wrote: > > > Sorry, that was poorly worded. I didn't mean to suggest that the each data > > URI generates a transfer over TCP. What I'm saying is that there is a > > caching disadvantage here since the initial JSON request itself can't be > > cached (the one coming from http://prototype.php.net/images/elephpants.php). > > The JSON request could be cached. It is designed to return a random > collection of images, so you would have to be willing to give up some > randomness, but there is no reason it couldn't be cached. > > > Yes, the request to the script that returns the JSON containing the data URIs > could be cached if it wasn't dynamic, obviously. I'm not saying that it > couldn't. I'm saying the data URIs won't be cached by the browser. What > you're saying is that this is moot in this particular case and I agree :) > > > > > For each of these data URIs the browser will consider it as a request even > > though nothing is actually transferred over HTTP from the data URI, > > obviously, but that's still not great. The reason being each data URI > > requires encoding/parsing on every single request (that's extra time to > > render the page that could be avoided). > > Have you measured this? I don't think there is any significant overhead to > data URIs. > > > Yes, and I never suggested that the overhead was significant. It takes > roughly 1ms to render those data URIs by looking at the HAR, which is not > significant at all. The minor point I was making here was mainly that data > URIs can't be cached and that leaves the disadvantage of the browser having > to start from scratch on every URI, which isn't always a bad trade off when > your data URIs pack less overhead than the HTTP request headers would > initially pack on top of your image. However, here it's the case that we have > a lot of them and the same overhead can be alleviated from the initial HTTP > header to the script that generates the JSON containing the data URIs in the > first place if it was just a single PNG file that could be cached in the > browser (avoiding one extra HTTP request to the PHP script generating that > JSON on every single request). It's not a huge savings, but in the long run > it does save at the very least that one extra TCP transfer along with the > very very minor rendering time caused by the data URIs. The overall savings > across thousands of daily requests across nearly 100 mirrors would be > significant, however. > > Just my 0.0002 cents > :) I think I got the wrong impression when you said you strongly recommend replacing this. Sounds like its not really a concern then? Rather than use a sprite, why not just add cache friendly headers to the elephant script? That would allow things to continue working with the Flickr backend.
