Last week I attended Oreilly’s Velocity Conference in San Jose, the only conference solely dedicated to the subject of website performance and testing. It was sold out for the first time; many of the presentations were standing room only and I was unable to get a room at the hotel.
One distinction that I was disappointed that was overlooked is the difference between static and dynamic web performance. All of the performance issues in the presentations I heard were all related to static web page performance, which is how long a web page takes to load when there’s only a single user accessing the website. While individual static page performance is important, by not thinking about what happens when hundreds of people start accessing that page at the same time, the actual performance when the system is being used is dramatically effected. It does no good to optimize a single page load to be under two seconds if the load times dramatically increase when only a few users hit the page at the same time.
There were many tools being presented at the conference like YSlow and Google Page Speed, which show waterfall plots of what happens in parallel when a web page loads. When implementing the suggested changes, however, one must be aware of the implications of those changes on the back end. For example, turning on compression reduces bandwidth, but can cause massive CPU spikes on the back when depending on the size and dynamic behavior of the resource. Our own research report on HTTP compression is a must read when developing a compression plan for your own website.
The other issue is that back-end performance for dynamic sites is very dependent on the patterns of when back-end calls arrive at the server, which is difficult to predict from looking at a single page. Its very informative to run even small load tests and look at the back-end behavior for patterns before deciding on a front-end design. Its entirely possible that a web page design which optimizes static web page load times could slow down that page when under load. You simply don’t know until the load testing stage.
The bottom line is that when using a static page performance analysis tool you must test the performance of that page under the expected load before and after the changes you make to be sure that the changes you’re making are actually improving performance under the same conditions as when deployed.
Michael Czeiszperger
Founder, Web Performance, Inc.
Founder of Web Performance, Inc
B.S. Electrical & Computer Engineering
The Ohio State University
LinkedIn Profile