You are sure that's the problem? Do you get a similar poor performance if you try updating a page? (Which will clear episerver cache in background)

Daniel it`s not about Edit mode. The very first request to a page is causing a precompilation of a view, next request are fast. Warmup module would be a solution here, but at this point it`s not starting for me.

I'm not talking about edit mode though. I'm talking about that there are several reasons why the first request to a page is slow. The most common is that Episerver hasn't had a chance to cache anything yet for that page. How do you know that it's the precompilation that takes time? Just so you spend the time on the right thing. Might be worth measuring first if you haven't...

Are you talking about the DXC Service of hosting a regular Epi-site in Azure?

It is true that the initial load after deployment takes some time (most of the site are beeing loaded up into memory) so the best thing to do is to make a run yourself before letting the visitors access the site. This can be hard on Azure, but I hope that is what hosting are doing, or doing a staged deploy in Azure (as you also can do) since that will help.

I trigger a webcrawler on a few websites after deploy (like old Siteseeker) to check both on new 404s and 500s and also to get rid of that first request time...

On some others I have a custom scheduled job in Episerver that does a similar thing (mostly used for caching external datasources though but the principle is the same)

Ok, sorry I didn`t mention it happens only after a deployment. I was mesuring it, and was experimenting with clearing the Episerver cache. I have seen the issue only for the very first request to certian page, that is why I`m sure it`s precompilation to blame.

Sounds like a thing the DXC guys should be able to take care of then...

Ok. Well, the first requst to a page fills up the cache and if you have empty the cache it will need to load it again and it not so much the precompiling of the view, more the read to the database to get the information of the page.

I saw that you already tried this out, did you get it to work?

http://world.episerver.com/blogs/per-bjurstrom/archive/2012/9/episerver-7-startup-performance/

Yes I`m on DXC. And DXC guys, didn`t manage to fix it, as there is nothing wrong from Azure perspective. I was directed to developers, and after a month of waiting, the answer was -> You can try to add a viewengine that would support compiled views (as Episerver is not supporting it). It looks like a chalange, and at this point I don`t have any more time for experiments on this. So the only solution for now, is to use webcrawler or schedule job to warm it all up :/ (my issue here would be, that I would need to warmup like 100 domains at the end)

@Henrik -> It was for different project. But will try to enable it here, thanks for remainding it.

Great, take a look at this also

http://www.epiwiki.se/troubleshooting/core-functionality/long-time-to-start-an-episerver-cms-site

This is a list of debug tools available which may help you get to the bottom of the issue:

http://www.david-tec.com/2015/02/episerver-debugging-tools/

Ok, thanks for links guys.

Was checking the meters, and can You confirm it`s normal that there is so much difference between my local & QA vs PROD ?

LOCAL -> Startup Performance View - Number of time meters: 75. Total time: 3.62 s.
QA (VM) -> Startup Performance View - Number of time meters: 75. Total time: 4.07 s.

DXC PROD -> Startup Performance View - Number of time meters: 75. Total time: 21.56 s.