Slow initial page load in development

Vote:
 

Hey guys,

I've worked on a few episerver CMS projects and one thing about developing on them is that it's really time consuming waiting for the initial page to load after a rebuild.

The build itself only takes a few seconds, but when trying to load a page on the epi site, it takes minimum of 3 - 5 minutes before it actually appears.

Although, once the initial page loads, everything else on the site is quick and behaves as I expect it to.

I've asked around, and other epi devs just say it's something they put up with, but my question to you guys, is this really the case? Do you really have to wait a few minutes between each build to test out your changes?

What are some settings I could look at to improve the initial page load speed? Are there any tools you guys would recommend to diagnose where the bottleneck may be?

#201505
Feb 21, 2019 8:22
Vote:
 

That is quite slow. Any more than 2 minutes and I would be annoyed.

Does first load feature many blocks, images or content links?

The first load is always slow, because Episerver is loading itself, as well as add-ons and custom initialization modules.
Because the content cache is empty, Episerver loads the requested page from the database, including all content items used on that page (one item at a time). On second load, content is served from the content cache.

I usually use dotTrace and SQL Server Profiler to profile a slow site. dotTrace will show which code paths are slow and why. SQL Server Profiler will show if the database queries are the bottleneck.

#201510
Feb 21, 2019 9:37
Vote:
 

This https://github.com/episerver/DeveloperTools would be very useful to find out which initialization modules are slow

of course if you want to break down to bare metal level, then suggestion by Stefan (dotTrace + SQL Server Profiler) is still the gold standard

#201512
Feb 21, 2019 9:52
Vote:
 

Have you got application insights installed I had to disable it in debug mode as was really slow for me as well

I now have this in my startup.cs 

#if DEBUG
            TelemetryConfiguration.Active.DisableTelemetry = true;
#endif

#201514
Feb 21, 2019 11:41
Vote:
 

3-5 minutes is a lot.

Some of the things that can affect startup times:

  • initialization modules and other custom code that is running on application startup (global.asax.cs, Startup.cs, etc.)
  • database (shared plans in Azure, etc.)
  • custom view engines (Episerver doesn't allow you to precompile razor views. If you have a page that contains a lot of blocks and block views are located all over the solution, startup times will be quite slow)  

  

Do you run the code in IIS Express or IIS?

Good luck!

#201519
Edited, Feb 21, 2019 15:28
Vote:
 

We are experiencing the same slow load times before the first page is displayed. Doesn't mater that it's CTRL F5 or just F5. We've experienced this for over 5 years now. Three minute load time is killing coding productivity.

#222228
Apr 30, 2020 18:58
Vote:
 

@Eric,
Have you followed Quan Mai's suggestions above?

#222266
May 01, 2020 15:29
Vote:
 

We have version 3.50 of EPiServer.DeveloperTools installed. I havn't looked at it myself. I did run /episerver/Shell/Debug/ShowTimeMeters and it was about 30 seconds total executaion for all episerver.

#222370
Edited, May 04, 2020 13:12
Vote:
 

Question. When I go to loacalhost/episerver, Developer Tools isn't anywhere to be found although it is installed.

#222377
May 04, 2020 19:51
Vote:
 

Just got Developer Tools working and we are seeing over 4 minute load times for our project. If we remove episerver, the loadtime is almost instantanious. Developer Tool shows episerver reources take between 30 to 60 second to load when ran from Visual Studio. Our developers are seeing over one hour per day in total wait time for the site to come up when ran from Visual Studio 2019. This has been happening for over five years.

#251314
Mar 24, 2021 16:25
Vote:
 

This thread is a little old / I'm late to the party but I'm wondering if you guys are using a local Sql Server instance to run development against. We get entirely acceptable performance that way. Doesn't blow your hair back, but not ridiculous. Just tried it now, 38 seconds to render the landing / home page after starting in debug mode. 16G RAM 11th gen I7 processor, VS 2022. VS 2019 was a little slower, but not much.

Our concern is more time-to-first-byte on our production environment. Our Cache-Control header is simply "private", no max-age or other directives. I am not super familiar with the possibilities here but from my reading, this is controlled in the IIS config, although you can get more granual programmatic control over it using ASP.NET Core middleware. That is not available to us yet, we're still on ASP.NET MVC, porting to Core after the new year. We have a ticket open to see if we can do something conservative with the cache-control header by getting Optimizely to set something in IIS, like cach-control private max-age=3600 or something to that effect, that's pretty conservative, if it has to apply to all dynamic pages. We're just seeing a reliable 1 to 2 second up-front, hold-the-show pause on the landing page render, for a first-time visitor ... while a little more browser caching won't help us with those particular visitors, it might ease the server load a little and help indirectly.

Open to things others have tried to improve this situation.

#266982
Nov 18, 2021 21:19
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.