Optimize and scale web widget performance

Niall makes some very,very good points here that I am going to keep in mind as I work on my own Widget implementation.

There are a lot of “tricks” you can use to minimize bandwidth/load times – and Niall covers most of them.   By “minify” Niall is talking about writing small code, mostly.  I think he could have named this “K.I.S.S.” – Keep it Simple, Stupid”.

What information does your widget need to display when the user is not actively engaged with it? OK, once you know that, get rid of the rest of it until the user DOES engage.  Why load information that the user doesn’t need?  The same idea applies to graphics.  Will a text link work, or do you really need to download that pretty graphic button 250,000 time a day?

In any case, this is a a great post to keep in mind.

And remember – if it makes sense applied to Widgets it probably makes sense applied to your web sites.

Serving widget content across hundreds of thousands of users per day is no easy task. A relatively small widget contains images, dynamic data, dynamic renderers, and manifest code that may consume 50 KB of space if you’re lucky. That’s 12 GB of bandwidth a day if you’re lucky enough to hit 250,000 gadget views hitting your servers, or about 3 file bundle requests per second. Even Google’s infrastructure has strained under the load of widget serving, but your sites don’t have to suffer the same fate.

Optimize and scale web widget performance


  1. Another buggin to install that plugin.

  2. Niall – thanks for stopping by. Too bad web browsers/applications aren’t smarter and doing real-time compression (stripping out useless data on the fly – like comments and spaces). But they aren’t.

    Until then we can write clean code, “Minify” things where possible (I shudder at the thought of millions of lines of uncommented code though!) and make smart decisions when it comes to what we initially display on widgets that don’t have the focus of the end user…


  3. Minify means strip everything out of the published file that is not useful to a machine. Comments and whitespace may make your code easier to read when developing, but you should slim down your file before pushing it out to the world.