https://stackoverflow.com/questions/16527944
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPros and Cons, Traps are similar for other script bundling solutions-- you will want to minimize first, pay attention to order of scripts, start your scripts with a ; to close off any unclosed scripts in another file.
One ASP.NET specific issue is the debug/development experience. If you combine your scripts, it is much more difficult to find your code in the IE debugger, the script will have a machine generated name that looks similar to other framework generated scripts & your code will be buried in a much larger file.
So I register my references in code behind and wrap them in ifdef DEBUG/endif and ifdef RELEASE/endif (be sure to define a RELEASE in the project properties, it doesn't happen by default if you use this trick). In the RELEASE version, I bundle all the scripts and the DEBUG version leave the files separate.
Also per Microsoft's recommendation, script bundling works best for files that you need throughout the website. If you have a multipage site with A, B, C and your users normally visit only one of them, then bundling the files for A,B,C will give the user 2 extra files. I think this is a bad micro-optimization because most apps have small javascript files & large libraries, so a website's worth of JS bundled is not enough bytes to worry about, unless you have a lot of traffic.
Finally, the server side ScriptManager doesn't offer any way to defer scripts or dynamically trigger a load from the client side (other than load scripts after UI), I use LAB.js to dynamically load scripts later... this sometimes can allow you to defer a script until you know you need it and possibly defer loading that script forever. Once you bundle that script, it will be loaded for each user if they turn out to need it or not..
Part 2 Another gotcha, at least for me, is that while you can enable caching of JS files in web.config (no time to look up syntax at the moment!) and you can also enable caching at the IIS level using the expires header, the ScriptManager does nothing to help you "bust" the cache when a new version comes out. Ideally, a script management tool would let trick the browser into thinking the script is in a folder that changes as the last update changes, so that scripts could be client side cached for a year.
I wish I had info on if the scripts are server side cached-- I would guess they are not. But because the user gets the script usually once per day at most -- on my server they seem to cache for 24 hours, it isn't too interesting if the scripts are regenerated on each request.
And finally, if you are using a CDN for things like jquery, (depends on if you are public or intranet) it is the 4.0 and 4.5 version that makes it easier to tell the ScriptManager to use a CDN and fallback when the CDN is down.
