- Timeouts – Have you ever noticed that you can spend an indefinite amount of time fooling around in the debugger without a halted request timing out? That’s because debug=”true” disables timeouts entirely, which is never a good idea on a live site.
- Bundling and Minification – ASP.NET’s new web optimization feature can automatically bundle and minify your JavaScript and CSS, but it only does so in release mode. When you run with debug=”true”, bundles are served as separate, unminified, uncombined script references with short caching headers. That’s important during development so you can read/debug your JavaScript code, but it defeats the entire point of the optimization exercise in production.
- WebResource.axd caching – Speaking of client-side resource optimization, resources served through WebResource.axd include aggressive caching headers in release mode. In debug mode, they are not cached at all.
A harsh reminder about the importance of debug=”false”
http://encosia.com/a-harsh-reminder-about-the-importance-of-debug-false/
Don’t run production ASP.NET Applications with debug=”true” enabled
1) The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)
2) Code can execute slower (since some additional debug paths are enabled)
3) Much more memory is used within the application at runtime
4) Scripts and images downloaded from the WebResources.axd handler are not cached
