When building SharePoint 2013 Apps, you will have to use either the JavaScript object model (JSOM) or the .NET client-side object model (CSOM). Both of these APIs follow a batch-oriented programming model. That is, you call some methods which queue up data queries and other operations and then you call a method to execute the queued methods.
For example, using the JSOM model in JavaScript, if you needed to load a web’s content type collection, you would do something like:
This code block queues requests to get and load the web’s content type collection. The commands are then executed using the executeQueryAsync method. The contentTypes variable is not populated until the executeQueryAsync method is executed.
This model works quite well but you have to be careful when loading collections of objects. In the above example, every content type property will be returned even if you aren’t going to use them. The responses can be quite large which will negatively affect performance. Microsoft knew this so they included the ability to control the properties that are returned when loading a collection.
In this example, I’ve told the load method to only pull back the Name and Id properties. It makes sense that this would perform better but how much better? I decided to use Fiddler to find out. If you haven’t used Fiddler yet, it’s available for free (at this time) at http://www.telerik.com/fiddler. Fiddler is a web debugging proxy that logs HTTP(s) traffic between your computer and the Internet.
Below is a simple SharePoint 2013 Client Web Part that displays a web’s content types. In this example, I use the load() method to load all properties.
The Fiddler response to the executeQueryAsync() call is:
As you can see, the request to load the content types and return the data took 1.6 seconds. The JSON response was 257KB.
I then modified the example’s load() method by adding the “Include(Name, Id)” string as the second parameter as shown below.
Here are the Fiddler results for the executeQueryAsync() call:
This request executed in 0.149 seconds and the response was 5KB. This second test executed in 9% of the time and returned 1.9% of the data. Quite an improvement!
So the next time you’re creating a SharePoint application that uses JSOM or CSOM, be careful with how much data you pull back. You can see from the above numbers that your users will be happier with the improved performance.
You can download the sample app part from here.
Edgewater Blog 