Easy Web Application Performance Tweaks

Happy Thanksgiving Week! As usual, the year has seemed to fly past. I trust it’s been a good year for you!

Yesterday, I wrote a post about JavaScript Minification using Combres and I spoke about low-hanging performance fruit. Just as you might easily pick the low-hanging apples from a fruit tree, these tweaks for performance are easily done. Sometimes so easily done you might ask, why doesn’t everyone use these tips? When I began explaining them to my team at work, I don’t think anyone had heard of them, except for possibly one of them.

So, here’s a brief overview of some of the easy things you can do to help your web application perform faster and more efficiently.

Expires Headers

Browsers today all have caching ability so why not start to take advantage of it? Expires headers basically tell the client, Hey this resource has not changed so don’t send it. This helps to reduce the number of HTTP (or HTTPS) requests that your user’s browser will have to make. Mads has a good post on how to configure expires headers for IIS7 here.

JavaScript/CSS Minification

Make sure that you are compressing (minifying) all of your JavaScript and CSS. If possible even combine your JavaScript to a single file and your CSS to a single file. This will reduce the number of HTTP requests and reduce file size which will, in turn, reduce network latency, etc. Oh and your mobile users on limited data plans will thank you! You can use tools like Combres or RequestReduce, YUI Compressor, etc.

HTTP Request Compression

Be sure to have your webserver compress the HTTP requests. IIS will do this for you if you turn it on. This helps to reduce response sizes pretty dramatically. If you’re still running IIS (!), here is a resource to help you: TechNet. You’ll have to edit some of the IIS metadata. It’s not as easy as with IIS 7 where you can just add a setting to your web.config file which is really nice for a shared hosting environment! Here’s the TechNet article for that. Do take note that you may need to deal with static content differently than you do dynamic content.


Reduce Page Size

Finally, you may just need to reduce your over all page size. On one of the applications I work on, we have a very large page that is central to the application. I’ve tweaked it many times – and improved it’s performance. But we’ve come to the realization that if we want to go smaller, we’ll need to break up the page into smaller pages. Sometimes you can tweak an issue and correct an architectural problem. But other times, you need to go back to the drawing board.


There are three tools that I can recommend if you’re getting started evaluating your apps performance:

  1. YSlow: Gives you a Firefox/Chome plugins that will test your site and grade it. It will point out the various areas where it thinks you can improve that page’s performance. There’s quite a bit of information on their website so be sure to check it out. YSlow is from the respected Yahoo Web Application performance team.
  2. PageSpeed: Gives you Firefox/Chome plugins that act much like YSlow but with different rulesets. PageSpeed is from Google.
  3. Browser Dev Tools: Firefox, Chome and IE all have Dev tools with network profilers. The profilers will show you how long each request takes and how long until the DOM ready even fires. So, you can monitor the page loads with this tool and dive into the question of which request is taking the longest.

Just remember one thing: software performance problems are not usually fixed in one step. Performance is improved by improving lots of little things and when you’re done, you’ll step back and realize that the application is running faster. So pay attention to those details!



JavaScript & CSS Minification

There’s a thought in the software industry that unless your software performs well it’s useless – even if it has many good features. This is especially true in the web world. I’ve heard it said that unless your page loads in less than 2 seconds, people will go elsewhere.

In web applications one of the low-hanging performance fruits is to make sure that your JavaScript and CSS files are minified and, if possible, combined into a single file each. There are various tools to accomplish this. As you might expect each tool takes a different approach. Some tools will automatically detect, minify and combine the files. Others require that you specify the files you want it to act on.

Recently, I started to use the Combres library (Github) and so far it works well. You can install Combres via Nuget (seriously, if you’re not using Nuget, STOP and go download the extension for Visual Studio!). The Nuget install script handles most of configuration tasks for you like updating your project references and the web.config file.

Once the library is installed, there are only two steps remaining:

First, configure the combres.xml file to reference the script and css files you with Combres to act upon.

Second, you need to add place holders for the Combres output:


I had to add the PlaceHolder controls to eliminate an error message about having “<%” symbols in the <head> section.

And that’s it for a basic setup of Combres. When you run your application, the Combres handler will produce a minified and combined CSS file and a minified and combined JavaScript file.

I liked several things about Combres:

  • It only acts upon the files that I tell it to. If, for some reason, I don’t want it to include a specific file, it’s easy to do – just leave it out of the xml file.
  • I can specify which compressors are used. I can even specify a different compressor for JavaScript than CSS. Check out the combres_full_with_annotation.xml file that the Nuget package installs in your App_Date directory for all the options.
  • If I want Combres to not minify and combine, it’s as easy as setting my debug setting to false in the web.config file (obviously, you don’t want to do that on production!).

I did encounter one hitch in the setup. The project I was adding this too is a Website project – not a Web Application project. So the project is dynamically compiled instead of being compiled into a DLL before deployment. Because of this, I needed to add the following line to my Global.ascx page in the Application_Start method:


