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.
Conclusion
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.
3 TrackBacks
TrackBack URL for this entry: http://www.readwriteweb.com/cgi-bin/mt/mt-tb.cgi/1535
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteWeb posts
Hi Alex,
I would say that most javascript widgets don't actually do an awful lot of work in terms of processing. 9 times out of 10 the lag you are talking about is the actual delay in requesting the JS file from the widget server.
At PollDaddy we were serving up 15 million widgets per month 6 months ago and our server was on fire most days. We solved this problem in part by pushing our widgets out to Amazon S3 so now the bulk of our widget serving is handled my a much more robust infrastructure than our own.
Most javascript widgets are just containers for a HTML string which is rendered out on the page. If you are going to be serving up that many widgets you really need to look at getting them hosted somewhere that can handle those volumes of traffic.
Lenny.
great post!
i'm also considering widgets with javascript as AIS contents.
Those JavaScript widgets really are a big issue. When Twitter is kind of down (often) my Flash widgets just look stupid but on the pages that use the JavaScript widget it must get past that three second point you mentioned and then...of course...it just hangs and the rest of the page won't load.
I second the use of Amazon s3 for broadcasting your javascript. Its easy to setup s3 to look like a remote server also.
PollDaddy has solved _their_ problem by shoving the Javascript under their carpet. They leave the blog reader/client in same situation. Every single link is a latency and Javascript on the client does not improve user experience from page delivery speed point of view. The problem with Javascript interactions on client remains.
Additional issue seems to be all the measuring and tracking done by third-party sites (and their Javascript). Every one is a latency to make the connection and extract metrics. Too many blogs are becoming a mashup under a different name.
Use Iframe to display the javascript of the widget. In other words create an HTML page containing just the widget tag, and in the page you want the widget displayed you include an iframe tag pointing to the HTML page with the widget code.
This method solves two problems:
- the javascript code of the widget (3rdparty) does not slow dow the display of your page. The slowness is limited to just the iframe. If their server goes down or is unreachable, is just the iframe that is not loading - and not your blog content.
= the widget publisher does not have access to your page content. JavaScript does not restrict cross domain scripting - so if you place a script src on your tag pointing to a 3rd party, that third party can see the referrer of your page, collect any data the user types, and who knows what.
The iframe solution has been used by advertising companies and more respected publishers since Microsoft first introduced it. It works pretty good.
Hi Reed,
I cant see why you would think we have "shoved it under the carpet". There is going to be a latency associated with any content you place on a web page. Its about making that latency as small as possible. Widgets are a great way to enhance the functionality of any site providing they are delivered quickly. The alternative of not using widgets means that site owners would have to build all this functionality themselves or depend on wordpress or somebody else to build it for their platform which is not feasible.
If you want your site to load as quick as it possible can then don't put any content on it. (joke)
Lenny.
Why not just stop using bloated widgets?
very interesting post :) useful !
Are there any other alternatives beside Javascript? ^_^
I don't think javascript has to completely go, but yeah people get waaaaaay too widget happy. What also makes me crazy are those page refresh scripts places like HuffPost uses. Isn't the point of AJAX to be unintrusive? I don't know whether this is because they think people need up to the second breaking news or some way to beef up their page views, but it's extra annoying when you use their quick-read lighbox feature and the next thing you know, the whole page is refreshed and your place is gone.
The biggest problem of widgets is the use of document.write, and the necessessity for its scripts to run while the page loads.
Widgets don't have to be there when the page loads up. There's nothing wrong with delaying their loading until the DOM is ready, or even later when the onload event has been fired.
All that's needed is properly written widgets, written with unobtrusive JavaScript, and a small script on the page that queues up each widget to load and run after the required event has fired.
The initialisation script just needs the URL of the external javascript file that contains the code for the widget, and a configuration object that the widget uses on initialisation.
That configuration object just contains the div or other container where the widget can be placed.
The performance problems about heavy JavaScript/talking to third party servers while the document is still loading up is well known. TechCrunch has had multiple problems with widgets on its pages, and a few years ago Scoble dropped the whole "number of comments" functionality from his comment link because it basically stopped his page loading. Every comment link generated its own HTTP request - and multiple HTTP requests is an absolute no-no for high performance pages.
Widget developers should also bear in mind that there are some sites that don't allow js, for secutity reasons. One example is WordPress.com. So it helps if, where possible, developers provide hmtl-only alternatives to their js.
Great Post Alex...The idea of using a multiple servers is a good one...and so it the idea of having something similar to a JVM (javascript virtual machine) to restore some order...
The main issue though is Microsoft's deliberate negligence of the evolution of browser as a computing platform...If MS was not so keen on getting everybody to use the closed .net system and worked on improving the browser as a platform, there would no reason a lot of the technical issues you pointed out won't be addressed.
We've replaced our javascript widget, on Feed.Us, with a "local" script. It works similarly to a javascript but calls info from a file that is hosted locally.
This allows the widget to run on the server side, not browser side.
Works nice.
*grin* .. Quite ironic that while reading your post I got blocked from scrolling downwards as your MyBlogLog widget loaded.
Seriously, great post. Most website owners/bloggers tend to load their websites with way too much "flair", most of which just cuase dissonance on the page.
Don't agree with your third point above though; most larger widget providers will implement an internal load balancing solution and this is preferable to giving users static server names that may or may not be available at any particular moment in time.
@owen. The idea is that you can then load-balance each of these.
Alex
@Isofarro - You are so on point. Why cant all the java on a page after the content comes in - as to not stare @ a blank page??
Thanks from http://www.askTheAdmin.com
And people should be using the jquery library instead of stuff like prototype. It is less than half the size.
What about concentrating on content and keeping widgets to a minimum? I realize blogs are all about personalization (add-ons), but where does each user draw the line?
Less widgets = less javascript line fighting each other. my opinion anyway, I'm sure many bloggers don't necessarily agree.
I disagree a bit with your 3rd point. Differentiating URLs only has value if you're serving up different JavaScript for each widget. Most widgets use a common core JavaScript and a second JavaScript file or other format file to customize the look and information in the widget. In this scenario you want as many files coming from the same URL so that the common files are cached. With the various load balancers available today there is no reason to differentiate by URL.
Using different URLs might also impact your ability to use Ajax/XHR.
@alex: point taken, though it seems a bit redunant, even roundrobin DNS can supply something more elegant than different URL's per user, but I suppose it's a design choice.
I've taken you post a bit further (coining the term JIL: Javascript-Induced Lag) on my blog: http://www.u-g-h.com/index.php/2007/08/15/how-javascript-can-hinder-rather-than-help/
Hope you don't mind my using your post for inspiration.
Thanks for this. Very well written and useful. I don't have much to add other than my thanks.
That's funny - that's funny
This page took 16.57s to load
I totally agree, JavaScript made websites hell slow. You have discussed a very important point that JavaScript is a single threaded language.
I agree with pretty much everything in this article except for one thing:
"Use Standard Libraries."
In isolation, I agree 100% with that statement. When developing a site that's going to have lots of JavaScript, you should pick one of the leading modern JS libraries. I like YUI. Others like jQuery, prototype, mochikit, and Dojo are good too. Pick one, work with it, but don't mix and match.
The problem is that your talking about third-party widget development. That is, bits of JS intended for inclusion in others' pages, on others' sites. And the problem is that the including site has probably already picked a standard JS library to work with. And, most likely, it's different than the one you like.
Unfortunately, many of these libraries don't play nice with each other when mixed on the same page - not to mention that they tend to weigh in at between 20-120k to download. So, you've already got the weight of the host page, but then as a widget developer you want to haul in all your own favorite wheel-reinventions as well?
What I really think this calls for is a smaller, portable JS lib devoted to the concerns of widgets. If that's possible, anyway. Make it polite, unobtrusive, and very very tiny. Limit it to just the things a widget would tend to want to do.
Excellent post. Some other exciting tools in this domain are yslow from Yahoo! This provides you a performance score for your site. The readwrite web site could use some improvements based on the reccommendations provided.
http://developer.yahoo.com/yslow/
Its not time yet to get rid of the JavaScript. Its even being more popular with the wider use of the AJAX technology.
Great post, and something we often wrestle with here at Lijit.
Other commenters have said that people should just "stop using so many widgets." That reminds me of the 90's when people were complaining about all those unnecessary and slow-loading images that people seemed to like.
Bottom line is that distributed content serving is here to stay and we need to figure out a way to solve it. People love this stuff, so there's a huge potential for those who can make it work.
Want a quick loading of BIG widgets - you can't beat this then.
http://www.widgetplus.com/testbed.htm
I dont agree on that it is "slowing down the web" it actually makes it faster, it makes your browser slower, different story. If people would implement JavaScript in a smarter way, all you need is a bit of code and use the rest only when something happens. Third party JavaScript is the issue, like mentioned before. If you can use JavaScript properly then there shouldn't be an issue.
RE: 3. Load-balance requests by generating different URLs
Sorry, this is totally ridiculous. Do you think everything from www.google.com comes from one server? Using different URLs is a pretty clunky way to load balance. There are numerous other ways to load balance that aren't apparent to your users.
RE: 4. Use Standard Libraries
It'd be even nicer if lots of developers used standard libraries hosted in a standard location. Say you want to use prototype. It'd be cool if everyone loaded it from one location, then it'd be cached in everyone's browser all the time. I think this has been suggested before. Maybe Firefox could even come with Prototype and Dojo (and maybe some others) pre-loaded (and automatically updated). Then you wouldn't need to download all that standard code every time.
There is no container for JavaScript... The HTML page it's in would be a wrapper not necessarily a container. Agree/disagree?
Thx for bringing up this important issue. I'm using digg.com a lot and loading of pages last about 1 min sometimes, if the page got many comments. It's exactly the problem you describe here. I guess Firefox, my browser of choice, does not defer the execution of the JavaScript. Because if you use Opera instead you got no problems with Javascript at all. So I would say, its both, a webpage coding and a browser issue. Something must change, that can't be the right direction to go. I've heard that next FF engine should handle this better. So let's see what future brings.
Actually, even AJAX calls are single threaded...
http://www.javascriptkata.com/2007/06/12/ajax-javascript-and-threads-the-final-truth/
Richard,
Ajax call is asynchronous. That is while the server is working, the browser JavaScript continues to run.
Alex
boo!
The boo-box-bot JavaScript only runs after ALL elements of the page are loaded (except Flash), with this we don't slow down the page-load time and the user can get all the content before the boo-box run.
Sorry for bad english.
from Brazil, Marco Gomes
CTO of the boo-box team
http://boo-box.com
I wonder how much of the issues are caused by not easily being able to debug your Java Script? The DTrace guys have turned this around - http://blogs.sun.com/brendan/entry/javascript_provider_ver_2_0
and *well* worth checking out. Being able to debug right down from page request to the kernel and back again brings massive benefits.
I've written some fairly large javascript libraries over the years. I've come to believe that if you think of Javascript as being for "widgets", you're ignoring its real power. Javascript facilitates improved interaction between user, browser, and server. It can also enable a faster, more powerful application development cycle.
Recently I've written a lot of Javascript that is included in the Water programming language. This facilitates nearly instant AJAX programming thought Water, as shown here:
http://www.youtube.com/clearmethods
The libraries are not small. However, pages still load fairly quickly, as you'll see in the videos. Contemporary systems and browsers evaluate even fairly large Javascript libraries quite quickly, unless there's a delay getting them from the server, in which case Javascript isn't really to blame.
Further, by using complex Javascript to facilitate easy AJAX programming, we've found that you can actually speed up the user experience by only refreshing such parts of the page as have actually changed. I strongly believe that the small up front hit of loading some additional Javascript to handle the AJAX transactionality is more than made up for by the time savings later of only having to wait for the server to generate tiny snippets of page instead of whole pages.
Dear Mr. Richard MacManus,
Let's face it . The web as we know it , can no longer neglect that the data we consume is truly fragmented.
I don't think that's a very bad thing at all, and i don't think we have anything to worry about . For a post right here in all its rich goodness has 26 script tags from as many different locations, i dont think it's doing too bad at all!
That said, there is no reason why developers should'nt look at optimization of the widgets and API's that they roll out. But you just cant stop the fragmenting of data, and people from consuming it.
Keep Clicking,
Bhasker V Kode
Maybe part of the slowdown is caused by the 342 cookies that are ass-pounded into browsers every time some idiot creates another useless blog-clog?
The pros of javascript far outweigh any of its negative attributes. Lets face the facts, we n-e-e-d javascript because there is no other current language that could replace its functionality range and browswer support.
Second, javascript is just like every other design element on a web page.. too much of a good thing is going to cause problems. We should elimate the abuse of javascript (bloggers with 7 and 8 external widgets i'm looking at you)... not completely divorse the web from the wonderful mate that is javascript.
Good article overall, thanks.
Oh, please please listen to what the first commenter (Lenny) has to say. You want to take the widget javascript loading _out_ of the critical path of the browser. There's a very simple solution to this. Just insert the tag into the document after a small delay when the page is loading. setTimeout (function () { document.write (...) }, 100);
That way the blog content loads without waiting for all the stupid javascript files to arrive.
Google Gears adds some true multi-threaded features to javascipt besides the primary offline capabilities. http://code.google.com/apis/gears/api_workerpool.html
@44 This simulates threads via setTimeout? How can it ensure that a particular worked does not starve the rest?
Alex
What's with the funky figure?
I agree with Mandelbrot (#46), some figures or statistics would be great. Theoretically, Javascript does have some constrains, but it will be interesting to know how much impact these scripts have on the server and the loads.
Javascript with Virtual Machine doesn't really sound good to me.
Ok, JVM allows Java to be so portable but..
I thought that JVM is what's causing Java to be so slow (even 10 times slower than C++). Why does everyone prefer JS with VM over JS as it is now?
And I don't really see a chaos in Javascript. I think that's because of the general underestimating of JS.
OK, with several widgets on a blog, it may start being slow.
But I think that widget creators and blogging systems have to change, and not the language they are using.
I found 26 instances of javascript on this page!
Marc, exactly! That is the issue. Much of that javascript is for the advertising that runs on the site, which speaking as a publisher, is key to the site's success. Other things like the poll and mybloglog are not essential, but certainly add to the flavor of the site. I would definitely like to improve the time it takes the site to load, but in the end (as a publisher) I'm reliant on the code from widget and ad providers. That's fine, but as Alex said there must be ways that we as an industry can optimize that.
1 2 Next