Can't see your attached picture.
Anyways you could add a setting to your OWN initialization modules to not to load when certain key is in the appsettings, to improve your start-up. BUT, the idea of initialization modules IS that those are executed before the application starts accepting requests and render content - and other code can trust that correct initialization has been done. So in that sense you might just create other issues in your app.
If your startup takes long, you should investigate your OWN modules, what takes there so long and if there is something you could improve.
Link to the screenshot that I tried to post.
But that screenshot shows thta your initialization modules are executed in 24 seconds. So something else is adding to your startup time to return the content, one thing is the view compilation(s). Traditional HDD vs SSD makes a difference in startup (it can be half of the time on SSD what it is on HDD).
I would use diagnostics tools to identify what is going on, where the additional time is spent. I suppose this is your sites start page loading? Are the next request to the start page fast after the initial request? If so, do you have some cache / service initialization done when the page is loaded, like building a huge main navigation, etc what is not done initialization module but when something is requested the first time. Anyways debugging/analyzing the code paths will indicate where the most time is spent -> so have a look at those.
How is the initialization timings in your test/qa/prod environments?
One thing you could look for is your log4net logging strategy. I was working on a project for which most of our logger level were set to Info or Warn (EPiServerLog.config) and they were producing a lot of entries into our logs on startup.
On DEV, we changed the level to Off and we saw a huge loading time difference.
We have found the same issue with Find.Commerce being extremely slow.
For custom init modules/code we have added an appsetting that we can change on develop that we use with custom code to disable the longer running custom startup items when needed but ofcourse with epi built in items its not great to just go switching them off.
My goal is to get our feedback cycle reduced from the time we make a code change to the time that the application renders in the browser. Currently the first request is taking around 1.1 minute.
Below is the output of the "Startup Performance" feature from Episerver developer tools (https://github.com/episerver/DeveloperTools)
My question is, how can we eliminate these from startup? We may want to toggle them off during development cycles. Is that possible?