The Unbearable Slowness of Javascript Widgets

Alex Iskold – the giant brain behind AdaptiveBlue – has a great post up today titled How JavaScript is Slowing Down the Web (And What To Do About It)While I’m sure no one has ever noticed how slow my blog (or Fred Wilson’s) loads (cough, cough, choke, choke – that would be sarcasm), there’s no easy solution.

In addition to describing the problem clearly, Alex suggests several approaches that make things better.

  1. Defer the execution of the JavaScript
  2. Minimize the amount of code that runs on load
  3. Load-balance requests by generating different URLs
  4. Use Standard Libraries
  5. Most Importantly – Think About It

I was in a meeting last week with Alex and a handful of other widget developers who are aggressively working on some interesting approaches and solutions to improve this.  Look for new and improved stuff coming soon to a blog near you.

  • What’s even more unfortunate for people like me, who like to browse with 50+ tabs open, is that some browsers (cough…Firefox…cough) execute all the JavaScript (across tabs) in a single thread.

    If the JavaScript for one tab is slow, the browser becomes unresponsive. Harry Sufehmi has a good summary of this problem:

    “SpiderMonkey, the Javascript engine used by Firefox, sucks. Really sucks.

    Firefox uses SpiderMonkey for itself. Therefore, if a website is heavy on Javascript, then Firefox itself will be blocked while it

  • Alex is clearly very smart. I just don’t get #4. Why Standard Libraries would make it faster?

    I have a great post about how to make pages fast, and has a bit of reference to some of those…

  • Marcelo,

    The reason for standard libraries is so that people who really know what they are doing with JS write them once and the rest of the crowd can reuse them.

    Same reason really why any language or any software project has libraries.


  • Dave

    One point missing in this conversation is that all these widgets quickly reach the attentional/clutter threshold for the user as well. Your blog page, for example, would be a lot more effective if each of the widget features (e.g., Blogs I Read, Categories, Lijit Search, etc.) were an outline/foldup feature rather than being listed out. As I look at it I see that you’ve actually removed some useless stuff that used to be there, like the word soup thing.

    Note also that clutter reduces the effectiveness of ads on blogs!

  • I don

  • I think his description of the problem is good, but the suggestions are wrong at best and harmful at worst. In particular:

    1. Worse than not working, the defer attribute can cause IE to crash.

    3. Non-canonical URLs for your scripts is only going to hurt cachability and load balancing through different subdomains is a Bad Idea. If you can’t afford a commodity box to run something like Pound to do real load balancing, at lead do round-robin at the DNS level on the same domain.

    That will distribute load, but since any modern web server can serve thousands of static requests per second your real concern should be availability, which DNS round robin doesn’t address very well. Consider a CDN like Akamai or Panther, it’s worth the cost. (Amazon S3 is not a CDN.)

    4. Even the smallest standard libraries are 5-15x the size of code you should need for your widget. I might consider something like a component of YUI.

    For a sophisticated look at these issues check out Mike Davidson’s writing and script. Also Yahoo’s performance information is invaluable.

  • So why can’t we do the onload in body of an html page, and the change the innerHTML of a div to point to an external widget? Wouldn’t that solve the problem?

  • @ Omer.

    Yes, you can do that, but that, but often, widgets do not have access to body onload, since they are inserted via tag. Essentially then you need to do what you are describing in the widget code, have the first piece which is tiny and then does deffered called.

    Otherwise you’d need to ask the user to paste in a chunk of JavaScript which is error-prone.