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.
<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%.
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.
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.