Why isn’t it enough to simply measure network performance? In this post, I will try to explain how UI response time is different than network performance.
Let's say you own a mobile application for hotel reservations. This is a highly competitive market, and you are trying to achieve the best user experience and make your application as fast as possible.
Processing Time
When a user enters their selection for hotel search, the application contacts the server and asks for the relevant search results. For efficiency, the server sends the results in a very efficient and compact format.
When the application receives the data, it has to process it.
First, it might need to decompress the data.
Secondly, the hotel’s list has to be sorted per user preferences. If hotel images are also displayed, the images must be opened and displayed. This processing takes time. And sometimes, it takes a lot of time.
The processing time also varies depending on the device. When the display is larger (as it is on tablets), your app needs to process more items because more items are visible. It also takes longer on weaker CPU devices. Each user experiences the performance differently, even if network time is the same.
Simply put, UI Response Time is the time elapsed from when the user clicks the hotel search button until the screen is loaded with the search results. No more, no less. This is the time you want to see in your monitoring tool.
Background Operations
Suppose your hotel search application has a great feature – once every ten minutes, it contacts a few external servers for price alerts. This is a background process – it will happen regardless of what the user is doing with the application.
Most importantly – these network operations don’t affect user experience at all! When you try to prioritize your work according to the monitoring results, it is very important to distinguish between these operations, and give them lower priority than operations that actually impact user experience.
Out-Of-Screen Content
Here’s another trick your developers are using to improve user experience: when a search request is sent, only part of the data is retrieved from the server. Usually it is just enough data to fully occupy the screen, and a little bit more (for scrolling).
But what about the rest of the data? In the old days of Web 1.0, a long list of results was divided into pages, with “next” and “previous” buttons to navigate between them. More modern applications are using a different approach – they will continue to fetch the rest of the search results in the background, allowing the user to interact with what they already see on the screen. This is probably one of the biggest benefits of Web 2.0.
Measuring the UI response times of such actions is very tricky. The reported time should be from the user’s perspective – meaning the report has to ignore network operations that don’t result directly in screen rendering. If the user selects one of the hotels for details, the results of those out-of-screen operations have no effect on the UI response time.
Look for a tool that will monitor your mobile application’s real user experience - and more specifically user-perceived UI response time.
Amichai Nitsan is a Senior Architect at HP Software.
