We've implemented a custom web part which we use to render content of an external website into a SharePoint page.

During our test we encountered some strange performance issues.

When we open a page with the web part for the first time it takes about 5 - 7 seconds to load the entire SharePoint page. If we then quickly (within the next 20-30 seconds) load another page with the same web part or click a link within the web part which reloads the page the whole page loads within 400 to 700 milliseconds.

But when we wait for a longer time before loading a new page or reloading the page the whole loading process of the SharePoint page takes again about 5 to 7 seconds.

The logic of our web part is very simple. Every time it loads, we dynamically request content of the external website. We don't use any caching mechanism in our web part.

To find the reason for the bad performance we activated the developer dashboard with extended tracing and and could see the event/step which takes so much time. Unfortunately we don't know what SharePoint does in this step. And also Google has no information for us on this.

enter image description here

6 Answers 6


Is it possible to do a similar trace on the external web page you are getting your data from? If this page is suffering from the performance inconsistency you may have found your culprit.

If not, can you replace the external page with a mocked up static page that you control? If you can control the datasource it will help you ensure that anything you are doing has a beneficial effect on performance.

  • You were right, we checked the website we were requesting and we could and it showed the same performance issues.
    – Flo
    Commented May 13, 2011 at 11:21

This is almost certainly due to the lack of caching on the content coming from the external site. How long does a request to the site normally take?

Consider adding some caching, or displaying the content on your page asynchronously. And indeed, are you sure that you've not got a hidden list somewhere being used as a cache? i've seen that done. I presume you wrote the web part?


If your web part gets data from an external source, do this asynchronously if at all possible, as if the external source is down, it might time out the entire page.


Are you surprised to see that it takes 7 seconds, or are you surprised to see that there seems to be some caching going on somewhere, even though you have not implemented any?

I think the problem is more likely to be related to the actual datasource than your web part implementation.

Does retrieval of the data involve an HTTP web request (like screen scraping)? If there is a Proxy server in the middle, then this could explain why there might be some caching in place, as the proxy server could potentially cache the response for a short period.


It sounds like your query, probably on a list, is returning too many records or is inefficient. SharePoint could be caching the objects it returns internally, or it could be optimizing the query on requests after the first. This would lead the behavior you are seeing. I have seen that myself. Adding a RowLimit to your query, or limiting the view row count, or adding indexes to your list may help.

have you reached any of these limits:


  • Thx for you comment, but our web part doesn't query any SharePoint list. But I will double check this perhaps some thing does a query implicit.
    – Flo
    Commented May 13, 2011 at 9:51

Adding SPMonitoredScopes to your code will allow you to see time spent in your own methods in the developer dashboard. This is invaluable in tracking down performance issues.

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.