INTRODUCTION

This is a series. The previous article can be found at Series 2.

Now we’ve arrived at the customizations topic. Customisations obviously cover a broad range of topics. Therefore, in this particular article I want to discuss only the basic elements and some tips that we can do to increase performance.

SHAREPOINT CUSTOMISATIONS IN GENERAL

Disposing SPWeb and SPSite and other disposable objects

We’ve now read a lot about this. Ensure that you dispose SPWeb and SPSite and other disposable objects properly. In MOSS, the navigation provider for example, needs to be disposed after use. When we don’t dispose these objects properly and only relying on Garbage Collector, we’re exposed to the risk of having memory leaks. The more users access this particular part of the code, the more severe the impact is to your RAM.

Use reasonable-sized images and media files

Although when you’re using SharePoint as Intranet it’s usually reasonably quick (because it’s local to the network and using network speed instead of WAN speed), it’s still good to use and upload reasonably-sized images and media files. It will save you a lot of bandwidth.

Eg. Why would you upload 3000×2000 image if the general maximum resolution you use in your company is only 1024×768.

Also, when you’re customising the UI of your SharePoint site, use GIFs where possible. Gradient colours don’t normally work correctly on GIFs, they have to be JPEGs but JPEGs are generally larger than GIFs.

Applying general good coding practice

MS has released a page in MSDN detailing good Sharepoint coding practice. http://msdn.microsoft.com/en-us/library/bb687949(office.12).aspx.

There are things like:

– Disposing SPWeb and SPSite;

– Using SPQuery instead of SPList.Items;

– etc

Use cached resultsets

You can cache resultsets if you wish. I’ll talk more about this later. Basically, instead of you keep re-iterating list items directly using SPList and SPQuery, you can save those SPListItem collection/resultsets using custom entity wrapper in cache technologies such as .NET Cache, Memcached, etc and only interacting with the cache.

Things like iterating all sites and sub-sites can be expensive, too. We can save a lot of database round-trip when we interact with cached resultsets instead of with SPWeb/SPSite directly.

SHAREPOINT CUSTOMISATIONS FOR INTERNET WEBSITE

You can use SharePoint as your internet website, too (ie. MOSS Publishing Site). And normally you will turn on anonymous access. The rule of thumb is, our website has to be quick and should load as fast as possible. The things that affect loading speed are:

– HTML source size;

– Image and media elements size;

– Script size (eg. Javascript that’s referenced by your website);

– Other referenced file size (eg. CSS);

– Length of page scroll. The longer the page is regardless how small/plain it is in size will still take some time to render on user’s browser.

With these things in mind, we can configure our MOSS site to be as “small” as possible:

– Hide CORE.JS from anonymous view. CORE.JS is only used to perform SP-related javascripted-tasks such as clicking on Site Actions displaying sub-menu drop-downs, etc. Anonymous user doesn’t need to see this hence can be hidden. This will save you several hundred kilobytes!

– Avoid web-parts and use custom controls instead. Web parts spit out nasty and uneccessary HTML code. Not only they’re not XHTML compliant, they’re also adding few KBs to your overall HTML source size. If you have multiple web parts on your page, they can surely affect your overall HTML source size.

– Hide SharePoint-related CSS (such as CORE.CSS). This is used to style the SharePoint-related menus and controls. Anonymous users don’t need to see this either. This can save you several KBs, too.

CONCLUSION

So I hope that this helps. If you come up with other suggestions please let us all know.

Cheers,

Tommy