As a web developer, I can attest to the following scenario being not too uncommon: A new client comes to me complaining that their existing web site is too slow. Of course, many factors can influence a site’s pageload time. Often, it’s not just a single one of these, but rather a combination of various issues. (It the problem were easy, they probably would not have had to contact me.)

Broadly speaking, though, one could say that two main areas frequently come into play: (1) the software, and (2) the server(s). Within those two areas (again, very broadly speaking), a number of possibilities exist in terms of combinations. Let’s consider a chart of the most common combinations:

(Please note:

The Zone 1 Situation: The Web Site is SLOW!

Zone 1, above, is where new clients often first seek out developers or consultants, which makes a lot of sense, when you think about it, as it likely represents the normal growth of a smaller enterprise or web site. What happens is that: (a) on the software front, the site implemented some out-of-the-box solution that worked well for a small site. This also (b) worked out acceptably on a shared-host type situation because the site started out small and really didn’t require the resources of an expensive hosting solution.

Two examples of this: First, consider a content managment system with a lot of usual bells and whistles (posts, tags, categories, etc.). Most of these systems are written with user audiences in mind ranging from individuals to small- and medium-sized businesses that will, in all likelihood, have a total number of pages (posts, articles, blog entries, whatever) in the few hundreds, with a considerably smaller percentage having a few thousand, and so on. Once you get to installs with tens of thousands of pages (and well beyond), the number of users for that CMS dwindles significantly. They’re still there, of course, but quite often they graduate to Zone 2, which we’ll get to in a minute.

Next, consider an ecommerce-type scenario, where the same sort of thing happens. A company starts out with a few dozen, or maybe even a few hundred, products but then expands it into the thousands (or more!). Things then slow down a good bit.

In each of the above scenarios, developers often find scalability issues related to database queries. When a site is small and the number if items being considered by the database is relatively low, the ways in which a database is queried can be much more complex (and/or sloppy) and still return the desired results in a way that is considered acceptable to the end user, even if at some point the server may be straining a bit. But, as the numbers increase, certain types of queries can become exponentially more resource-intensive on a server, and thus will slow down the site.

The way out of Zone 1 is often a move to Zone 2, although moving straight to Zone 4 is probably a better long-term move. So, let’s look at Zone 2.

The Zone 2 Situation: Add Horsepower

Companies in this category started out running well, but then expanded their online presence and things started slowing down. The easiest solution is usually to throw more server horsepower at the problem. Fortunately, today that’s becoming somewhat more accessible than it was in the recent past. But, still a lot of companies will move to a platform where the server admin becomes an issue as well, which often means adding a server administrator to the team, even if just as an on-call consultant for periodic server updates, patches, etc. That, in turn, often adds time to ongoing projects, as more people need to be rounded into various efforts.

Better servers can solve performance issues, for sure. But, I often see it as a weaker solution. It’s like your web site is a heavy cart, and the server is there to pull it forward. When the old horse falters, you call in a stronger team of horses and keep going.

All is well and good in that scenario, but hopefully you can see that there is another option, which is lightening the load instead of adding horsepower. So, let’s look at Zone 3!

The Zone 3 Situation: Too Many Horses?

Zone 3 is when you start thinking about truly optimizing a site. A few projects actually start out here, especially when there was a decent budget to begin with. But, one way or another, Zone 3 reflects not only wanting a high-end server, but also wanting clean, optimized code.

Above in Zone 1, I identified two specific scanarios (the CMS, and add-on software) that often lead to slow performance, usually after some threshhold is reached that winds up slowing down the site, often due to slow database queries.

So, assuming we began in Zone 2, where you already have a new super-server in place, the next item to focus on is the code — specifically, either fixing the molasses queries that are slowing down your site or maybe even re-writing custom systems that include only the queries you absolutely need (thus avoiding the bottlenecks).

It’s amazing how often these slow queries muck up the works of otherwise decent software. I see it a lot in solutions that are meant to cater to a very wide range of user needs, but where the slow site in question does not need most of the functionality offered by the software. So, you’re in a situation where the queries are needlessly complex and slow down a site when you try to scale upward exponentially. (Also, you’re then maintaining a code base that is largely unneeded, yet one that also might cause issues on your site even if an update to an unneeded function contains an error.)

Also amazing is how truly scalable database applications become once they’re either optimized or custom coded. Instead of 10,000 relational database records being completely unworkable, you now can 100,000 relational database records barely strain any server resources. I’ve seen this many times!

The Zone 4 Secnario: Easy Living

In keeping with the animal metaphors herein, I picked a fox for this one because (IMHO) this represents possibly the most clever take. Here you’re running a normal business site (often an Intranet) where the hosting requirements are fairly low, cheap, and easily maintainable (e.g., no server admin needed, managed servers, nothing your normal cPanel can’t handle, etc.), and yet you’re working with fairly massive loads of data. The only difference is that, because your code is fully optmized, and/or custom to your needs, there’s no need for that workhorse server anymore (or the server admin and extra time he/she needs), unless of course you absolutely need to get into advanced pagespeed optimizations. But, for many normal sites, it can be a real sweet spot. For custom-scripted solutions, you’re also, at this point, usully saving a good bit of money and/or frustration for updates on these other less-optimized systems.

In Fairness, Though…

It should be noted, of course, that a custom-scripted (and/or fully optimized) solution can represent a decent investment at the outset. One way or another, there’s usually a cost involved. But as a web developer, I’d really love to see more clients start at Zone 4. Failing that, if they’re in Zone 1, I’d like to see a move to Zone 4 next — and only then to Zone 3, if desired. I guess you could say I’m simply not a fan of Zone 2, as I don’t see it as a sustainable solution.

That’s all my opinion, of course. Your mileage may vary.