News Stay informed about the latest enterprise technology news and product updates.

Metrics can help improve website user experience

An expert says enterprise architects need to develop relevant performance metrics to capture website user experience.

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.

In the RAIL model, Idle helps to quantify the speed with which background processes can be interrupted. A big challenge for developers lies in architecting applications such that background tasks can be interrupted quickly when users start to interact. "It may make sense to schedule background work when the user is not active," Irish suggested, "but at any time, the user might interact, and we need to be ready for them." To achieve this goal, Irish continued, the main JavaScript thread needs to complete work in 50 ms chunks.

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.

Next Steps

Identifying valuable performance metrics

How metrics can transform IT

Dig Deeper on Microservices and mobile development

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close