We struggled with the same problem. We began compiling Views in order to catch obvious issues that would creep up on us during Integration Tests and UX Tests. Even worse were the bugs that somehow crept into production.
But, our build times became intolerable. Our developers build countless times and that became a major part of our day. We had jokes about testing after lunch so the build could be done while we were out.
We eventually moved to building before UX-tests.
Now we are moving toward pre-compiling. Only one guy on our team has adopted it for now and apparently pre-compiles are noticably better than builds (incremental vs total). And setup is basically a nuget fetch.
These articles should be a good start
http://stacktoheap.com/blog/2013/01/19/precompiling-razor-views-in-asp-dot-net-mvc-3/
http://blog.davidebbo.com/2011/06/precompile-your-mvc-views-using.html
Pre-compiling gives us all the advantages of deploying ready built binaries. Our users don't experience the momentary lag the first time a View is hit.
As far as I know IIS autostart = true
will start you Application Pool but will not force compile your Views. As a result, you're left with the initial start-up hit for the first user to use each View.