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!



C# String Performance

In my last post, I talked a bit about JavaScript performance specifically around For loops. Today’s topic is also performance related but specifically around building strings in C# in loops.

I think every programmer has had occasion to build quite large strings at runtime. Typically, however, string operations can cost you a lot in performance. I had run into this issue recently. I had started out building a large string with just simple concatenation like so:

string MyString = string.Empty;

for (int i = 0; i < 1000; i++)
    MyString += " This is an addition to MyString " + (i + 500).ToString() + " Some more addition to MyString";

We’ve all seen and used an approach similar to this. It’s easy to read and understand (generally). However, this little sample is really inefficient. It took 237 milliseconds on my machine. Hmm, maybe not so good.

Let’s try another way:

StringBuilder MyStringBuilder = new StringBuilder();

for (int i = 0; i < 1000; i++)
    MyStringBuilder.Append(" This is an addition to MyString " + (i + 500).ToString() + " Some more addition to MyString");

This approach only took 1.9 milliseconds! That’s a huge difference if you’re trying to shave your page load time down.

So what if we increase the upper bounds to say 10,000?

String Concatenation: 24,371 Milliseconds (24 Seconds)
String Builder: 29 Milliseconds (0.029 Seconds)

Now that’s a huge difference! You’d better believe that would make a difference in response time!

The big reason for the difference is that the string is being build in a loop. If you had a one-off string to build, you may not see that big of a difference. But if you using a loop, you’ll be much better off using String Builder!



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.