Page weight in SharePoint

When looking to design, build and introduce any SharePoint based environment into your business, like any web based development that is accessed via a variety of internet browsers, you need to consider (amongst a whole host of other things!) the page weight of your users home page. Be that the main intranet home page, internet facing, team or mysite page – which ever you have set to be the users main browser home page.

This is often forgotten in an age when rightly so, broadband is getting more prevalent and cheaper.

Nevertheless, organisations still have bandwidth demanding applications and is even more critical for enterprise size customers or when your users are dispersed geographically and accessing SharePoint over small network bandwidths, over remote connections and or when your existing network utilisation on these links is high.

I held discussions with a well known high street bank not so long ago about introducing SharePoint into its branch network, essentially to roll out a company wide intranet and in short, it was put on hold due to in part very small bandwidth links to its core branch network – circa less than 256k. Utilisation on these links was also quite high – 40-75% each day. And whilst a large LAN/WAN upgrade project was being considered, it was decided nonetheless to put the intranet project on hold until this was completed so as to not jeopardise the impact and hence adoption of the new intranet. It’s a decision I thoroughly endorsed.

During this period of evaluation we got to understand what SharePoint downloads all be it once during most users browser sessions. In short, there are about 300-400 kilobytes worth of javascript, other controls and files on a standard, out of the box SharePoint home page. This is before you add in any additional branding, custom web parts, content, etc. Hence you could very quickly come to a page which weighs in at 750k to over 1mb! It’s worth noting this is only for the first time and is cached for subsequent sessions (unless of course the cache is cleared frequently,i.e. when the PC is powered off or browser closed). Multiply this by 1000’s of users all logging on in the morning, you could well hit some thresholds on your bandwidth.

There are of course different types of optimisation you can do, like server side compression, but this requires considerable additional effort and change, if not planned for from the outset. But is nonetheless an area worth exploring if time and budgets permit.

More often than not its more or a local bandwidth issue nearest to the client, rather than the server side. Another consideration should be the timelines in which users will be logging on, i.e. when will performance ‘peek’. Of course, if your business is ‘bandwidth rich’, then it may not be a problem at all, but in my experience it’s always worth looking into it.

It’s recommended to thoroughly investigate this area prior to launch or when thinking of introducing other bandwidth demanding application via your SharePoint environment such as video streaming.


Andrew Walmsley



Technorati Tags: , wss,

One Response to “Page weight in SharePoint”

  1. Michael Gannotti Says:

    I have a number of clients in the banking industry as well as other clients with similar remote offices. One approach I have introduced many of them to that minizes this while maintaining network integrity as well as minimizing custom requirments is the use of eithe terminal services or Citrix as a means of accessing the portal and other Intranet services. In this instance the user only need pass the bits across the wire required to get a view of the resource as well as initiate and carry out interaction with it without needing to download all the contents. This allows them to move beyond simple page viewing and even carry out more robust collaborative tasks that may involve working with large file size documents.