A long time ago, when dinosaurs were still operational, we tried to improve performance of our HTML / CGI pages by various ways, but also having different goals for such improvements.
In the dawn of web, when U.S. Robotics 14.4kbps modem was a de-facto standard and traffic compression wasn’t widely implemented by ISP call centers, our biggest concern was the size of our files. I wouldn’t say “output”, as it was mainly static, but even when it was dynamic, like the output from CGI modules written in Visual Basic 4 or 5, it was paramount that users would not wait more than 2 seconds to get the HTML part of it.
Now even mobile phones are having unlimited data plans, home connections reach 100 Mbit/s heights and in order to decrease the size of the output we just have to tick a checkbox in IIS, so the output – be it static or dynamic, is compressed. So the era of “HTML optimizers” – tools that remove extra spaces and “unneeded” tags from your markup, is over.
Another thing that helped us to avoid traffic jams, was Ajax. It killed 2 rabbits with a single shot – decreased the traffic flow by only up/down loading the data our application needs at this time, and thus increased the response time. But this came at a cost.
Each small callback made by Ajax is no different than ordinary callback, except that it transfer smaller amount of data. But it’s a connection nevertheless. Even if keep-alive is used by browser, it still consumes a connection from server and still there are protocol issues involved.
Imagine, that you are shopping at the mall. And you are asking salesman to wrap something for you. One thing, then another, and then also one. The benefits of Ajax and compression are such, that instead of ordering big things, say, plasma TVs, you are requesting smaller ones, like soda cans. So, instead of 10 TVs, salesman is wrapping 10 soda cans into a fancy gift wrap and writing on them that, indeed, it’s a soda can.
You see where the problem is? You are asking for each individual thing you request from server, by sending individual requests and then parsing responses and then parsing the received files. The overhead is significant even if the output is compressed or cached on server.
The threat (to performance) was recognized a while ago, and some optimization guides even suggested to merge external JavaScript script files into one and do the same to cascading style sheets (CSS) files. That worked, but it was a hell for developers, as files needed to be maintained separately by different authors, and merging them all into one file wasn’t handy.
So, just like previously with compression and caching, Microsoft solved this problem without attempting to change your coding behavior or standards. Now, all you have to do is to keep your CSS or JavaScript files together, according to the purpose, and instead of multiple
<link href=”styles/mystyle.css” rel=”Stylesheet” />
you can type this:
<link href=”styles/css” rel=”Stylesheet” />
and it will take all .css files from the styles directory, create one virtual style sheet and send it to the client in one response. Depending from the amount of css files, this may decrease the loading time of your web page for up to 20%.
The same goes with JavaScript files, and that’s probably even more significant, as we’re usually using .js files for all custom controls and Ajax, so there are usually more JavaScript files than cascaded style sheets in ASP.NET web application.
This feature of ASP.NET 4.5 is called Bundling, and it works with Visual Studio 2010 designer after you install .NET 4.5 support. At the moment of this post, the .NET 4.5 is in “developer preview” phase, and is available to download from Microsoft’s download web site.
And if you are old school and trying to remove the extra spaces and comments from your ASP.NET, CSS or JavaScript code, before it goes to production, you can quit this practice now as it also became part of ASP.NET under the name of “Minification”. It comes together with bundling.
Just like everything else in ASP.NET, you can transform and change everything on the fly, making known beast do magic tricks.
In case of Bundling, you can change the order in which files are loaded. By default, it is smart enough to put jQuery on top of your own files, but you can change that. Moreover, you can compile your own bundle out of different folders and files, and each such bundle will be accessible by it’s own custom URL, like “~/MainPageScripts”.
Finally, you can create your own extension for Bundling feature, enabling it for file types not known to Visual Studio / .NET. CoffeeScript, for example.
Interesting thing about the new features of ASP.NET is that when they are introduced, it causes a massive recoil from those using 3rd party libraries to achieve the same functionality. The reason is simply psychological – “I spent so much time on learning and implementing this stuff, my projects depend from it, and now you’ve ruined it all!”. Obviously, some projects will have to die, just like URLRewrite did when such functionality was introduced natively in .NET. But that’s the nature – Add-Ons and mods live while their features are not introduced in the product they are extending.