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 :)