If I didn’t add that line, my HTTP requests to the combres.axd handler would return a 404 error.

Combres also does some other things that I haven’t delved too deeply. It adds some caching capabilities such as expires headers. These is another easy performance change you can do but is outside of the scope of this post.

I’ve really liked Combres and recommend that you have it a try!



JavaScript For Loop Performance

A while back I wrote about creating HTML tables for tabular data and then using the jQuery plugin jEditable to allow inline editing of that table. The approach works well over all but there’s two areas where it falls apart – when the table has a large number of rows and when using older browsers (especially IE).

My first take on writing a framework to render the HTML table was in JavaScript. I liked it because everything was in JavaScript except the data access layer. However, when the table has a large number of rows, rendering it in the browser doesn’t work well – especially when your most commonly used browser is IE 8.

While IE 8 is an improvement over IE 6 & 7, it is still pitifully slow in executing JavaScript. I learned this after the fact, when I can a complete framework. It wasn’t too apparent with just one or two grids on the page, but when I had five grids and each at least several rows, IE 8’s slowness became painfully apparent. So, off to do a deep dive into JavaScript performance in IE 8.

My  approach had been to make an AJAX call, retrieve a DataTable that was converted to JSON and then loop through that on the client, gradually building out the HTML table. One of the first performance issues I found was the wide variety of JavaScript loops and their various speeds. It turns out that while IE 8 is very slow over all, there are several JavaScript loops that are really slow.

Here are two different benchmarks for JavaScript For Loops:

Check them out; I’ll wait.

Notice the graphs for IE 6, 7, or 8? They barely even register on the overall graph. If you are interested in specific loop performance, you can run the test and see the operations per second number.

What I found was that in IE 8, for…in loops only where clocking in at around 150 ops/sec. While modern Chrome and Firefox were in the thousands. This was a bit frustrating because the for…in loops made it really easy to work with the JSON that was being return to the client. Foreach loops and jQuery loops were also quite bad.

So my rule of thumb going forward, is to use just a plain, native for loops. At least in the older IE browsers, they represented the fastest possible execution times.




Simple JavaScript Hooks

I recently had cause to inject some business logic into a JavaScript framework. I’m trying to keep the framework as generic as possible so I want to keep from hard-coding the business logic directly into the framework. In a C# context we might simply override the desired method to insert our behavior. You can override a function, in a way, in JavaScript. However, in my opinion, it’s not as clean.

After doing a bit of research, I found the following approach using jQuery. So far it works well. You define your ‘hook’ by simply doing the following:

 $(document).bind('OnSave', function() {
    //Insert code/logic here.

To execute the hook, you simply do this:


The beauty of this approach is that if you don’t bind a hook called ‘OnSave’, nothing happens. You are free to bind a function to the hook or not. It’s your choice.

You can also pass parameters into the hook like this:

 $(document).trigger('OnSave', [description, value]);

Where ‘description’ and ‘value’ are arbitrary variables that you want to pass to the hook. When using these hooks, the bind method call looks like this:

 $(document).bind('OnSave', function (description, value) {
     //Insert code/logic here.

That’s it! You can find the jQuery documentation for here and here.

Happy Coding!



JavaScript Data Grids

I recently had cause to build an editable grid out of HTML and JavaScript and settled on two jQuery plugins: DataTables and jEditable. I’ve really been impressed with both!

The DataTables plugin takes a basic HTML table and adds column sorting, filtering, pagination and much more. To create the default grid all it takes is the following:


The jEditable plugin allows the grid contents to be edited inline. So all you have to do is click on a value and a textbox or select list appears. Like DataTables, jEditable is quite flexible. Basic initialization is as easy as:


What I love about the jEditable plugin is that if you want a select list to appear when the cell is in edit mode, all you have to do is this:

  $('.editable').editable('http://URL_To_Page_To_Handle_Database_Action', {
    type: 'select',
    data: {’Ford’:‘Ford Motor Company’,‘Honda’:‘Honda North America’,‘selected’:'Toyota'} 

This configuration will cause the field to be a select list in edit mode and populated with the car company information in the data array. If you need the select list to be dynamically populated, you can provide jEditable with an array of values.

Since you initialize jEditable using a jQuery CSS selector, you can choose which columns become editable or even which columns are textboxes and which are select lists while in edit mode. Just apply unique CSS classes to the correct column.

If you use ASP.NET, you can create a method on page and decorate it with the [Web_Method] attribute. Then you can use the jQuery AJAX method to send data changes to an update method to be written to the database. If you want to have your select list be dyanmic (as mentioned above) you can also use the jQuery AJAX method to retrieve your option list.

If you didn’t need the pagination, sorting, filtering or other features provided by the DataTables plugin, you can just use the jEditable plugin on the HTML table.

I used these two plugins to replace ASP.NET grid views. The page had grown over time to be quite complex with a number of grid view controls on the page. The grids had become slow and the View State was very large. These plugins allowed us to give the end user an editable grid but with great performance and much less overhead.