A few months back, I had an article published in Sapient Testing; Smart Stuff for Career Software Testers, the newsletter for the Association for Software Testing, titled "Right Click -> View Source and other Tips for Performance Testing the Front End." In the article I present a series of tools and techniques for testing the front-end performance of websites based on the book High Performance Web Sites: Essential Knowledge for Frontend Engineers -– 14 Steps to Faster-Loading Web Sites by Steve Souders (O'Reilly, 2007).
While writing that article, I realized just how infrequently performance testers discuss front-end performance, how infrequently that we do it deliberately, and how frequently the most severe performance issues are tracked back to front-end design and implementation. This surprises me, especially considering the following:
Put those things together and what you get is no one paying attention to, or checking for, potential performance improvements in the part of the web page most likely to contain the most opportunities for the largest and cheapest performance improvements.
Most surprising of all is that testing for the majority of the worst and most common front-end performance issues is, relative to back-end performance testing, exceptionally easy. In fact, since I wrote the article, I've come up with an easy-to-remember (for me, anyway) heuristic that, when coupled with some of the (free) tools mentioned in the article, allows me to conduct a reasonably comprehensive set of front-end performance tests in just 15 minutes, though I admit that in 15 minutes I can generally test only a couple of pages.
The heuristic is "For a well performing website, performance test the front end with SCORN." Where SCORN stands for the following:
Let's take a brief look at each guideword.
Size: When it comes to website performance, smaller is better. Whether it's a graphic, a s
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
cript or the base HTML page, it has to get from the server to client at least once, and that trip is bound to take less time when there is less information to transmit. Specifically look for uncompressed graphics and media, object or code duplication, script and styles living outside of the base HTML, and code "minification."
Caching: Any page or object that users will view more than once is worth at least considering caching on the client side. The trick is balancing the relative speed of pages and objects being displayed from cache with the fact that objects displayed from cache may not be the most recent version. Check for Expires settings, ETags and other client-side cache controls to see if they strike a sensible balance between object load time and object freshness.
Order: Possibly the most dramatic user-perceived performance gain can be achieved by requesting component objects in the correct sequence. In most cases, the sequence of objects should be as follows:
Response codes: Checking response codes for each object can help identify requests for objects that don't actually exist, superfluous redirects and errors that aren't apparent from the browser. Each of those can cost more time than getting the object without error/redirect or eliminating the unused request entirely.
Number: For the most part, fewer is better. But depending on a user's connection speed, several smaller graphics may be faster than one large one. In the vast majority of cases, one external style sheet and one external script file will be fastest. It's worth asking questions if the number of objects impresses you as other than "fewer".
If you're not sure how to test for the items above, refer to the article in the December 2007 issue of Sapient Testing.
----------------------------------------
About the author: Scott Barber is the chief technologist of PerfTestPlus, vice president of operations and executive director of the Association for Software Testing and co-founder of the Workshop on Performance and Reliability.
