Re: Turning beta into production

On 2012-12-31, at 10:41 AM, Sherif Ramadan <theanomaly.is@gmail.com> wrote: > > > > On Mon, Dec 31, 2012 at 1:25 PM, Stewart Lord <stewey@ambitious.ca> wrote: > > > On 2012-12-30, at 10:07 PM, Sherif Ramadan <theanomaly.is@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.