Sitecore 8 is pretty nice, but not without its share of rough edges. One persistently annoying issue I came across is that after you compile your solution in Visual Studio, it is glacially slow to start up in Experience Editor (formerly Page Editor) mode. Given that most sites built in modern Sitecore fashion are using component based architecture that is Experience Editor centric, this is a big drag on development time.
In this post I’ll outline the story so far, and some tweaks you can perform to improve the performance of Sitecore 8 after a compilation.
As a baseline, on my i7-3770k, 32GB RAM, and all-SSD system EE 8.0 takes 1:30 to startup after a compile. Yeah, a minute and a half. Sitecore 6.5 will start in the same situation in 0:21.
Option 1: Precompilation
John West and Kevin Obee noted that I should try disabling the SPEAK precompilation features. These are in the <initialize> pipeline and registered in Sitecore.Speak.config and ContentTesting\Sitecore.ContentTesting.config. If you comment these out, you trade having the SPEAK interfaces come up slower the first time (because they are not precompiled) for faster initial startup time (because you skip precompiling).
With those two precompilers commented out, my startup time dropped massively to 0:41. Still twice as slow as Sitecore 7.2, but oh so worth it when you’re compiling all day.
Option 2: Optimize Compilation
Still unsatisfied with spending 20 seconds compiling unchanged .cshtml SPEAK views every time I compile my application, I started looking around into the actual compilation process. An interesting facet of this issue is that it’s not triggered by simply restarting the app pool. You must touch an assembly in the bin folder to trigger the slow startup.
A clue came in the form of this StackOverflow answer from @pbering. He mentioned enabling the optimizeCompilations setting in the web.config. What does this do? Well, off to MSDN. If you read this document, it makes it clear that when you change a top-level file (which includes anything in bin) it invalidates all dynamically compiled assets because a dependency of their compilation has changed. Razor files, such as what SPEAK uses, are dynamically compiled - .NET parses them, compiles them to a C# class, and stores them off in the Temporary ASP.NET Files folder.
So essentially what happens is that Sitecore 8 depends on a WHOLE LOT of dynamically compiled SPEAK renderings. When you start it up the first time, ASP.NET compiles them and stores them in its compilation cache. As long as you don’t change any dependencies - e.g. dlls, global.asax - .NET can update the cache selectively when the cshtml file is changed, and it’s fast. But as soon as a dependency is changed - e.g. your site dll - .NET throws out the whole site’s cache and compiles it all again, just to be safe. With Sitecore 8, this takes 20-60 seconds at least.
You can instruct .NET to ignore dependency changes and only recompile dynamically compiled files when the file itself is modified. This has some potential dangers if you modify a dependency without changing the dynamically compiled file and make a breaking change; see the MSDN article for details of the things to be aware of if you enable optimization.
The good news is, if you turn on <compilation optimizeCompilations="true"> in your web.config, there is no longer any SPEAK recompiling on startup! Even better, it starts up in 0:13, beating 7.2 by 8 seconds!
That said, be aware that there are significant issues to be aware of when enabling optimizeCompilations. Read the MSDN article. I have not deeply tested using this setting, other than it removes the startup speed issue. If you run into problems, stopping IIS and clearing the Temporary ASP.NET files folder should clear it up. Rebuild may not help.
Option 3: Disable the SPEAK Experience Editor
A separate ticket on Sitecore support (relating to EE in Sitecore MVC) rustled up this other possible solution: disable the SPEAK-based Experience Editor, and go back to the Sheer one from previous Sitecore versions. This removes all cshtml compilation issues from the equation, and feels slightly faster in the browser to me. It has a less-polished UI appearance however, likely due to it not being a priority to reskin :)
To disable the SPEAK EE, open App_Config/Include/Sitecore.MvcExperienceEditor.config. Locate the comment around like 33 regarding ‘uncomment the page extenders below to switch to sheer’ and follow the directions in the comment.
Hope that helps!