Improving SharePoint Performance (Publishing)

When viewing a publishing site created with SharePoint, the very nature of the websites presented are “read-only”. Another way you often hear it phrased is “public facing” websites – or anonymous publishing sites.

For some examples of SharePoint publishing websites, check out wssdemo. There are a list of the “best looking” websites hosted on SharePoint – as well as a full list here – grouped by industry sector.

A bunch of new issues & some problems arise with hosting a Publishing site, and exposing a website to the public, including security, content editing, publishing and searching (findability).

Often “last” on the list is the performance of a website. Again, this has many facets, including physical hardware (got enough RAM ?), network configurations, server loads (users) and bandwidth – and caching configurations within SharePoint.

One area that is easy to address, but often last-thought-of, or even considered – is simply reducing the “page size”. This will be quicker for the end user, and will reduce some load on the IIS server hosting SharePoint – and network traffic.

SharePoint was traditionally a “corporate intranet” product, it’s called SharePoint Portal server for a reason ! The Publishing aspects have been added more recently, and has some quirks & hiccups – including page size – as well as accessibility and content shipping – some of which is (hopefully) on the “to do” list for SharePoint 14.

🙂

Anyway – as SharePoint is essentially an ASP.NET application on steroids, you can introduce some ASP.NET smarts to help reduce the page size – one aspect of performance that you can control – as a developer.

When you click on “View Source” for a SharePoint page, you will see a number of included JavaScript (js) and Cascading Style Sheets (css). It follows that some of these are only really applicable in an “editing” scenario.

This is certainly true for “init.js” – and “control.css”. These provide functionality to content editors, and other SharePoint internal/system users – not really needed for public, anonymous users (aka Publishing).

To remove these from the page – and reduce the page size significantly (400-500KB !), you just need to add a few tags to the Master Page. The premise is that certain SharePoint controls will be rendered for “author mode” – and when in Display mode, these files are not included (init.js / control.css).

Check out this article from thekid.co.uk – for the specific syntax – very handy tip.

———————————

As opposed to dropping files that are referenced from the page – another way is to have a look at the way that web controls are used *ON* the page itself – in master pages and page layouts.

ViewState is an ASP.NET concept that allows you to keep the “state” of a field, object or variable – when performing a page “POSTBACK”. These are needed when grabbing the text entered (TextBox), or determining which radio button or checkbox/es are selected.

Sometimes, the ViewState is not actually needed – like with a menu control, or when only needing to “display” a value. And – the ViewState is just a big long hieroglyphic text string, hidden in the HTML – so it’s actually longer than it needs to be, increasing page size.

This is the case when viewing a SharePoint “Publishing” page – most controls can be read-only (except for such fields as the “search box”) and thus no page state needed.

Again – SharePoint is a big ASP.NET application – and uses many, many ASP.NET controls – mostly with PageState switched on – which is fine and OK for an intranet portal (ie. back to SharePoint’s roots).

There’s (another) great article over at thekid.me.uk which shows some great techniques to turn off view state when in “Display Mode” – a very simple but effective concept.

This starts by looking at the ASP.NET page trace (control tree) to see what types of fields/controls are being produced by SharePoint.

From there, a look into the Master Page, to see what controls are corresponding – for example the “page title” control (TextBox/Label) – which needs ViewState in “edit mode” – so can’t just turn ViewState to off for this control.

The answer (from thekid.co.uk) is to create a “wrapper” control to check the “FormMode” of the current page – and if the page is “Display” – then the ViewState is switched to off (for as a TextBox, or menu).

By wrapping the control around a bunch of ASP.NET controls, SharePoint (or more precisely ASP.NET) will then switch off ViewState (or not) – and thus push out the necessary ViewState text (or not).

You’ll have to read the article from “thekid.co.uk” to see more, and grab a copy of the DLL to try for yourself – very cool. Thanks thekid !

———————————

Another way (*NOT* thekid.co.uk this time !) is to look below SharePoint, and underneath ASP.NET – to the IIS web server itself. The premise here is that web sites comprise of “static” and “dynamic” files.

Obviously, static files can be cached, as well as “compressed” – and thus smaller when transmitted to the browser (smaller page size).

IIS Compression allows you to specify certain types of files to include, which are zipped to a compression folder when first requested – and IIS will then use it from there afterwards.

An article here describes the concepts/how-it-works – Using HTTP Compression for Faster Downloads (IIS 6.0).

Obviously a “JS” file is static, and could be compressed – as well as a “CSS” file – and thus a prime candidate for this. Any aspx or SharePoint dynamic content is re-generated each time (as you’d want).

Another TechNet article here tells how to do it – enable IIS Compression within IIS 6.0 (Windows Server 2003).

———————————

As a last commentary, there is a great product that does optimization and compression (of sorts) – in a complicated but very clever way.

The RPO (Runtime Page Optimizer) is a software component for ASP.NET and SharePoint websites that automatically optimizes web pages to increase performance and decrease page sizes.

Faster pages mean happier customers, smaller page sizes saves bandwidth.

Runtime Page Optimizer (RPO)

The simple way to describe it is that a web page request from a browser is actually 20 or so requests to the same server to grab the JPG, CSS and other artifacts linked in the HTML/ASPX results. By combining some of these items together, you can reduce web server hits, file sizes and improve page size – and web server performance.

The complicated aspects of RPO is that many files are (JPGs) can be combined into ONE file, and the IMG tags changed to grab the correct region within the combined JPG.

It’s sooo clever, that it’s very hard to describe !

Here’s a brief blurb from the website :

These optimizations will speed up your site with no code changes.

1. Combine CSS files (stylesheets)

Combine multiple CSS files into a single file. Minify the CSS by removing whitespace and redundant characters. Set far-future-expiry dates on the file so the CSS file remains cached on the client machine until it changes.

2. Combine JavaScript files in the page head

Combine multiple JavaScript files referenced in the page head into a single file. Set far-future-expiry dates so the JavaScript remains cached on the client machine until it changes.

3. Compress HTML, JavaScript, CSS files

Apply GZIP compression to HTML, JavaScript, CSS files to reduce file size.

4. Combine consecutive JavaScript files in the page body

Combine consecutive JavaScript files referenced in the page body into sets. Set far-future-expiry dates on all JavaScript files reference in the page body so they remain cached on the client until they change.

There is a free trial – as well as an online page checker which allows you to test your own site – and some articles, including how to implement for SharePoint.

Some of the case studies show about 1/2 the page size – HALF !

There is some configuration you can do to “optimize” more or less compression – once you’ve installed the product.

———————————

Obviously ALL of the above is to be considered use at your own risk.

Ensure you perform lots of tests, and metrics – both BEFORE implementing any changes – as well as AFTER implementing such changes – test all page actions and functionality. By “stripping out” aspects of the page/s delivered can have some unexpected (and undesirable) results – if not careful…!

🙂

Advertisements

One thought on “Improving SharePoint Performance (Publishing)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s