Return of the HTTP overhead delay – this time without a server side component
Following my post yesterday about delaying the loading of avatar images to cut down on HTTP requests I was wondering if there is a way to do this without having to resort to a server side solution. In short, there is.
- Check out the demo page to see the script in action, and download delayHTTPoverhead.js to use in your own sites.
Using the script is dead easy, simply include it in your page and make sure to include avatar images in the following format:
<img src="default.gif#http://avatarurl" ... >
The default.gif is your placeholder followed by a hash and the real URL. All the script does is go through all the images, check which one has a hash in its src attribute and remove everything up to the hash. If you don’t want to loop through all the images in the document, you can change two variables in the script: You can provide the ID of an element to constrain the loop to in parentID and you can provide a class that is applied to all the avatar images in avtClass. The script is Creative Commons Attibution licensed, so go nuts using it.
Here is the script’s saga: the internet’s Drew McLellan commented yesterday on the blog about the usefulness of the idea and we talked over lunch and then Messenger how we could make it JS-only. First Drew considered the real URL as a parameter after the placeholder, but that messed with the caching as each default.gif?foo would be considered an unique URL. We then thought about fragment identifiers, as for a browser foo.html and foo.html#bar is the same resource.
We weren’t sure about the validity of a real URL as a fragment identifier, and as we are too lazy to look these up I consulted the walking standards encyclopedia, David Dorward and got the green light for the fragment identifier idea. On my way out the office I put the idea past Lawrence Carvalho who thought it necessary to allow for a parent ID and a class to constrain the amount of replaced images. Five stops later on the Picadilly line the script was done and now I am uploading it. It is great to have the right people working next to you.
July 15th, 2007 at 11:37 pm
July 12th, 2007 at 11:40 pm
July 10th, 2007 at 8:20 pm
Very cool! Bookmarked for later usage, maybe on my own blog…
July 10th, 2007 at 8:41 pm
Go teamwork!
July 10th, 2007 at 9:47 pm
Nicely done. We may have to use that ;-)
July 11th, 2007 at 5:07 pm
And what about people without javascript ?
July 11th, 2007 at 6:24 pm
I’m going to have to disagree with David. According to RFC 3986:
fragment = *( pchar / “/” / “?” )
pchar = unreserved / pct-encoded / sub-delims / “:” / “@”
unreserved = ALPHA / DIGIT / “-” / “.” / “_” / “~”
pct-encoded = “%” HEXDIG HEXDIG
sub-delims = “!” / “$” / “&” / “‘” / “(” / “)” / “*” / “+” / “,” / “;” / “=”
So you see the colon isn’t valid in fragment identifiers.
As always, don’t rely on hearsay to determine validity when you can go straight to the authority on the matter.
Why didn’t you just urlencode the URI before using it as the fragment identifier?
July 11th, 2007 at 9:35 pm
uh, if you have a problem serving up images why not tune your server? moran
July 11th, 2007 at 11:38 pm
How about just specifying the width and height attributes of an image? Doesn’t that make the browser render it along with the page before loading the images?
July 12th, 2007 at 1:01 am
@mark: what if you cannot control the servers the images come from? Ever looked at myspace?
@rik: I touched on that in the other post, yes you make your avatars dependent on JS, but it is a conscious decision of you to wonder if the site without avatars is less of a problem than waiting for them for a long time.
@greg only visually, the problem is all the HTTP requests images create which slow down your page rendering. Check the previous post for a demo.
July 12th, 2007 at 4:18 am
Please ignore my earlier comment, obviously not enough caffeine in my system. Colons are valid characters in fragment identifiers as the notation I quoted myself clearly shows.
July 13th, 2007 at 6:15 pm
This doesn’t really seem like this accomplishes the goals intended. From my testing the ability to scroll the page was dependent on whether or not the images have loaded, so when they were loading under lesser connections the page was unable to scroll, isn’t that defeating the purpose?
Has anyone else tested on various connection with various browser? I experienced the most noticeable problems in Firefox and IE.
July 15th, 2007 at 12:11 pm
Some testing (in FF2 only so far) has revealed that adding a <noscript> element after the <img> element containing an <img> element with the actual URL of the image causes the image to be loaded as normal if JS is disabled. The image is ignored if JS is enabled and the images are loaded after page load.
The script could perhaps be rewritten to omit the fragment identifiers and fetch the true URL of the image from the noscript (noscript is available in the DOM). I will have a look at rewriting this to do this…
February 8th, 2009 at 12:19 am
Chris,
This is very nice solution indeed! I’d really like to use it, but is it possible to control the order in which the avatars load? So they will load one by one in the order they appear and not in the usual unpredictable chaotic way that images load..?
Thanks!!