On Sun, Dec 30, 2012 at 11:30 PM, Stewart Lord <[email protected]> wrote:
> > On Dec 30, 2012, at 7:17 PM, Sherif Ramadan wrote: > > > Now for the bad news: > > > > 1) Prototype actually requires a lot more requests per page view than > the existing site. (Upon preliminary testing this about double the number > of requests on average). The main reason for this seems to be that the > prototype is using one data URI per image in the footer where we display > the PHP elephant plushies. This is actually very bad, because data URIs > generally gon't get cached by the User Agent. This could mean a lot of > extra HTTP requests per page view increasing load with minimal benefit. I > highly suggest we refactor this to use a single PNG file as a sprite image > that can be cached by the UA and with a little CSS it can work any > necessary effect magic needed. > > > I think you are misunderstanding how data URIs work. We make one JSON > request to get N elephant images. We then place these into the DOM using > data URIs specifically to avoid the request overhead you are talking about. > If your network pane reports ~40 requests, then about half of these are not > actually http requests. > 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). 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). Granted, it's minimal in impact since the URIs are so small. But like I said these aren't critical points just some suggestions to consider. > > http://en.wikipedia.org/wiki/Data_URI_scheme#Advantages > > Stew
