ASP.NET Tips #24 - Before tackling any website performance issue, first verify the problem isn’t on the client

Traditionally, many performance problems have been rooted in either the database or application server. However, with the proliferation of advanced JavaScript frameworks such as Backbone.js or jQuery, performance problems are increasingly starting to appear on the client.

Rather than immediately attempting to diagnose a performance problem on the server, first use a free browser-based tool such as Google Chrome Developer Tools to ensure that the problem isn't actually occurring on the client.

You may just save yourself a lot of time tracking down performance problems on the wrong end of your site.

Don’t underestimate the value of the UI when tackling performance problems

Simple UI tricks, such as progress bars, redirecting users' attention using animation, or placing slower loading sections at the bottom of a page or offscreen, can often 'fix' a performance problem without the need to tune the underlying code.

These UI tricks are an important tool to have in your performance tuning toolbox and can be much quicker and easier than addressing the underlying issue. They can act as a holdover until you have the time to devote to the core problem.

Throw hardware at the problem, not developers

As developers, we often want to fix problems with code, but don't be afraid to 'put the compiler down' and throw some hardware at the problem. Performance problems caused by disk I/O bottlenecks or paging out of RAM can often be solved by a faster hard drive or more RAM.

CPU bound bottlenecks can often be solved by a new machine with a faster processor. As counterintuitive as it sounds, addressing problems by buying a new machine or upgrading an aging one is often much cheaper than having a developer troubleshoot, diagnose, and correct a deep performance problem.

And the rest of your website will get a performance kick to boot!

Don't assume that problems can only arise from business logic

When beginning to diagnose performance problems, we often assume the problem is in our business logic. Don't forget that the areas of our code that provide infrastructure can cause problems as well.

Areas such as HttpHandlers, HtmlHelpers, mapping, logging, or IoC frameworks are increasingly at the root of performance problems. While business logic still causes its share of problems, infrastructure code is quickly gaining in the performance problem race.