Lesson 1: Pay Attention to Page Size
As you develop SharePoint sites, you need to keep in mind that the out-of-the-box SharePoint pages have a large payload to begin with. For example, the out-of-the-box SharePoint Publishing Site home page makes 37 requests and downloads a total of 635,348 bytes, as clicking the screenshot below shows.
As you add new graphical elements, content, and functionality to your pages, the page payload increases even more.
To make sure that your pages are as small as possible and load quickly in a web browser, you can take advantage of the following techniques.
The same principle applies to CSS files. However, this might not always be possible to do, depending on how your components are architected. So, you should combine all your CSS files into a single file whenever possible.
.js) and the minified JQuery UI library (jquery-ui.min.js), which are part of the Microsoft Ajax CDN (www.asp.net/ajaxlibrary/cdn.ashx).
CDNs have two benefits. First, they speed up loading assets. Assets are loaded to users’ browsers from the closest servers possible.
Second, CDNs reduce the amount of bandwidth consumed between the SharePoint servers and browsers, thus saving you money on bandwidth usage.
For example, in one of my client’s websites, I found comments in a previously deployed master page that added 5KB to the page payload size.
Comments can be very helpful during development, but whenever you can do so, eliminate comments from the assets you deploy to your website.
Turn off View State. Another overlooked performance tweak is turning off the View State mechanism for the controls you place in web pages. This helps reduce page payload considerably.
Unless your controls require that the View State mechanism be enabled, turning it off won’t adversely affect your website. For anonymous public-facing Internet sites, View State typically isn’t required.
The amount of data that a control stores in its ViewState property varies. A small view state of 1,500 to 2,000 bytes is pretty typical for a page in a SharePoint website.
However, you’d be surprised how many SharePoint sites have a view state of 9,000 bytes or more. It might not sound like a big difference, but the bytes add up.
Load content asynchronously. Lazy loading content asynchronously, and only as needed, is a slightly more advanced technique to reduce page payload. This technique reduces the size of the initial page load.
Sometimes the reduction is substantial, but it depends on the design and functionality of the website. The JQuery library makes implementing this approach easy.
The Visio marketing website screen shot shown below provides a good example of this technique.
In the screenshot below, the red boxes indicate where users can click to load additional information, without refreshing the web page in the browser.
The initial page load for this web page uses 70 requests to load a total of 895,040 bytes. Without asynchronous content loading, there would be 22 additional requests and an additional 729,549 bytes loaded.
Other files you can typically suppress are the cui.js and core.js files. Collectively, these files add three requests and 233,099 bytes to your page payload size.
This technique requires the greatest amount of testing to ensure that your website will perform properly when these files are suppressed, especially if you’re using a large number of out-of-the-box Web Parts.
Also, keep in mind that if you’re using SharePoint’s ECMAScript Client Object Model, the core.js file shouldn’t be suppressed. To learn more about this technique, check out Chris O’Brien’s excellent blog “Eliminating large JS files to optimize SharePoint 2010 internet sites."
Understanding the various options to reduce page size can help your SharePoint websites perform well.
However, in the real world, not all website projects have the time or budget allocated to implement all of these techniques. It’s certainly possible to create SharePoint websites that have acceptable page payload sizes without implementing all of these techniques.
Also, keep in mind that page payload size isn’t the only factor that makes a fast SharePoint site.
Many other performance considerations should be taken into account, such as the quality of your custom code, cache setup, server farm hardware, and network configuration.
See Lesson 2 from Todd Baginski: Use the Content by Query Web Part.
See Lesson 3 from Todd: Learn How to Enable Anonymous Users to Rate Content.
Or go back and see the back story on how Todd learned this.