SAN FRANCISCO: Leading enterprises are embracing the idea of using performance budgets during software development to measure website user experience. A performance budget gives developers measurable targets for different phases of application performance. But it is important to choose the right metrics for the application, argued Paul Irish, project manager for Google's Chrome DevTools at the Fluent Conference in San Francisco.
A performance budget breaks down all the elements related to application performance into metrics that developers can test code against early in the development process. These metrics can include factors like page load times, interaction delays, animation rate and the ability to interrupt idle processes. As developers make changes, they can instantly see how the changes affect the application against the target performance budget.
Putting slow in context
The biggest challenge is that it is hard to measure slowness from a user perspective because "slow" is an imprecise term from a development perspective. What matters changes depending on the context. For example, 10 ms is lightning fast for an ecommerce site, but it would be considered slow in the context of a game, Irish said. Some popular application performance metrics include DomContentLoaded, Frames Per Second (FPS), first paint and the notion of jank, a slang term for describing perceived slowness.
But many of these metrics do a poor job of quantifying a user's Web experience. As a result, organizations are trying to meet performance goals that are different from perceived application slowness. "We want to make sure we are addressing the right problems and looking at things the right way," Irish said. A good metric needs to capture perceived user experience in the appropriate application context.
Understand the impact of different delays
Irish recommended that organizations look at the usability research Jakob Nielsen introduced in 1993, which is still relevant today. Nielsen examined the effects of application delays of 100 ms, 1,000 ms (1 second), and 10 seconds on website user experience. For many applications, 100 ms gives a feeling of instantaneous response; 1,000 ms keeps the user flow of thoughts seamless and allows a natural progression through tasks. A delay beyond 10 seconds loses a person's attention.
Irish later demonstrated where Nielsen's model fell short with actions like immediate application feedback. Even at 10 ms, there is a noticeable lag in the connection between where a user's finger is touching and visual feedback. This lag does not disappear until the application can respond in 1 ms.
Quantify website user experience with the RAIL model
Google has developed the RAIL (Response, Animation, Idle and Load Page) response model to relate the different phases of application flow to user perception of performance. This model provides measurable target goals that organizations can then incorporate in application performance budgets.
According to Irish, response from tap to paint should be less than 100 ms, which is where the user feels an immediate response, while touching and moving should be less than 16 ms. Animation should complete each frame rendering in under 16 ms, which corresponds to the 60 fps rendering speeds of modern browsers. Page load should be completed in 1,000 ms to make the website user experience feel seamless.
Embrace the right performance budget
Irish next discussed some of the Chrome development efforts to help enterprise developers meet application performance budget targets. One new feature being baked into Chrome is a waterfall viewer that makes it easier to see the correlation between what is happening in the network waterfall and the look of the page. The tool not only reports on network activity, but also frames and updates to the page.
It is not as important to see when a file was requested as it is the user's perception of how the page loads and flows. Irish has posted performance audits on major sites like ESPN, CNET, and Time.com to help explain how these principles can be applied in practice. Irish contends that RAIL is a place to start the conversation and that it can be used as a model for evaluating performance constraints of an enterprise's overall performance budget.
Identifying valuable performance metrics
How metrics can transform IT