Web Performance: Measure the Right Thing
By attempting to improve your site's page performance, you can actually make it slower. There are numerous well developed techniques to improve the performance of your web sites and applications. Steve Souders and others have put together some best practices to improve your page performance, and companies like blaze.io have put together turn-key solutions to implement these practices. With these and other ingenious tools that help measure page performance, you'd think implementing a program to improve page performance would be straightforward, but you would be wrong.
Performance improvement is an optimization game, and optimization is the act of maximizing (or minimizing) some measurable quantity. The conventional wisdom for page performance holds that the time from first byte until window's load event is fired (i.e. time-to-onload, or TTO) by the browser is the best quantity to optimize, as it roughly approximates the wait until the page is interactive. While this seems like the worthwhile goal, it isn't; many of the techniques used to optimize TTO have deleterious effects on the user experience, including making perceived performance much slower.
Consider the practice of deferring the loading of various JavaScript files until TTO. This generally has a very positive effect on TTO, but can have potentially negative effects. At a former client, a major airline, developers and management became fixated on TTO (as measured internally and by a third party). The result was that the page would fully render in under a second on average, but some customers would be unable to use the flight search widget properly for twenty seconds or more.
In a somewhat common scenario, the HTML corpus of the page would download, along with the major images assets (hero shot and sprites), and the page would render completely above the fold. The deferred load and execution of the various JavaScript assets would then commence. Unfortunately, the assets that powered the flight search widget would sometimes take an inordinate amount of time to download, resulting in a much diminished, if not jolting, user experience.
The solution is simple; the prescriptive guidance from Souders and others is to put these assets, those that spark the interactivity of critical features of your pages, inline. Specifically, including the JavaScript for the flight search widget in a script tag at the bottom of the HTML payload would have made the widget interactive in a timely manner. By optimizing the wrong quantity, the team made things perceptively worse.
What should have been the optimized quantity? The answer to that question could only come from user-experience thinking. UX is a kind of optimization itself: personas are developed; their goals explored; and the interactions are designed to best help them meet those goals while balancing the personas' agendas against each other. This kind of user-centered exploration of the problem space gives us a tangible quantity to optimize in any given interaction.
In the particular case of an airline's homepage, many agendas begin with searching for a flight; it is clearly the most important interaction. Concordantly, it is the time-to-interactivity of the flight search widget on the homepage that should have been optimized. By prioritizing the interactions on a given screen, we create a ranked list of performance measures that will provide tangible benefits to users of our web sites.
These measures, like time-to-interactivity of the flight search widget, are couched in domain-specific terms. We have to instrument our JavaScript to make them measurable in ways not unlike the DOM onload event. By segmenting traffic and sending instrumentation data back to a beacon, we can monitor and optimize the real experiences of our customers, instead of a browser event.
