Introduction

Most of the material in the following pages first appeared in my end-user monitoring blog. However, this book (hopefully) collates it into a coherent body of information that is of value to new entrants wishing to understand the performance of their web properties, particularly as experienced by visitors to their website(s). I also hope to help readers understand some approaches to detailed analysis of the frontend performance; that is, the components of delivery associated with user devices rather than backend delivery infrastructure.

Historically, client-side performance has been a relatively straightforward matter. The principles were known (or at least available, thanks to Steve Souders and others) and the parameters surrounding delivery, though generally limited in modern terms (IE5 /Netscape, dialup connectivity anyone?), were at least reasonably predictable. This doesn’t mean that enough people addressed client-side performance (then—or now, for that matter), despite the estimated 80% of delivery time spent on the user machine in those days and almost certainly more today. There is an undoubted association between performance and outcomes, although some of the specifics have elements of urban myth about them. For example, the oft-quoted relationship of 0.1-second deterioration of PC page response with 1% revenue might hold true—if you are Amazon.com.

From a monitoring and analysis point of view, synthetic external testing did the job. Much has been written (not least by myself) on the need to apply best practice and to select your tooling appropriately. The advent of real-user monitoring came some 10 years ago—a move that was at first decried, then rapidly embraced by most of the “standalone” external test vendors. The undoubted advantages of real-user monitoring (RUM) in terms of breadth of coverage and granular visibility to multiple user end points—geography, O/S, device, browser—tended for a time to mask the different yet complementary strengths of consistent, repeated performance monitoring at page or individual (e.g., third-party) object level offered by synthetic testing.

Who This Book Is for

In writing this short book, I envisaged several potential audiences. If you are an experienced technical performance practitioner, this is not the book for you. However—although perhaps not common knowledge—many aspects of performance enhancement are straightforward, and there are a number of use cases where an informed approach to possibilities and processes in this area may promote good practice and enable effective management and business growth.

In short, therefore, this book should be of most use to interested and currently uninformed users in the following categories:

• Senior managers wishing to understand the competitive advantages of high-performance web-based applications, and better challenge existing processes and assumptions in their organizations

• Marketers (or others) responsible for delivering a high-performance digital channel to market, either developed in-house or via external agency

• IT practitioners tasked with optimizing existing web-application performance, in situations where a ground-up rebuild is not a practical option in the short to medium term

The limited space available does not permit an exhaustive treatment, but hopefully it flags some of the cardinal points and acts as a useful introductory, “how to” guide to this important area.

How to Read This Book

It is hoped that readers will gain useful insight from all the content. However, given that is it seeking to address both a line-of-business and technical audience (albeit at a relatively high level), it is possible that some sections will have more relevance than others to your situation.

The material is organized as follows:

Chapter 1 provides a general introduction and emphasizes the goal of performance optimization. As such, it should be relevant to all users.

Chapter 2 outlines the categories of tools available for understanding application performance, and their generic strengths and weaknesses. Most useful to those with a management oversight of application performance or those embarking on monitoring, including delivery to mobile devices.

Chapter 3 is a suggested “how to” process for implementing frontend optimization. It provides a high-level flow process and touches on the key granular areas to address. As such, its primary audience is those wishing to gain a hands-on grasp of FEO in practice, such as someone in an IT role tasked with implementing effective performance optimization but lacking practical experience from elsewhere. It concludes by referencing a source for creating and managing key performance indicators (KPI).

Chapter 4 considers performance from a management/business perspective. It outlines some approaches and potential constraints facing those wishing to take a “root and branch” approach to building a high-performance culture in organizations. It concludes with a brief summary and recommendations about FEO in practice.

Ultimately, it’s a short book and should be eminently digestible during a train journey or short flight. I hope that you find it useful.

The Goal of High Performance

The key fact to continually bear in mind regarding FEO is that it is a means to an end, not an end in itself. Many studies have shown the strong association between digital performance and beneficial business outcomes. Many factors influence customer behavior (such as market-set expectation, nature of offer, design, etc.). However, performance is unique in that slow response can trump all other factors. At some point, slow performance inevitably equals lost sales, and user expectations of mobile performance are increasingly convergent with that of the desktop computer.

