Widgets are s-l-o-w-i-n-g m–e d—o—w—n
The great thing about having a bunch of widgets on my blog is that every time my site slows down I have my choice of people to blame. Shame on me for having so many widgets, I guess, but really – there has to be a better way of managing this.
From start to finish, the experience of inserting a widget on my blog is unsatisfying. I have to configure each separately (so it’s hard to make them consistent in look and feel); I have to manually insert the javascript on my blog; to change attributes or location of the widget I have to mess around with the code again or have to go back to the site where I created the widget in the first place; I can’t create a library of widgets and turn them on and off at will; and my widgets are constantly breaking something on my site (apologies for those using my Lijit search last week, which I managed to inadvertently disable when I was moving a few things around on my sidebars). And because I use advanced templates in Typepad everything that’s designed to make at least some of this easier doesn’t work.
On top of all of this, since pages load sequentially, if I have a slow widget or two everything comes to a crawl (and when I say “if”, I mean “when . . . daily”). This isn’t how the world should work. How about someone developing a CDN for widgets? I’m imaging a widget distribution system that manages the calls back to the widget creators, cashes the appropriate material, allows for better compatibility across browsers and platforms and manages the page loading in a more intelligent fashion (ideally all of my content should load first, then the internal links such as my recent posts, and lastly, all the other stuff I’ve littered the page with – although I understand that what I’m describing won’t be able to do this entirely). This same system could also handle the creation of widgets, streamline how I turn them on or off, how I move them around my site and when they are displayed (i.e., I could rotate them if I wanted to or vary their display based on post topic or blog category). This system would be the single place that my blog called back to in order to render all third party content. If a widget wasn’t loading properly, they could just skip it and move on to the next one without holding up the loading process. They’d also be in a better position to architect a network more suitable for this type of content distribution (since most widgets are created to extend content where the widget creator isn’t particularly focused on their distribution network once their content is in place).
We’ve been talking about variants of this in the Boulder tech crowd for months – let’s get on it!