Lesson Outline

Actual Performance & Perceived Performance

Performance is critical to the user experience in an application, even small hiccups in performance can lead to a frustrating experience overall. Often it is small, sometimes imperceptible, differences in performance that can make an application feel native and smooth versus just feeling a little "off".

In the High Performance Applications in Ionic module, we discuss a lot of factors related to performance, and we get into the low-level technical details. If you have not read that module, I would recommend doing so for some more in-depth theory and strategies for improving performance in an application. In this lesson, we will focus on discussing performance at a high level in the context of user interface and user experience.

We could break UI/UX performance down into two separate categories: actual performance and perceived performance. In case you have not already read the High Performance Applications in Ionic module, here is a quick snippet from that module that explains the difference between perceived and actual performance:

You know how often weather services will report a feels like temperature as well as the actual temperature? Some factors like the wind and humidity can make the temperature feel hotter or colder to humans than it actually is.

A similar concept applies to performance, the way in which our application is designed can alter the user's perception of how performant it is. There may be no actual difference.

A big part of making an application feel faster is to provide feedback to user interactions as quickly as possible. We've run into scenarios in this module where we have clicked a button and faced a delay before the page actually started loading due to a massive amount of rendering we were asking the browser to do. The process for this specific interaction looked something like this:

1. Click page button
2. Wait ~2 seconds as page loads
3. Navigate to page

Having the user click a button and not receive any kind of feedback in 2 seconds is not within acceptable levels, we need to give them some kind of feedback within around 80ms for it to feel performant.

Let's assume that there was absolutely no way we could possibly improve this load time, due to operations we need to run on the page there is simply no way around that wait time. Although we may not be able to improve the actual performance, we can improve the perceived performance.

All we need to do is display something to the user during this wait time - something that indicates their interaction worked and that something is happening. What that is may vary, but in this case, it will probably make the most sense to do something like this:

1. Click the page button
2. Immediately navigate to the new page
3. Display a loading indicator where the content needs to be loaded in, or if necessary an entire screen loading overlay
4. Perform the necessary loading
5. Remove the loading indicator

Now when the user clicks the button they can see something happen immediately, when they arrive on the next page they can see that something is loading in (they don't just see an empty screen and wonder if the application is broken). Although the total load time may still be exactly the same, this process will feel a lot more performant.

Generally speaking you will spend more time working on the actual performance of your application, but spending time on improving little details that impact perceived performance can be the difference between a smooth experience and a frustrating one. Sometimes, perceived performance can actually be more important than actual performance. Consider these two examples:

1. Page button clicked

2. (wait 2 seconds whilst data is loading)

3. Navigate to page

4. User can interact with page instantly after navigation

5. Page button clicked

6. Instantly navigate to new page

7. Display loading indicator for data (page can not be interacted with)

8. (wait 4 seconds whilst data is loading)

9. Remove the loading indicator

10. User can now interact with the page

The actual performance of the second example is worse, because the data takes 4s to load instead of 2s. However, I would argue that the second example still provides a better experience than the first even though the task is accomplished slower. With the first example there is no indication of what is happening, the application will just freeze for 2s. This is a jarring experience and the user might wonder if the application is broken. The second example takes longer, but the user receives quick feedback and won't feel like anything has broken.

The main takeaway here is: work on improving both actual and perceived performance.

Actual Performance

Factors that impact the actual performance of your application will affect how quickly tasks in the application are performed, e.g. how quickly we can load in what needs to be displayed, and how quickly we can render and display frames to the user.

The biggest factors in determining the actual performance of your application is the browser rendering process and network request response times. We need to optimise the code for our application to ensure that it can be run efficiently by browsers. This can especially become a concern when we are attempting to create more intricate layouts and animations in an attempt to improve user experience. A poorly designed animation can have a big impact on performance, and any improvement you were seeking through implementing that animation would likely end up having the opposite effect by making the application slower.

Factors that impact performance are discussed at length in the High Performance Applications in Ionic module, and it is not easy to summarise, so I would recommend taking a look at that module for more details on improving performance. In this lesson, we are mostly going to focus on discussing a concept that is more uniquely related to user interface and user experience, and that is perceived performance.