Pretty much everyone who uses jQuery agrees it’s best to reference the libraries from a CDN, such as those provided by Google or Microsoft (even our Wijmo libraries can be referenced from the Wijmo CDN, provided by Media Temple). This is great for the core libraries, plug-ins and themes, but won’t work for your custom CSS and JavaScript libraries—those need to be served up locally (or from your own CDN).

Serving external files locally can cause pages to load slower (since many files must be requested, and the files are not cached) as well as consume bandwidth. Since CSS, JS, HTML and the output of an ASPX page are all just text files, one way to increase transfer speed is to compress the files before transmitting them, just like we usually ZIP an email attachment before sending it. For quite some time now, all browsers have included the capability to decompress files before rendering them, and there are two supported algorithms for doing so.

My preferred solution for compressing files before transmitting them is to implement HTTP Compression on IIS. This is a “set it and forget it” type of thing—configured once on the server, we don’t need to maintain any dependencies or libraries in our code base, etc. It’s just easier. IIS has modules built in (, and there are third party choices as well (such as

One of the main advantages to using IIS compression is that it works for pretty much everything—classic ASP, all flavors of ASP.NET (WebForms, MVC and Web Pages), CSS and JS files, etc. Images don’t see too much benefit since PNG and JPG are both compressed formats (use sprites if you need better performance with images). In WebForms with large ViewStates, the IIS compression can greatly speed up the transmission of those pages.

Since this is configuration which must be done in IIS itself, you’ll probably need to check with your network guys or host provider to confirm this is in place, or have it implemented.