Home How JavaScript is Slowing Down the Web (And What To Do About It)

How JavaScript is Slowing Down the Web (And What To Do About It)

A single line of JavaScript is what powers a lot of blogging technologies these days. Widgets, sharing tools,
visitors tracking, advertisers. In many cases a single line of JavaScript is all that a blogger needs to
add a new technology to their blog. The problem is what happens when a lot of these single lines of JavaScript come together…

There is a well-known phenomenon in physics called non-linearity: When a lot of different things interact with each other, the outcome is hard
to predict. Software is no different – when you put together a lot of components, you just do not know what you are going to get.
This is because each component acts as if it is standalone, but they are literally fighting for real estate space and people’s attention. The truth is that this war is
hurting everyone – the readers, the bloggers and the services. Everyone is frustrated.

In this post
we’ll take a look at what is causing pages to hang from too many single lines of javascript; and what can be done about it.

Bloggers – the Unsuspecting Victims

Widgets are the new black and microchunking content is here to stay. Bloggers love showcasing
their personality and favorite content on their blogs. This is why people rush to install new widgets like
del.icio.us, Flickr, Twitter, AddThis, Sphere – because they are useful and there is a lot of demand for them.

Widgets are fairly easy to install if you are familiar with HTML and your blogging platform.
All you need to do is paste the HTML for the widget where you would
like it to appear. Sometimes you need to insert code into the head of the HTML document, but it is not
that difficult. So with a bit of technical understanding, you can do it or use a platform
like Widgetbox to install it automatically.

It’s simple enough that people are installing more and more widgets onto their blogs; and that’s where things
have started to get hairy – as it may result in blogs taking a long time to load.

Not All Widgets are Implemented Equal

There are two major technologies for implementing widgets today: Flash and JavaScript.
Flash widgets have their own issues; from being heavy, to being unresizable, to being unable to
manipulate the DOM. However, typically it’s not Flash widgets that are causing problems, it is the JavaScript ones.

The irony of this is that JavaScript was envisioned and designed to be a lightweight language
to support minimum interactivity and quick manipulations of HTML documents, on the client site. But because
of the twisted paths that our technology trails have taken us, JavaScript evolved to be the programming
language for the web. From Ajax to Widgets, JavaScript is being used in a lot of cutting edge projects these days.
But the truth is, JavaScript has its issues. Let’s explore those…

How Browsers Handle JavaScript

Perhaps the most shocking reverlation to any experienced technologist is that
JavaScript is a single threaded language. What this means is that it performs things sequentially
and not concurrently (with the exception of Ajax calls). Anytime a piece of JavaScript is being loaded or
evaluated, everything else has to wait.

This means that a single slow JavaScript add-on can slow down the loading of an entire blog.
And that is exactly what is happening all over the blogosphere. So what is the solution?

Can JavaScript Widgets be Better and Faster?

Unfortunately there is no silver bullet for this problem. That is there is no single trick
or technique that will resolve the problem. While there is a combination of things that companies
can do to moderate the impact of being put together with other widgets, ultimately – given enough of a mix
– problems are bound to happen. While as an industry we ponder on what can be done, here are some things that
JavaScript providers should consider:

1. Defer the execution of the JavaScript

One of the frequent problems is that all JavaScript wants to run at once,
but it really can’t. If the script does not need to modify the page as it loads,
the execution of the script should be deferred until after the load.
This way, the content of the page will come up fist. Unfortunately, not all browsers respect this directive to defer.

2. Minimize the amount of code that runs on load

Anything that runs on a page load, slows down the load. The less code there is to run the better.
Another related issue is traversing the entire page looking for something. This is a major ‘no-no’, since
it will cause theUnresponsive Script popup. In general, any JavaScript that runs over
a few seconds (typically 5) will cause a problem. Splitting the long execution by using timeouts
is the right (although painful) way to go.

3. Load-balance requests by generating different URLs

Most scripts these days give you back the same URL, for example: www.mycoolwidget.com. This is
not easy to scale. As the widget becomes more wide-spread, the amount of concurrent requests going
through the same server will be quite large. A better approach is to give out different URLs, like this:
server1.mycoolwidget.com, server2.mycoolwidget.com, etc. Even though for now they can be
pointing to the same domain, in the future there will be an option to split the traffic.

4. Use Standard Libraries

Probably the worst thing is to reinvent the wheel, since JavaScript is so easy to get wrong.
Unlike Java there is no set of standard libraries, but some like prototype
have effectively become a standard. The libraries are written by experienced people who know and understand
the pitfalls of the system, so it is a good idea to reuse their code.

5. Most Importantly – Think About it

Being aware that there are other pieces of JavaScript that will run on end user’s sites,
is the most important thing. By wearing the “I am part of a bigger system” hat, developers
will minimize the likelihood of undermining another widget, as well as ensuring an all-round smoother user experience.

Where Do We Go From Here?

While being a good Javascript citizen is encouraged, there is still only so much that developers can do.
You simply cannot know how and where your widget is going to be used. What other things will be installed?
Without this information, tuning the script is difficult. And the impact is on bloggers and blog readers.
So what do we do?

If we look at the Java community, this problem has actually been solved many times over. Applets, Servlets
and even scary-sounding Enterprise Java Beans are not really different from widgets conceptually.
The big difference is that they all are managed by containers.

A container is a hosting environment that
provides delivery infrastructure and communication interfaces. It handles loading, unloading, callbacks,
clicks, messages and all the good things that we engineers love and non-technical people dread to hear about.
In short, we need a container for JavaScript – because a container is what brings order to the component chaos.


While widgets and JavaScript tools are very cool and very useful, there is no good infrastructure
to make them work well today. The initial symptoms of blogs being slow to load, that are visible today,
are only going to get worse as more widgets and bits of JavaScript hit the blogosphere. It is not reasonable
to ask bloggers to understand the complexity, interdependencies and problems that can be caused by
combining widgets.

We need automated and standard ways of delivering these widgets. Ideally we should look at how this
has already been done before in the industry. The Java community was a huge success and leveraging the experiences
that it had could be of great value to the widget startups.

As always, please let us know what you think. If you are a widget developer, we would love to hear
the ways that you optimize your code to be more environment friendly and quick.

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.