Page Rendering Cheap, but wait there's more

The rage for the past few years has been about measuring client rendering. Marketing managers are demanding to know the cost of the code on the client. Programmers are demanding to know the cost of the code on the client. Heck, even Project Managers are demanding to know the cost of code on the client. Why? The faster the client code the faster the client overall in this era of thick HTTP clients. In eCommerce terms, greater speed = greater conversions = more revenue = someone gets a bonus! All too often these groups are turning to the performance testers to answer the question.

What most of these organizations are unaware of is that the ability to measure the cost on the client has been at their own fingertips for quite a while inside of the developer tools of a browser. What is the advantage of having access to this information as early as possible? The earlier a performance issue can be identified, the less expensive and faster the fix. With performance testing, we seek a high-value return for a normally moderately expensive set of actions in development, execution, and analysis of performance tests. If the information on client-side cost is not available until the very end of a development cycle, whether it is Agile or Waterfall, then the odds of being able to address a structural issue to reduce cost in the client is low before release. The information becomes a statistic with low actionable value. 

The image above is from the performance tab of the Chrome developer tools. For this particular page, it becomes obvious that the majority of the cost is in items other than loading resources from the server. These statistics would have been available to the developer of the web page during page development. This same information would have been available to any resource engaged in functional quality assurance activities.

Rather than waiting to the end of the process, I would encourage every developer and every functional tester to ask performance questions early and often. Whenever you ask a functional question, a security question, a requirements question, be sure to include a performance question. During quality assurance activities (unit, component assembly, end user interface, ...) take advantage of the developer tools and the performance measurement capability.  

If the page is functionally correct but slow for a single user, then use the development tools built into the browser to understand why rather than passing the application downstream for another group to address "performance." Code which does not meet performance requirements on the client side for a single user will never be able to meet the requirements for multiple users. Rendering performance, whether or not this includes local JavaScript and blocking actions, is inherently a single user measurement of one person and one browser. 

Be curious. Open the developer tools on your browser. Ask a performance question.