Now, let’s explore what client facing UX performance is and why it is critical.
User Experience is the compilation of many elements, as such, users find that a lot of factors can affect the usability and overall satisfaction of a mobile application. Among the high-level factors, users have to consider usefulness, usability, the value creation, the ease created for the users, credibility, accessibility and more. A key factor, from the user experience perspective, is the application performance itself.
Mobile applications are operating in complex network environments, where the communication channel parameters (bandwidth, latency, and packet lost -- to name a few) are continuously changing. As a direct consequence, this can cause impermeable damage to the usability of an application and the brand sentiment, overall.
Every application communicates with some type of backend – and therefore, this communication is Rest API-based, which enables applications to download and update information as needed, as well as maintaining synchronization.
In order to analyze the application performance, users should split this dilemma into transactions. A transaction is initiated when a user interacts with the application and clicks on any given button (such as clicking on the login button), and end when the application renders the results received from the backend. Additionally, note that most transactions can include 10s of Rest APIs requests and responses.
As the communication channels affect the experience, users will find other parameters within transactions that can affect their efforts as well, such as the number of requests or of round trips (a plethora of requests/responses), the size of downloaded data, and correlated response delays (from a server perspective).
Users may encounter non-networking elements that can impact the overall user experience, like the consumed CPU, Memory and/or Battery.
As it pertains to transaction performance, another important metric to consider is ‘Speed Index’, which is highly critical to the user experience.
When users examine an application model (as shown in the previous chapter), one can see that every connection from one activity to the next (edge), can be considered a transaction.
The aim of the solution, from the tenant perspective, is to identify regression performance and the corresponding root causes.
We would like to create a ‘performance base line’, based on the past executions and to begin with -- identify any significant deviations that may exist. Deviations may be considered any of the elements listed, such as, transaction duration, speed index, CPU, and Memory.
In this instance, the solution is building a hypothesis around deviations -- from a performance standpoint and it leverages large amounts of information that have been compiled on each transaction, in order to identify the root causes.
Figure: Performance base line