1

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

Improve this question
4
  • 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. Commented Apr 29, 2013 at 16:53
  • Would executeOrDelayUntilScriptLoaded cause a timing gap? I will try Chrome, but I'm not so familiar with it's debugging tools. Commented Apr 29, 2013 at 17:33
  • Weird, Chrome has no gaps. Perhaps the Developer tool creates those gaps by writing header information or such? Commented Apr 29, 2013 at 17:52
  • possibly, all I know is rule #1 in development: Never expect miracles from Internet Explorer, especially concerning client side code :-p Commented Apr 29, 2013 at 17:56

2 Answers 2

Reset to default
1

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.

Improve this answer
5
  • Not sure if that's the case, JavaScript wouldn't care if you were just deployed, server side code is what feels sluggish afterwards... Commented Apr 29, 2013 at 16:54
  • You have to think about that ask data to client.svc that is hosted on IIS Commented Apr 29, 2013 at 16:58
  • Good point now that you mention it, so my curiousity is how fast does this happen after reload? Commented Apr 29, 2013 at 17:07
  • because IIS has all the data in memory. Commented Apr 29, 2013 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. Commented Apr 29, 2013 at 17:32
1

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)."

Improve this answer
1
  • 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. Commented May 1, 2013 at 16:02

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.