Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I'm working on a sample script that calls out to the User Profile service and retrieves some sample data. I noticed that when I deploy the Application page and render it, I get a considerable gap between the last web resource being loaded and then my calls being made (got it clocked in at .5s). The screenshot below shows after the result being called a few times in a row, so I have much lower exeuction times for the POST calls, but I still can't figure out why they just don't start after the last Web Resource is loaded. If anyone has a starting point on how to figure this out it would be a huge help. We also notice these gaps on pages where we're using Content Search Web Parts, so I think it's something to do with our server setup.

enter image description here

share|improve this question
    
Not entirely certain so this gets to be a comment. Plenty of SharePoint JavaScript uses functionality to wait until everything is loaded before running (or look up executeOrDelayUntilScriptLoaded in SharePoint). My one thought would be to try under different browsers and measure that way. –  tekiegreg Apr 29 '13 at 16:53
    
Would executeOrDelayUntilScriptLoaded cause a timing gap? I will try Chrome, but I'm not so familiar with it's debugging tools. –  EHorodyski Apr 29 '13 at 17:33
    
Weird, Chrome has no gaps. Perhaps the Developer tool creates those gaps by writing header information or such? –  EHorodyski Apr 29 '13 at 17:52
    
possibly, all I know is rule #1 in development: Never expect miracles from Internet Explorer, especially concerning client side code :-p –  tekiegreg Apr 29 '13 at 17:56

2 Answers 2

it's usual after a deploy because IIS, ASP.NET, SQL and so one needs time to allocate memory, get information around, and send to you what you asked.

Indeed the others calls should be faster.

share|improve this answer
    
Not sure if that's the case, JavaScript wouldn't care if you were just deployed, server side code is what feels sluggish afterwards... –  tekiegreg Apr 29 '13 at 16:54
    
You have to think about that ask data to client.svc that is hosted on IIS –  Salvatore Di Fazio Apr 29 '13 at 16:58
    
Good point now that you mention it, so my curiousity is how fast does this happen after reload? –  tekiegreg Apr 29 '13 at 17:07
    
because IIS has all the data in memory. –  Salvatore Di Fazio Apr 29 '13 at 17:17
    
Sorry, I should have made this clearer, but this is well after a deploy. I know you can't see it (and I wasn't aware of this before I posted that you couldn't get the original size of the image) but the call to /_api/contextinfo in that run was 46ms, the shortest I've ever seen it. That was like the 10th run in a row. Regardless of when I run the test, there's usually ~1s gap between the last Web Resource and my POSTs. –  EHorodyski Apr 29 '13 at 17:32

I'll just post my answer as "The behaviors of different browsers can vary. Internet Explorer's JavaScript renderer in particular has many quirks that can slow performance down or give inconsistent results compared to other browsers. Likely there is no easy workaround for this short of using an alternate browser (and putting up with its drawbacks as well)."

share|improve this answer
    
If this is the case Microsoft has a support ticket coming. They usually design these things around IE, and if the CSOM/REST calls are so slow because of IE it makes no sense. How do they expect people to adapt their App paradigm if it takes forever for these calls to be made? I can confirm it's an IE issue as well. Chrome renders under a second (644ms for content, 966s with images) but IE lags to at least 1.4s. Thanks for the help. –  EHorodyski May 1 '13 at 16:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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