SP 2013: Measuring performance on the JSLink property in SharePoint 2013

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren


In one of my previous posts I talked about "Using the SPField.JSLink property to change the way your field is rendered in SharePoint 2013". That article talks about how we can set the JSLink property in our SharePoint solutions and how we easily can change the rendering of a field in any list view.

It’s pretty slick and I’ve already had one client make use of the functionality in their pilot SharePoint 2013 farm. However I got a comment from John Lui asking about what the performance would be like when executing the same iterative code over thousands of items. Since I hadn’t done any real tests with this myself, I thought it’d be a good time to try and pinpoint and measure if the client-side load times differ while using the JSLink property.


The tests will be performed WITH the JSLink property set and then all tests will be executed WITHOUT the JSLink property set.

I’ve set up my scenario with various views on the same list. The total item count of the list is 5000 items, but we’ll base our tests on the limit of our views:

Test 1  
View Limit 100
Test 2  
View Limit 500

The results will be output with a difference between using the JSLink property and not using it. Should be fun.


I’be been using these tools for measuring the performance on the client:

Fiddler4, YSlow, IE Developer Tools

The code that will be executed will be the same JavaScript code as I had in my previous article.

SharePoint 2013 browser compatibility

If you intend to measure performance on various browsers, make sure you’ve pinned down what browsers are actually supported by SharePoint 2013. The following versions of browsers are supported:

  • IE 10, IE 9, IE 8
  • Chrome
  • Safari
  • Firefox

Let’s start measuring

Let’s start by taking a look at how I’ve done my tests and what the results were.

Testing methods

Each test was executed 100 times and the loading time result I’ve used for each test is the average of the 100 attempts. These tests are executed in a virtual environments so obviously the exact timings will differ from your environments – what’s mostly interesting right here though is the relative difference between having JSLink set and not set when rendering a list view, so that’s what we’ll focus on.

I’ve performed these tests on IE 10 and the latest version of Firefox. Since older browsers may handle scripts in a less efficient way than these two versions of the browsers, you may experience different results when using for example IE 8.

Results overview

SharePoint 2013 is pretty darn fantastic in its way that it renders the contents and pages. The measurements I’ve done here are based on the entire page and all contents to load. The chrome of the page (Navigation/Headers etc) loads instantly, literally in less than 25ms but the entire page takes longer since the content rendered for the list view will take considerably longer. Here’s the output…

Using 100 Item Limit in the View


Difference: 969 milliseconds


There’s not really much to argue about with the default 100-item limit. There’s a difference on almost one second, which is pretty bad to be honest. I would definitely revise these scripts and optimize the performance if I wanted quicker load times. However, if I changed the scripts and removed the rendering of images and used plain text instead, there was very little difference. So I guess it comes down to what you actually put into those scripts and how you optimize your JavaScript.

Using 500 Item Limit in the View


Difference: 529 milliseconds


The load times are naturally longer when returning 500 items, but the difference was smaller on a larger result set. I also performed the same tests using 1000 item limit in the view, and the difference per page load was between 500ms to 1000ms, essentially the same as these two tests. If your page takes 7-8 seconds to load without the usage of JS Link like these samples did in the virtual environments, I’d probably focus on fixing that before being too concerned about the impact the JS Link rendering process will have on your page. However, be advised that if you put more advanced logic into the scripts it may very well be worth your while to draft up some tests for it.

Things to take into consideration

  • The sample script here only replaces some strings based on the context object and replaces with an image. No heavy operations.
  • Replacing strings with images took a considerably longer time to render than just replacing text and render. Consider the code you put in your script and make sure you’ve optimized it for performance and scope your variables properly and so on.
  • Take your time to learn proper JavaScript practices. It’ll be worth it in the end if you’re going to do a lot of client side rendering stuff down the road.
  • If you’ve got access to Scot Hillier’s session from SPC12, review them!


Its not very often I’ve seen anyone use 1000 items as the item limit per view in an ordinary List View Web Part. Most of my existing configurations are using 100 or less (most likely around 30) items per page for optimal performance – however should you have larger views you should of course consider the impact the rendering will have if you decide to hook up your own custom client side rendering awesomeness.

You’ll notice the biggest difference between page load times if you’ve got a smaller item row limit in your view, simply because it looks like using the custom JS link property adds between 500 – 1000 milliseconds whether if I’m returning 100 items, 500 items or 2500 items in my view. Worth considering.