So, poor performance equals reduced revenue. Although some studies have shown that lost traffic does return, either later or via a different channel (e.g., visiting a bricks and mortar store, if it exists, for the brand in question), it is equally likely that this loss will represent some gain to the competition. Figure 1-1 contains RUM-derived data showing the association between transaction abandonment and total page-load time for iPhone and desktop computer users (aggregate US retail sites, one week).

In summary, high-performance sites accomplish the following:

• Minimize transaction abandonment

• Reduce bounce rate from key search engine destination pages

• Build customer satisfaction/loyalty

• Enhance “stickiness” (time on site)

• And thereby maximize competitive advantage.

Figure 1-1. Revenue loss: key page response versus transaction abandonment rate (Credit: Gomez Real User Monitoring]

Performance goals are met through understanding and focused intervention, potentially at all points in the delivery chain from primary infrastructure/content, third-party affiliates, delivery network, or at the client device. This book focuses on the latter, although effective monitoring and analysis will at least reveal weaknesses in the other areas.

Although the high-level association between application response and revenue has been established since the early days of the commercial internet, this does not particularly assist those responsible for managing performance enhancement for a given site. Between internal analysis and optimization, and adding external enhancements, it is certainly possible to improve the performance of any site. But if this is achieved at ruinous cost, then the net benefit is reduced proportionately.

The ideal is therefore to understand the tipping point—the performance at which revenue is optimized but beyond which net returns are reduced. This figure is unfortunately unique to a given site, although if comparative tests show a gross deficit between your site and its key competitors then it will be best to make a start anyway!

The difficulty in determining the optimal target performance for a given site is that any amount of comparative testing won’t tell you the answer—the only people who can do that are your customers. In other words, it is necessary to make an association between actual performance (which varies all the time, of course) and specific revenue-relevant outcomes such as transaction abandonment, page bounce rate, and basket size/total revenue.

Historically, the problem has been that these various metrics are captured by different tools—including RUM performance monitors, behavioral analytics, and order processing systems—and these cannot be correlated exactly due to differences in measurement between them (such as sampling and/or time-to-time aggregation). For example, one (actually, a RUM) tool that purports to display the relationship between performance and revenue is actually using an aggregate average-page-response for every page on the site to calculate it.

Trying to “read across” tools is even more fraught with difficulty. This is not to say that one should not try to make the association using the tools at your disposal. You should just be aware that it is very difficult, will only ever be approximate, and will not be worth investing the time unless you have a precise idea of how all the metrics are derived. However, with the advent of holistic Application Performance Management (APM) tools, the goal of effective performance monetization has become much closer—and in some cases, has arrived.

Monetization: The Holy Grail

The ability to report on transaction timings at individual user-session level (as opposed to all-user single-page or page-group performance) is particularly useful, although rarely supported. When present, it extends the ability to monetize performance; that is, to understand the association between page response to end users and business-relevant metrics such as order size or transaction abandonment.

The creation of such performance-revenue decay curves (for different categories of user), together with an understanding of performance relative to key competitors, enables decision support regarding optimal site performance. This avoids under- or overinvestment in performance.

Modern approaches to monetization use the events-database analytics extensions offered by some APM vendors. The key factor to establish is that you are measuring a 1:1 relationship between an individual user session, the site response to that session, and the outcome. The tools that do offer this provide powerful visibility through the ability to ask structured questions of the database, based on linking multiple metrics. This is done using Structured Query Language (SQL)-like scripts. To obtain maximal value, such products should ideally support relational joins—making associations between metrics to, for example, compare conversion rates between transaction speed “buckets.” It is worth delving into the support (immediate or planned) from a given vendor for the detailed outputs that will underpin business-decision support in this important area.

Figure 1-2 shows an example of monetization output from one of the vendor products.

Figure 1-2. Monetization: transaction performance (banded) versus revenue (£) (Credit: AppDynamics]