Putting the Brakes on SharePoint with JQuery

Home » SharePoint Performance » Putting the Brakes on SharePoint with JQuery

Putting the Brakes on SharePoint with JQuery

Posted on

For the better part of the last year I’ve been watching from the sidelines as nearly the entire SharePoint community jumped on the JQuery bandwagon. It seems like every year some new thing comes along which will make SharePoint sing and dance like a Broadway musical (remember 2007 – the year of AJAX?). Blog after blog has popped up with tips and tricks on how to do nearly everything with javascript, from fetching list items with web services to making pretty lightbox effects out of picture libraries. Ok, that’s cool and all, but the one question nobody seems to be asking is: will it scale?

Putting aside the obvious shortcomings of doing all sorts of programmatic gymnastics with uncompiled, loosely-typed, client-side code, let’s pause a minute to consider what impact JQuery may have on performance. There’s nothing magic about JQuery itself; much like LINQ, it simply provides less-obtrusive language semantics in order to make common tasks more efficient. If you look into the source script you’ll see that it’s mostly a bunch of arrays being populated with getElementById calls and regular expression searches – not exactly rocket science.

In most of the examples I have seen, JQuery is being used to modify the user interface by changing elements of the document object model (DOM) after it has been sent down to the client by the server. The average SharePoint page has more than 1,000 elements in the DOM right off the bat before adding any web parts or publishing field content; add to that some of the really funky code that the OOTB web parts produce, along with a list view or two, and you can easily end up with pages that have thousands of DOM elements. That’s a lot of stuff to process in client-side code. All that iterative selecting, searching and modifying that JQuery does in the background to manipulate these elements takes time – the bigger the page, the more work has to be done before the final content is rendered in the browser. Considering that SharePoint pages aren’t exactly optimized for performance right out of the box, and how much time and effort is spent trying to shave a few seconds off of average page load times, is it really a good idea to start mucking around with the DOM just to produce some fancy visual effects?

I remember having a conversation over dinner at DevLink last August with Dennis Bottjer. Dennis was convinced that JQuery was the answer to many a developer’s frustrations with the SharePoint UI and customizations in general. I conceded that he was probably right, it would catch on and spread like wildfire, but I was concerned that overuse would lead to performance problems. We went back and forth about it for a while then let the matter drop but the more I see it being used (you were right on that score, Dennis) the more I am troubled by its impact on high-volume sites, especially enterprise portals and public-facing web sites, and the lack of any substantive performance discussion in the greater community.

In order to validate my theory that even simple JQuery functions can put a damper on SharePoint performance (or, should the results prove positive, at least put my mind at ease), I set up a very simple test scenario. I created a web part page in a WSS site in SharePoint 2007 then added an out-of-the-box list view web part to the page which rendered a view of the first 500 items in a custom list. I then copied the JQuery scripts to a subfolder in the /_layouts directory and added a <script> link in the <head> tag of the master page. Finally, I added a content editor web part with a JQuery function that changed the background color of every other item in the list view to yellow, like so:


I then fired up SharePoint Performance Manager to assess the render time of the page both with and without the JQuery CEWP. An empty CEWP had an average execution time of around four seconds (which is scary in and of itself – I need to look into it further and figure out why that particular web part is so slow even with no content); adding the function to change the row styling increased the execution time by about a second. I flipped it on and off twenty times using ten sample page loads for each configuration and the results were relatively consistent – in my test environment the JQuery took about a second on average to do its work. The overall effect on page render time was rather less due to multithreading, working out to about a third of a second. Ok, that confirmed my basic theory but there were no real surprises and a third of a second doesn’t stop the world from spinning (although, to be fair, many dotcoms have spent millions of dollars in infrastructure for the sole purpose of reducing load times by a fraction of a second).

The next step was to set up a series of load tests to ascertain the impact of the JQuery operations when multiple simultaneous requests were involved. I configured a single-page web test in Visual Studio Team Test and dropped it into a load simulation of 100 concurrent users over a three minute period. This is when things got a bit more interesting. Overall page load time without the JQuery code went up from around six seconds to about eleven seconds (an 80% increase, which is to be expected on a single virtual machine with only 4GB of allocated RAM) but when I added the JQuery function to the CEWP it shot up to thirteen seconds – not at all what I was expecting. I ran the tests a dozen more times with similar results. While the base page load time increased by 80% the JQuery impact on page load went from a third of a second to two whole seconds – a 600% increase! That’s more than statistically significant – that’s downright worrisome.

So what gives? Admittedly, my test environment isn’t anywhere close to "real world" – your mileage may vary depending upon the server and network infrastructure, client connection, amount of concurrent requests, and, of course, the exact nature of the JQuery methods being executed. But the results were pretty clear – under load the javascript performance was less than stellar. I would be very concerned about this type of code in a high-traffic environment; in fact, I would almost certainly call this out in a performance assessment as a critical blocking factor.

The takeaway here is to be very careful what kind of JQuery operations you are performing on your SharePoint pages. In most real-world scenarios I doubt whatever client-side functions are being performed would have a drastic impact on performance – typical enterprise portals just don’t get that much simultaneous load. That being said, I would steer clear of JQuery in most high-traffic situations, especially home pages for popular WSS sites, shared application pages (like viewlsts.aspx) and any public-facing MOSS publishing pages. I’m especially troubled by JQuery inside of content editor web parts, as the CEWP by itself appears to be rather burdensome even without additional scripts, and would much prefer to embed the scripts directly (either in the master page or as a custom control) if I absolutely had to implement some fancy DOM-manipulation scripts.

Don’t get me wrong – JQuery has a lot of benefits, not the least of which is the ability to write complex query logic with relatively little code; however, its use in performance-sensitive environments could be more trouble than it’s worth. As with all things SharePoint, there’s more than one way to skin the cat and other methods may achieve the same results while introducing less overhead. Use it if you must but test, test, test before going into production or you may get a nasty surprise when that fancy new MOSS portal goes live.


As expected, this topic has generated some discussions in the community, which is exactly what we need.  Here are some links to related posts:

Marc Anderson – Putting the Brakes on SharePoint with JQuery – or not

Dennis Bottjer – Stop, Think, Dev SharePoint

Eric Shupps – Follow-Up on JQuery and SharePoint Performance


Many people have rightly pointed out that my load tests were not real world (whcih I did mention in the post) and not really applicable to client-side script processing.  That’s caused a lot of confusion and is fair criticism.  I was going for the impact that the CEWP’s and List Views had on each other under load and got distracted by the strange results I was getting from the CEWP’s – I should have separated the two discussions.  To that point, I have discovered some interesting things about how the CEWP’s work and will be posting on it in the future as soon as I have a chance to compare them with the 2010 version.  See my second post (linked above) for more discussion of render time performance as opposed to load time.