I'm a SharePoint user.

My company has introduced SharePoint and use it as their intranet site. They've made some changes to the masterpages, etc. to let the intranet have a 'corporate' feel. There is aboutn 5000 employees in the company, but I doubt that all of them uses SharePoint , nor all at the same time.

As far as I know from the IT department, the SharePoint (MOSS2007) installation runs on a monster of a server (clustered), with the SharePoint databases hosted on a SQL Server cluster. We also have a firewall and Proxy running in the office.

My question is, with my limited knowledge of SharePoint, and required infrastructure:

Why, if the SharePoint developers and IT department tells me that SharePoint is running on the best possible infrastructure, is it sooooo SSSLLOOOWWW.... to open pages, and browse the different pages, saving lists, etc?

Any help and/or understanding would be appreciated.

PS: I've heard we are upgrading to MOSS2010 soon...

  • 1
    To date I have not heard anything back from our developers or IT department regarding the questions I've posed to them as listed by Rob. I think that Rob covered most of causes why a Sharepoint site might be slow. The other answers also added to my list, but Rob's helped me in asking Why? to the Dev and IT dept. Lets hope I get an answer back from them, but in the mean time I'm accepting Rob's question list... err. Answer. Thanks for all the others, you've helped as well.
    – riaan
    Commented Dec 3, 2010 at 5:02
  • You have to do some profiling there, to find out what the bottleneck is. Is the database taking long to fetch results for queries? Is there any custom C# code that could be rewritten for better performance? Etc.
    – Geeky Guy
    Commented Aug 19, 2013 at 16:54

6 Answers 6


Be sure your hardware meets the recommended requirements (not minimum). Then you may want to run some of the administration reports to identify slowly loading pages. Some things to consider:

  • Are you running 64 bit or 32?
  • Do you have auditing turned on for all lists?
  • Are you displaying a relatively small number of items (100) per page on your list views, or are you displaying the entire list?
  • How much memory do you have on your SharePoint Web Front End Servers? On your SQL Server?
  • What else is running on your servers? (hopefully nothing)
  • Does anything show up in the SharePoint logs or Windows event viewer that would indicate a problem?
  • Do you need to use index columns on certain lists?
  • What is your bandwidth like?
  • Do you have code that runs when certain pages load (e.g. in the master page) that could be executed asynchronously instead of synchronously?
  • Do you have a large amount of content being returned on the pages? (use Fiddler to test http response time)
  • Do you have caching enabled?
  • Do you have custom code? Are objects being disposed of properly?
  • Is your SQL Server data on a SAN, NAS, local drive? What type of connectivity?
  • Is it slow on all workstations or just some? How current are your desktops?

In my experience, memory and pipe (inadequate bandwidth or network issues) are usual suspects. If it is a highly customized environment, custom code could also be an issue.

Every environment is different. It may be one of the things on this list, a combination of them, or something completely different. If there is nothing here that helps you, consider posting more detail about your hardware and specific pages. Solving performance problems in a distributed environment is never easy. I'm going to go out on a limb based on my experience and say that SharePoint is not the problem in and of itself.-

  • 8
    And add to that closed (not deleted) web parts (check for them by appending ?contents=1 to url). Also latency > 1ms to SQL server will impact performance. Do you have a (non SharePoint specific) virus scanner on the server? If so exclude logs and indexes (support.microsoft.com/kb/952167). SQL server is the heart of a well performing SharePoint installation, so configure it for performance. Commented Nov 24, 2010 at 8:06
  • Oh and i would give Rob's comment +2 if i could ;-) Commented Nov 24, 2010 at 8:07
  • Thanks. I've relayed your questions to our developers and IT department. As soon as I have more info (if and when they reply) I will provide you with some feedback.
    – riaan
    Commented Nov 24, 2010 at 14:17

I'd also check to see if there are any Sharepoint lists using item-level permissions. Item-level permissions will dramatically slow things down when the list size starts getting big(a few hundred items). Also, the recommended maximum number of items in a list is 2000. If some lists are getting towards that size you might want to break them out into difference lists or nest items within folders.

One other thing to look at in any custom code that may be deployed is how lists and listitems are retrieved. If there are a lot of calls to retrieve lists using the default:

SPList aList = SPContext.Current.Web.List["aList"]; 

it could slow things down. The reason is that in this case Sharepoint retrieves all the lists on that web, then selects your desired list. A much faster way to retrieve a Sharepoint list is to use:

SPList aList = SPContext.Current.Web.GetList["/Lists/aList"];

By getting lists by relative URL you are saving the overhead of getting every list. We got a big speed boost in one part of our application just by changing our calls. There are also other ways to speed up caml and linq queries, but that's just a start.

  • Same for Items within a list! E.g. Always use SPList.AddItem instead of SPList.Items.Add. Further explanation can be found here.
    – Markus
    Commented May 20, 2014 at 7:42

SharePoint can indeed be a bit of a dog sometimes, but there is no reason it should be as bad as you make it out to be. Perhaps the problem is not really with the hardware, but rather a simple network related issue such as the one outlined here.

  • Thanks, I've forwarded your link to our developers and IT department, and await their feedback. As soon as I have any, I will add to SPO.
    – riaan
    Commented Nov 24, 2010 at 14:20

You might try enabling the blob cache on the web servers. This will allow files used by the pages; i.e. .js,.css and images, to be cached on the web server instead of being pulled from sql each time.

About the blob cache - http://technet.microsoft.com/en-us/library/cc261797.aspx#section3 Configuration - http://technet.microsoft.com/en-us/library/cc770229.aspx#BLOB


I ran into something similar (though might not be the same as you're experiencing). The solution made no sense to me at all, but resolved the EXTREME slowness and the client was happy leaving things as-is.

I posted about it here on Server Fault: https://serverfault.com/questions/149320/further-performance-tuning-on-medium-sharepoint-farm

And here is the direct link to the solution that we implemented (about 1/2 way down the page - turning off compression): http://social.technet.microsoft.com/forums/en-US/sharepointadmin/thread/694a9a01-3371-4037-9d18-cf8895654996/

  • 1
    Your "answer" is really just links without any real content. Read the FAQ if unsure why this is not consistent with the StackExchange model for answers.
    – Argalatyr
    Commented Jun 29, 2011 at 3:55

Browsing to a site for the first time after the underlying IIS App Pool is recycled is extremely slow. To solve this, you can run a wakeup (aka: warmup) script that simulates hitting your SharePoint sites (there are a couple of free scripts posted by developers that you can search for). Schedule the script to run soon after a scheduled IIS recycle. For instance, my App Pool is scheduled to recycle daily at 2:00AM. I then have a scheduled task to run the wakeup script to run at 2:02AM. Do this early enough as depending on the number of sites you have, this may take several minutes to a few hours.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.