We are trying to resolve some performance issues at a remote site.

One thing that we suspect could be causing the performance problem is page ghosting.

Is there some way to see if the pages that are being called are ghosted?

  • Please be clear: What do you mean by 'calling'? What is the method you prefer to utilize: Object Model, Web Services, FP-RPC? where should the check occur: on the client or server side? Commented Mar 5, 2010 at 13:36

7 Answers 7


In my experience, the ghosted/unghosted thing is a total SharePoint myth. If you're having significant performance issues with a page, I sincerely doubt that this is the problem. I'd look more at what Web Parts are on the page and what you're asking them to do.

  • That pages can be ghosted is definately not a myth (we've had this discussion before, right? :-). If it affects performance or not? I have seen no solid evidence one way or the other. One thing is certain though: ghosting is a pain when you want to upgrade artifacts! Commented Mar 6, 2010 at 12:47
  • Oh, ghosting/unghosting is real, no debate about that. Sorry if I wasn't clear. The performance thing is what I say is a myth. Commented Mar 6, 2010 at 15:25

Solving performance issues in SharePoint by second guessing what the problem could be could be a very long and tedious process.

What you should do is give the site a thorough check-up for issues that could affect performance (and yes closed web parts is one on a probably very long list).

Other candidates:

  • large site collections(>100gb), large lists (>2000 items ) etc (read Plan for Software Boundaries on TechNet)
  • is caching enabled? Output caching, BLOB caching, HTTP compression
  • custom code. Probably the worst contributor for bad performance. Is specific pages slow or is the pages slow in general? Does your code dispose its SPRequest objects (watch memory consumption). Read this and this.
  • alerts in eventlog or 12 hive logs. low disk space? low on memory? are you using 32-bit?
  • sql server is the heart beat of a well performing SharePoint. Check for alerts in event log.
  • faulty NIC. I have seen this wreck performance on an otherwise well performing site.

  • how large is the footprint of your pages? If you need to load tons of
    CSS, JS and images by every request
    (without caching them) this could
    kill performance as well.

  • in general: is your servers set up according to best practices? Read more on technet

This was a few of the issues i would consider, again depending on what kind of patterns for bad performance you experience (you dont describe this in your question).


I asssume by 'called' you mean by the browser.

If you just want to see if a given page is customised then you can look at the pages in SharePoint Designer as this will show you quickly which ghosted pages have subsequently been customised.

customized file in SPD http://www.code-storm.co.uk/resources/pb/Customized.png

Of course if you need to do it via code then this is not a viable approach.

Have you checked out the site with Fiddler to see what is happening under the covers?

  • Its the blue icon by the way...Should have said that. Commented Mar 5, 2010 at 14:17
  • Yup Marc's point is really valid too, check for closed web parts first. Commented Mar 5, 2010 at 20:03
  • For the end-user, Charles' post could be marked as the answer I believe if the question is 'how to check if a page is ghosted/customized' Commented Mar 9, 2010 at 18:15

As Marc said the issue may not be the ghosted/unghosted status of the page but...if you do want to check the status of the page then SharePoint Manager is a really useful tool for looking at properties of SharePoint objects. This should save any time writing code to do the check and if the page is unghosted then 'customizedpagestatus' will show customized.


As Marc said above, check the number of web parts and what they are doing. Especially check if there are a large number of 'Closed' web parts hiding behind the scenes from power users not understanding the difference between Delete and Close. They are not visible but will continue to consume all those resources. Almost every time I assist someone with a performance issue on a site, its due to >= 10 Closed web parts.

  • the replies are ordered by rating here, so 'above' might turn to 'below' at some point, so better use the 'link' button or just omit such potentially misleading pointers. Sorry for being off topic. Commented Mar 9, 2010 at 18:07

Another issue to check and this may seem strange is to find out if you have custom built webparts that have code. It is possible that some of them may not be properly releasing the resources they used. This is just an addition to the other points already mentioned.


My 5 cents: If that's an option at all, you could check the ASP.NET trace timing to see the shares of each control rendering or not rendering in the page's control tree. See web.config/system.web/trace for the application pool in question and add trace.axd in the url (or set the pageOutput attribute to 'true' for the trace element in the web.config).

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.