For the last couple of years I worked on Geekzone to improve web performance, with great results. The thing that started me on this path was our limited computing resources at the time and a desire to use these resources in the best way possible. From there I found out more and more about Web Performance Optimization and accumulated some tricks that could help some of you out there.
There are so many variables in web performance that in most cases just adding more CPU power or memory won't necessarily speed up the user experience on the other side of the wire. That is because most of of the time spent by a web browser loading a web page is due to factors other than the server's processing capability. Steve Souders says 80% - 90% of the end-user response time is spent on the front end.
Any time a web page takes longer than a couple of seconds to load there is a chance the visitor will simply close the window or navigate away to another web site. In some cases this is reflected in lost sales. The faster your web site, the easier it is for customers to transact with your business.
While web site designers and developers can't control the line speed at the end, they can control what's loaded on the browser when their web pages are rendering. Being smart about it is how we implement web performance optimization.
There are of course things that can be done on the server side as well. Recently I was asked by a friend to find out why his retail web site was performing so badly, and why on peak time his Microsoft SQL server would just grind to a halt, most of the times requiring a few reboots daily. This obviously was something on the server side, not on the client side.
First I found out his server was running on a virtual environment with minimum memory, causing the database server to spend most of the time swapping things between memory and disk. I also looked on his Google Analytics reports and found 80% of the traffic was landing on a single script, which we agreed to concentrate the work on. I found things such as a "SELECT *" query over a table containing a few million records with a long "WHERE" clause and similarly long "ORDER BY" clause - and not a single index defined in the entire database. And this sort of query was used about ten times in that page alone.
Needless to say, working on that script was enough to practically solve the server side of the problem. And solving the server problem also improved revenue, since there were no more lost sales due to server crash, slow response times, etc.
But sometimes things are not that clear and the boundary between server and client performance is fuzzy. In some cases web and database servers are working just fine and a web page still takes a long time to load. That's where Web Performance Optimization projects come in.
I've created a new Web Performance Optimization category in my blog and I will start posting small tips and comments about tools I have used.
Of course if you run a web site and think a Web Performance Optimization project could help you improve metrics, please contact me and we can work on this.
Other related posts:
Google Chrome cache performance
Geekzone experience using Pingdom RUM
Geekzone over the years: the tech behind the scenes
comments powered by Disqus