How To Keep Widgets From Slowing Down Sites: WEDJE
The whole world is going to widgets. This overused, overhyped term refers to third-party code one places on their website or blog in order to display such things as Flickr photos, Twitter status, or iTunes playlists. Everybody and their mom is putting out widgets these days, and although only about 1% of them are useful or interesting, they are an important new distribution mechanism that is changing the way companies think about syndication.
But there is a big problem with widgets: they slow down the sites that use them. In the best case, you have a company like Flickr whose servers are almost always snappy, and in the worst case, you have a young startup that is constantly struggling against increasing demand and occasionally can’t serve up any code at all.
The problem is that in either of these cases, the completion of your site’s loading and rendering depends on someone else’s code living on someone else’s server. Including a fast and reliable Flickr widget still slows your site down by at least a split second and including a less stable one can leave your site hanging indefinitely.
We’ve been developing what we think is going to be a gangbusters widget at Newsvine over the last few months but just as we were getting ready to deploy it, Intern Rob and I hacked together what we think is a method of deploying widgets in such a fashion that they don’t affect the load times of their parent sites whatsoever.
Following is a breakdown:
Raw embedding usually involves providing a chunk of
script include to remotely deploy code into the user’s site. The advantage is that it’s much cleaner and more flexible. The disadvantage is that it slows sites down a little every time and a lot when there are problems.
The Solution: WEDJE
document.write to write code into your site inline. The problem is that if the widget server hangs, the rest of your site can’t draw until the script is done executing. This could be a split second or it could be forever. Many people mistakenly think you can use the
defer attribute in your script tag to keep this from happening, but
defer effectively kills the
document.write function entirely so this is not a solution.
div with an
defer parameter added, and then use
innerHTML to write to the
div whenever the script has loaded. This seems great in theory, but in reality, Internet Explorer is the only browser which seems to properly render the rest of the page before the script is done executing.
WEDJE is similar to the
innerHTML method above except it creates what is effectively a cross-platform, cross-browser defer, enabling your script to load and execute asynchronously across all environments. We write out a
script element to the
This text is before the widget code.
This text is after the widget code.
Notice how everything loads regardless of the state of the widget? Voila.
Intern Rob and I are under no illusions that this is rocket science, nor that it hasn’t already been tried by someone else, nor that it works perfectly. To the last point, we’d love your feedback as to what could be improved or where it may not be working. So far, tested browsers are:
- Safari: Mac and PC
- Firefox: Mac and PC
- Internet Explorer: PC
- Opera: Mac and PC
1. Here is the sample code which goes in the js file:
2. Here is the sample code to embed in your page:
Compact Version (Don’t use if you serve your pages as application/xml):
Application/XML Mime-Type Version (thanks Scott):