This is not the same delay experiences when the first request arrives, but this is a delay that is experienced each time a Razor based view is accessed for the first ti
Webgrease. It minifies your production js and css bundles on first load, then caches them. Problem is that when the minification has errors it will try to compile every time, running whatever error routines are in there. There is no bug report and the only way of finding out this is happening is by directly opening the references and seeing stuff like:
/* Minification failed. Returning unminified contents.
(69,1): run-time error CSS1019: Unexpected token, found '@import'
(69,9): run-time error CSS1019: Unexpected token, found '"variables.less"'
(70,1): run-time error CSS1019: Unexpected token, found '@import'
Which (in the above case) reveals that your unnecessary .less or .sass files have been published - which is usually the result of wildcard bundling. Wildcard bundling will cost you more time than it saves.
Parsing views can be slow. Have you tried using RazorGenerator
to compile your views?
Type install-package RazorGenerator
in the NuGet Package Manager Console, or install it via NuGet manually here.
The issue is caused by the parsing and compilation of the Razor views. Once views are compiled, they execute very quickly. Views are only parsed and compiled on the first request for the view, or if the view has been modified since the last compile.
You can resolve this on a deployed WebApp by precompling your views as a part of your Publish process. See the image below on how to do it in VS2012, using the standard publish dialog.
You can select the updatable option if you wish, but for a production site I wouldn't recommend it.