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.

Baginski WCM Fig1_0

Many of these requests are for JavaScript files and Cascading Style Sheets (CSS) files.

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.

Combine and minify JavaScript and CSS files. To help keep your pages as small as possible, you can package and deploy your CSS and JavaScript files with the following guidelines in mind.

Whenever possible, combine all of your custom JavaScript files into a single file. This reduces the number of requests the web browser has to make to the SharePoint server and cuts down on page load time.

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.

In addition to combining all your JavaScript and CSS files, minify them whenever possible. For example, you can remove the white space and line breaks in these files to make them as small as possible.

Use content delivery networks (CDNs).
When possible, you should use CDNs to load JavaScript files. For example, you can use the minified JQuery library (jquery-1.6.2.min
.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.

Remove comments. Removing comments is perhaps the most often overlooked performance tweak you can make to a website. Many times developers don’t remove comments from the JavaScript files, CSS files, page layouts, or master pages in their SharePoint sites before deploying them to production.

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.

Baginski WCM Fig2_0



In the screenshot below, the red boxes indicate where users can click to load additional information, without refreshing the web page in the browser.

Baginski WCM Fig3_0

Each time one of these regions is clicked, an asynchronous call is made to retrieve the corresponding image. By taking this approach, only the initial image is loaded when a user first visits the website.

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.

Suppress JavaScript files for anonymous users. Another advanced technique to optimize the size of your page payload is suppressing the loading of certain JavaScript files for anonymous users. For example, anonymous users don’t interact with the ribbon on your SharePoint site, so loading the sp.ribbon.js file isn’t required.

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.