There are a lot of articles explaining the basics in performance optimization in ASP.NET. Here is one and here is another. It is important to know the basics and use them where appropriate. The basics include caching, viewstate optimization etc. But what do you do to optimize further, when you have implemented all the basic techniques? You search the Internet to find an article about it, just like this one. The conclusion of this article is: Make the response from the server to the client as small as possible. You already have made the server-side code run fast with the basic techniques, so now you need to shrink the output. Here are a few examples that will take you a long way.

1. Remove whitespace in the HTML
This is very simple to do in ASP.NET. Here is the method to use.
It can easily reduce your html code by 15%.

2. Remove whitespace and comments in CSS and JavaScript files.
This is also very simple. Read this post on how that is done easily.
CSS code can be reduces by 30% and JavaScript about 15%-20%.

3. Put all styling in a stylesheet file
If you do a lot of styling in your html, the file size increases. Every time a page loads the styling is also returned from the server. But if you put all your style in a stylesheet, it will get cached by the browser and thereby only return from the server once. This can be a great improvement if you have a lot on in-code styling.

4. Put all JavaScript in .js files
This uses the same principle as my point about putting all style in stylesheets. Browsers caches .js files just like CSS files so it’s only returned from the server once. Again, the impact of this trick is dependant on the amount of JavaScript you use in your html page.

If you apply all four techniques, my guess is that you have reduced the response to a minimum. If you pay for the bandwith used by the website, this could save you a lot of money by reducing the filesize.

A couple of colleagues and I talked about how unpleasant surprises could be avoided if you use the time needed to research the task before actually starting to work on it. It turned out, we all did it in our own distinct way, but the end results were the same. I, for instance, use scenarios as my primary tool for scoping a task. Some uses a more theoretic approach and some googles for the answer first and asks the questions later. These are all valid approaches in my opinion.

The tricky part of all this is, that it is very hard to measure the effectiveness of each approach. After all, it is the finished task that is the goal and not the process it self. Some would disagree, but that is another argument. I think my approach is the best, of course, because it asks the questions before looking for answers. The questions help define the details surrounding the task, details that are both critical and non-critical to success. The answers can then be found in books or the web if you do not know them yourself.

By finding-the-answers-first approach, you would typically search the web for similar tasks and read about how other people have solved them. This is also very efficient, but it does not let you define the details of your own task before you get the answer. You could end up half way through the task, realizing you had taken a wrong turn because you didn’t see a small but important detail somewhere down the road. If however, you are convinced that the answer suit your needs, one could argue it would be a waste of time asking all the questions, and thereby making this your favorite approach.

It is of course not so black and white. Different approaches suits different tasks and it would be wisely to choose the right approach before starting the task. However, some tend to lean more on one specific approach more often than others do. In fact, this was exactly what we found when discussing this at work. We all had our favorite.