Web performance benchmarks or the rule of Fast Enough

I recently saw a blog post that listed out performance benchmarks of two presentation layer technologies for Java.  The posting probably wasn't as non-biased as it could have been, but that's besides the point, and not the issue of this post.  The performance stats were measured in milliseconds from the time a request hit the server to the time it left the server to go back to the user.  A stat worth keeping an eye on, right?  We want our applications to be fast, of course we need to be focused on how long that request sits on the server processing, don't we?

As developers most of us want to squeeze out the last bit of speed we can get from our applications and technologies.  We want ours to be the fastest, naturally; and most developers have a tendency to be perfectionists to some degree or another.  But is it really necessary?

Back to the post I read.  As I stated the results were measured in milliseconds.  Most of recorded data (even in  multi-user scenarios, the author did up to 25 concurrent users) points for both technologies were sub second.  That's less than one second for a request sitting on the server processing, sounds pretty darn good to me.  The author's conclusion (assuming I read it correctly) was essentially technology X should be used instead of technology A because it's faster.  Now to the heart of this post: do your users really care about that much of a speed difference??

When we're dealing with web applications we have to remember that the users are not running this application on their local machines.  Each request has to go over through the Interet, which is definitely slower than seeing something on our local development machines, or even on a local network.  We also have to keep in mind the user's perception of "slow."  That's really what this boils down to.  If our users feel the application is sluggish then we should probably look into it.  Users of the web don't expect requests to come back instantaneously.  Most users are happy with a 5 - 10 second return of their request.  If a couple seconds of that is spent processing the request on the server, you're probably good.  There are also other considerations on the client's side for perceived web performance, namely the browser being used.  How fast does it render HTML, does it wait to display the full page or does it load incrementally, etc ?

Basically there are a lot of variables that make up the perception of a slow web site.  Your best source of knowing if something is slow is your user base, and I'm not just talking about one or two but a sizable chunk of users.  If they're saying it's slow, go look into it.  If you don't hear any rumblings, don't worry about it.  Your site is "fast enough."  Also remember web front end technologies that are mainstream are all "fast enough" otherwise no one would use them.