Web monitoring pros have to take into account a lot of factors when it comes to improving web site performance, and in an interview with Steve Souders, the Velocity Conference co-chair last June on on the O’Reilly Radar blog, he suggested that many of you could be looking at the wrong part of the problem.
Souders suggested that many people are looking at the back end and trying to tune the code and database queries to get the maximum performance out of it, but he says, this is a trap that many web architects fall into. He said it actually has very little impact:
“We discovered that about 10% or 20% of the overall page load time was spent on the back end. So if you cut that in half, you only improve things 5%, maybe 10%. In many cases, you can reduce the back end time to zero and most users won’t notice.”
What should you be doing then if expending energy on the code seems to be a waste of your time and resources? He says it’s actually better to pay attention to the front end and watch for things like how you manage resources and how the browser plays into displaying your website. That’s really the place where you going to get the most bang for your website tuning buck.
And that’s worth keeping in mind if you are experiencing web site performance issues. There is a tendency inside any organization to try to assign blame when things start to break down (if you doubt this, look no further than this year’s Boston Red Sox). It must be the programmer’s fault. It must be bad code. But this shows even if that is the problem, it’s not really going to give you any major lift by fixing it and that’s certainly worth knowing before you start down that path.
But it’s not just the idea of blaming the wrong people, it’s that you’ll simply be wasting your time and effort on something that as Souders points out most people simply won’t notice in terms of impact.
You can read the whole interview to get the gist of what he’s saying, but he adds that just in individual browser performance there is a wide variation and it’s hard for any developer to take every contingency into account and tune the web site the to perform in an optimal way in every situation. There are just way too many variables involved for that.
So the next time, you run into a web site performance issue, keep all of this in mind. There are a dizzying variety of factors that can have an impact on load time from the browser to the code density to the individual hardware the on the end user’s machine/device.
It probably won’t get you off the hook if your site is performing badly, but at least it can help you point your resources in the right direction to solve the issue.