With that said – It’s a pretty cool feature and I’ve already seen a lot of more use cases for some of my clients to utilize these types of customizations. It’s a SUPER-AWESOME way to customize the way your list renders data instead of converting your List View Web Part (or Xslt List View Web Parts and so on) into Data View Web Parts like some people did with SharePoint Destroyer.. Err.. SharePoint Designer. For me as a developer/it/farm admin guy this will make upgrades easier as well (hopefully) as the list itself will be less customized, and only load an external script in order to make the customizations appear. Obviously I’m hoping for all scripts to end up in your code repositories with revision history, fully documented and so on – but then again I do like to dream :-)


Follow me

Tobias Zimmergren

Product Owner, Cloud Offerings at Rencore GmbH
Tobias Zimmergren delivers high-quality articles about business and technology around the Microsoft scene.

Tobias focuses on advisory and consultancy for the Office 365 and SharePoint offerings from Microsoft.
Follow me
  • Henry Johnsson

    Interesting it doesnt seem like it takes up too much performance to use this thing. but on small lists if it takes almost 500 to 1000 ms longer then its not good for our solutions actually but if quicker servers that are not on developer machine is quicker then it is a perfect thing. using this javascript custom is very cool to not have to use spd and other tools like these. just like u say in the other post u can just use this and dont have to convert to dvwp with spd.

    • http://www.zimmergren.net/ Tobias Zimmergren

      Hi Henry,
      You also have to consider that this was performed in a virtual development Environment (a very good one, but still not a huge awesome server). The measurements are relative, but I’ve found the same results on a server farm where I’ve recently tested it. Albeit the load times were slightly faster, we still saw the same performance difference with and without the JSLink functionality. Obviously a lot of this is going to depend on what the script actually does – but yes, it’s a pretty cool way to customize simple things in your fields/lists without the need for SPD or other deployments.

  • http://www.facebook.com/jthake Jeremy Thake

    Great overview of performance with and without JSLink in your SharePoint 2013 pages buddy. Seems that JSLink isn’t that much of an overhead on large datasets but noticeable on smaller ones.

    • http://www.zimmergren.net/ Tobias Zimmergren

      Hey Jeremy, thanks.
      I’ll be running up some additional tests soon to see how it handles more complex JS manipulations and how different browsers are affected, and I’ll also run them in a production environment with the proper hardware :-)

  • http://twitter.com/johnnliu John Liu

    Awesome stats, thanks for testing this.

    Are these times including the actual postback, or just the javascript processing after the http-response?

    • http://www.zimmergren.net/ Tobias Zimmergren

      Hi John,

      These times are the entire page load process, server and client side together. Measured from the point of requesting the page until the entire page is loaded including all scripts. I’ve done some client-only loading time tests as well with similar results.


  • http://goarticles.com/article/Custom-SharePoint-Development-Is-an-Extremely-Productive-Platform-That-Works-Great-for-Business-Applications/7298535/ Arsenio Lynn

    Using this java script customized is very awesome to not have to use sharepoint development and other resources like these.

    • http://www.zimmergren.net/ Tobias Zimmergren

      Hi Arsenio,
      In a way it’s still SharePoint development, but it’s just more focused on client side tasks than server-side deployed code. And yes, it’s pretty slick :-)

  • http://twitter.com/sharepointapp SP Innovations

    Great post

    • http://www.zimmergren.net/ Tobias Zimmergren

      Thank you, appreciate it.

  • Pingback: SharePoint Saturday 2013 Belgium - Farewell XSL, Welcome Display Templates - E. Struyf's Blog - E. Struyf's Blog()

  • http://therelentlessfrontend.com/ Aackose mentulal

    Very useful post & statistics. Exactly what i was looking for.

    I was planning on creating a dashboard with multiple JS links based LVWPs. Now i am having second thoughts on if this would affect the UX in case of smaller lists.

    I guess the “RenderListView” method in “clienttemplates.js” is a good starting point to analyze how MS does the templating and rendering of List Views. There seems to be quite a handful of timers, recursions going on in there to render the ListViews.

    • http://www.zimmergren.net/ Tobias Zimmergren

      Hi Aackose,
      Thank you for your comment. Some time has passed since I did these initial tests, and I’m sure there’s some improvements in the platform in general, but as always with any technology you should always perform some basic tests or estimates of the impact a solution can have.

      I’ve implemented JSLink-based solutions for a lot of things already and most of them run just fine – it’s important to make sure the scripts are well written though.


  • Pingback: Personnaliser vos sites SharePoint 2013 avec le Client Side Rendering (CSR) et le JS Link | SharePointerie.com()