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:
- All the research I could find validates my experience that 50-90% of a web page's response time results from front-end design and implementation.
- Virtually all of the tools, training, articles and conference talks available to individuals who test the performance of software systems focus heavily on the back end. So much so, in fact, that most dismiss the front-end aspects of system performance as something not worth worrying about, ostensibly because we can't control the end user's system. (Yes, I was guilty of overlooking the front end in my articles, training courses and conference talks until I made a concerted effort to update my materials after reading Souders' book.)
- In my experience, the front-end design and development of websites is conducted with little to no thought to performance, outside of possibly reducing the size of the graphics. Additionally, I've never been made aware of a team conducting a peer review on the HTML that generates the web page on the client side, never been made aware of unit tests on such code, nor witnessed a tester deliberately and proactively test the HTML for possible performance issues.
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:
ize
Caching
Order
Response codes
Number
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 script 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:
- Styles/style sheets
- Critical content (i.e. what the user came to the page to see)
- Relevant media (i.e. graphics related to the critical content)
- Incidental content (i.e. non-critical graphics, possibly advertisements)
- Scripts
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.
