将一个MVC项目从12.2升级到14.2，VS2012升到2013，发现使用IE11调试非常慢卡死，CPU占用100%，后来经过排除，发现只有DevExpress的MVC项目有这个问题。
最后在DevExpress的支持页面找到答案，原来是VS2013的Browser Link功能造成的。
-
If you use Visual Studio 2013 for web development, you could face some issues:
1) A Web application is being loaded for a very long time/client scripts are being loaded long when you debug it on the development server;
2) CPU usage by the local IIS worker process increases enormously while debugging the application;
3) Pages that use the jQuery library return JavaScript errors;
4) HTML markup contains garbage tags.
In Microsoft Visual Studio 2013, the Browser Link feature was introduced. It provides dynamic exchange between IDE and any open browser on your machine. With the help of this feature, you can test changes in page markup in browsers on the fly, inspect HTML objects, etc. However, the use of this feature might cause abovementioned problems in the debugging process.
A common solution is to disable Browser Link in Visual Studio:
via menu (uncheck the "Enable Browser Link" check box)
via menu (uncheck the "Enable Browser Link" check box)
解决办法是在主界面菜单中禁用这个功能，就在绿色运行尖头按钮旁边的Browser Link下拉菜单中。
或者修改web.config文件，添加下面的内容：
<appSettings><add key="vs:EnableBrowserLink" value="false"/></appSettings>
此问题的详细分析：
Case 1 and 2: The cause of the problem is that the Browser Link feature requires dynamic compression to be disabled. The dynamicCompressionBeforeCache attribute allows IIS to dynamically compress the response when a request is made for the first time and queues the content for compression. When this attribute is enabled, a page loads faster, whereas if it is disabled, it causes additional CPU consumption and increases the page load time - see the remarks section of the MSDN : urlCompression article.
In these cases, the only solution is to disable the Browser Link feature as described above.
Case 3:
Browser Link's Scripts Manager adds a jQuery reference to the <body> tag. JavaScript is an interpreter language and processes code line-by-line, so the place where the scripts are referenced or declared is really important. If a custom script that uses the jQuery library is declared before the body (commonly, scripts are added in the head), it will not work correctly.
If you want the Browser Link option to be enabled, you can move jQuery-dependable scripts to the <body> tag.
Case 4:
This issue is usually caused by a page compression conflict. If URL compression has the enabled dynamicCompressionBeforeCache that is set by default for IIS 7.5, it interferes with HttpModules that are used by Browser Link, and produces problems in output.
If you want the Browser Link option to be enabled, disable the dynamicCompressionBeforeCache (web.config -> system.webServer):
In these cases, the only solution is to disable the Browser Link feature as described above.
Case 3:
Browser Link's Scripts Manager adds a jQuery reference to the <body> tag. JavaScript is an interpreter language and processes code line-by-line, so the place where the scripts are referenced or declared is really important. If a custom script that uses the jQuery library is declared before the body (commonly, scripts are added in the head), it will not work correctly.
If you want the Browser Link option to be enabled, you can move jQuery-dependable scripts to the <body> tag.
Case 4:
This issue is usually caused by a page compression conflict. If URL compression has the enabled dynamicCompressionBeforeCache that is set by default for IIS 7.5, it interferes with HttpModules that are used by Browser Link, and produces problems in output.
If you want the Browser Link option to be enabled, disable the dynamicCompressionBeforeCache (web.config -> system.webServer):
<urlCompression doDynamicCompression="true"doStaticCompression="true"dynamicCompressionBeforeCache="false" />