Mobile App Performance Metrics Checklist [Development Stage]

Probably, each developer can easily explain why the testing stage is so important. Therefore, let’s skip the part where we repeat obvious statements and arguments and switch directly to the specifics and essential metrics, you should take care of. However, the wide variety of testing types and the number of their specifics are too voluminous for a single article. For instance, it is possible to distinguish at least 9 types:

• Unit Testing
• Integration Testing
• Regression Testing
• Smoke Testing
• Alpha Testing
• Beta Testing
• System Testing
• Stress Testing
• Performance Testing

Therefore, let’s avoid considering a single testing stage, for instance, the performance testing during the development stage, how to conduct it, etc. Instead, let’s talk about the critical metrics and most essential factors worth taking into account during development. In other words, we propose you examine performance optimization and its aspects from a theoretical perspective, rather than technical specifics.

Fields of Key Metrics

In fact, there are 3 main criteria, that highly impact the final performance level. Usually, they are divided into 3 topics: device, server, and network. Yet, we would like to make an additional one - code. In fact, each of these spheres has its own specifics. For instance, mobile device performance is based on its capabilities, so if the device is outdated, it may result in long loading or freezes. Alternatively, if the application is too resource-intensive, it may result in overloading, high memory consumption, etc. Actually, the number of such related issues is massive in each topic, and may take hours to consider them in detail. Thus, to be more precise and faster, let’s make a mobile app performance metrics checklist of the most common performance issues and briefly explain them.

Mobile Device Performance

As was mentioned before, the main aspect, that defines the overall device-related part is its capabilities. Obviously, cheap and low-quality mobile devices, as well as outdated ones, will have more performance issues than modern powerful smartphones. Yet, this issue is not an actual responsibility of the developers, but rather a problem of daily active users. However, it is worth it to lower application requirements if it is possible. Alternatively, some mobile application developers provide a lite version, which is less resource-intensive and provides only the main functions and features of an original mobile application.

In order to check the compatibility of the app with the device, we recommend you test it on various devices. It is an easy out-of-box solution, that allows fast testing from the end-user perspective. Truth be told, such an approach is limited in functionality and won’t always help to locate and fix an issue, yet would be a great illustration of the overall customer experience depending on the used device.

If you are willing to create the best device-related performance, you may push your mobile application to live and wait for a few months to gather data about your average users. For example, most application distributors, as well as third-party analytical software, show at least basic information about the most common devices used and prove app store optimization tools. This will be enough to categorize main device types or models and direct more resources to optimize your product for the most common gadgets, or the weakest of them. As a result, you will be able to improve the user experience of the major group of your customers.

Additionally, with the use of specialized analytical software or app store optimization tools, you can also check a few main performance-related aspects like:

• How much time does it take to open your mobile application(load time),
• How much battery life does your mobile application consume,
• How much memory(RAM) is it required to use an app without any occurring performance issues or app crash reports,
• Can your customers use your mobile application in the background with other applications without interactions?

Actually, it is possible to check all of the foregoing aspects without using specialized software or app store optimization tools, i.e. purely manually. However, it will take more time and resources, sometimes less accurate and informative. Yet, some developers still prefer a manual approach because it can be more flexible and allows testing in unique circumstances.

Server Performance

Another important aspect to take into account is server-related performance. In fact, this field is crucial for the correct working of any app. Mostly, each software application or other product is based on servers, stores its data on databases, uses various integrations such as API, etc. Clearly, a poor response rate in at least one of these directions may result in freezes and long loading periods. Thus, the developers have to check all of the possible backend or server-side performance issues in order to prevent possible impact on the performance.

It is worth mentioning, that some applications are fully cloud-based or highly dependent on server-side rendering and other similar services, that are dependent on the server.

Talking about the mobile app performance metrics, related to the server performance, it is possible to highlight a few main characteristics:

Server capacity is its ability to maintenance requests. The bigger capacity is - the more requests can be operated for a shorter period of time. Clearly, the bigger the server capacity is - the better server performance may be.

CPU usage is an essential metric, that illustrates the time period and how much CPU server operations require. It may vary depending on the server settings, the number of requests and background processes, their complexity, etc.

Response rate is the average amount of time, needed to fully proceed with the request from the app user. Schematically, this process can be illustrated as:

virtual user request > server > server response > virtual user

In fact, it is one of the most crucial server-related metrics, that highly impacts the overall server performance and user satisfaction.

Issue or Failure rate is the percentage of unsuccessful responses. In other words, it is a correlation between the overall processes and the ones, that failed. Clearly, the fewer failed processes you have - the better performance and overall product satisfaction are. If your product has a high failure rate, you have to figure out the reasons and how to fix them. Mostly, a high failure rate is based on poor server services and quality or lies in code mistakes.

Network Performance

Eventually, it is not a secret that network connection and its stability are important for each application, whether is online-based or provides some services, that are network-dependent. Yet, including the fact, that most modern active users are using the Internet on a daily basis, as well as that most modern applications are using the network connection for at least a few features or services, they provide, it is hard to underestimate the importance of stable network performance.

Frankly speaking, Network and server performances are codependent. For instance, the foregoing server aspects can be much better than network ones. In this case, performance may suffer because of poor network settings and capabilities. On the contrary, the network capabilities may overcome the server capacities, therefore the second ones will define and shape the final performance result. So, it is important to find a “golden mean”, when network and server performances are as similar as possible and able to perform the same tasks with equal results and productivity.

Talking about the important network-related aspects, that seem similar to the server ones, we can name capacity and response rate, yet they have some specifics. For example, network capacity has two different types: theoretical and practical.

Bandwidth is the theoretical characteristic, that illustrates the maximum capacities of the network, and the amount of data it can transmit for a set amount of time.

Throughput, on the other hand, is the physical marker, that is a real possibility of the network in specific conditions. Clearly, the maximum is rather a hypothetical level, used to track the data transmission, and monitor how critical the load is. Mostly, it is avoided or unreachable due to some conditions or factors.

Another important aspect is Packet Loss. This key performance indicator shows how much data is lost during the transmission between the user and the server due to various reasons. Clearly, you would like to avoid it as much as possible, because it can not only slow down the loading processes and performance but cause errors and app crash reports as well.

Among the most common reasons for packet losses are software and network issues, and provider or router mistakes. Usually, to measure and track the lost packets, operators use Transmission Control Protocols, known also as TCP. The process of returning lost or damaged data packets is called retransmission.

Latency is an essential metric, that is partly similar to the response rate and indicates the time, required to transmit the data between the user and server, or backward. Additionally, the delays or disruption of data packets between these destinations are known as Jitters. Among the reasons, that cause Jitters are poor connection, overloaded network, etc.

Eventually, there are some additional mobile app performance metrics, that do not need to be explained: Network connection and availability. Yet, it is worth mentioning, that there are a few various levels of availability: Ethernet(E), 3G, 4G, Wifi, or wired. Usually, they go in ascending order, from weaker to more powerful connections.

Code Factor

Finally, we would like to highlight the importance of code. In fact, we believe that despite the importance of the previously mentioned fields of mobile app performance metrics, the role of the code is the most important aspect. While all previous aspects are flexible and may vary, depending on different aspects, as well as improved and fixed during the maintenance stage of the development process, the code basis is worth considering from the very beginning, because making changes in the code samples is a much more complex process.

Alternatively, clean and correct code can overcome other aspects that impact the overall performance. Frankly speaking, there are no specified metrics of how good or clean the code is. It is a very subjective factor, that varies depending on the specific case. However, there are some tips on how to make sure the code is clean and optimized.

First of all, avoid complex and redundant code: if there is a way to simplify code units without losing functionality - do it. The best concept is to make it simple, but not oversimplify. Additionally, it is worth regularly inspecting the code, because experience says there is always something to change or improve. Take care of the optimization.

In fact, our developers regularly claim that there is nothing, that cannot be fixed on the code level, especially in the context of performance. The clean code rule is probably the most common advice you can meet on the Internet. At first, it may seem very simple and obvious, yet do not underestimate this advice.

For a better illustration, we propose a few cases of our developers, that managed to increase the application performance by making changes on the code level only.

Example: Screen resolution and preloaded messages

The first example of such a solution is adjusting the messenger for the device specifics. One of the products we took part in the development of, provided a messenger feature. This feature, like any other modern social media app, or messenger, included preloaded messages, so when the user opens the dialog, the application shows a few recent messages that are already processed.

Yet, as we figure out during the testing stage, in some cases the number of the preloaded messages was too big to be processed by various devices. Therefore, our backend developers changed the preset number of proceeded messages and specified various cases. In fact, they have divided the types of devices and made the number of preloaded messages flexible, depending on the devices’ screen size and average screen resolution. To make it possible, they simply set different rules for each device type. In other words, they set the conditions and parameters for this feature, so it preloads the number of messages according to the average screen and device’s capabilities.

As a result, thanks to the flexibility of the required actions, the performance of the application highly improved and worked better on each of the defined devices.

Example: Data Array Issues

The second case is the issue with photo uploading. One of the projects provided a photo-sharing feature. To be more precise, the application had two features: taking a photo with the in-app functionality and sharing these taken pictures within the app. During the maintenance, we figured out that a single picture causes no freezes and everything works relatively fast. Yet, when we tried to upload 5 pictures at a time, we noticed that the loading process it taking much more load time.

As a fast and easy solution, we decided to divide the data array into separate processes. So, in case the user will upload 5 or more pictures at a time, on the user side there will be no seem difference. On the contrary, on the backend, this action(uploading 5 photos) will be considered as 5 independent processes: upload picture 1, upload picture 2, …, upload picture 5. As a result, the performance increased, because the application is more adjusted to work with a single object than an array of them. Of course, it is possible to rearrange the whole app architecture to adapt it to work with data arrays. Nevertheless, such rearrangement will take much time and resources. Moreover, such changes are unnecessary, therefore it is easier and more pragmatic to find a “crutch” and implement it instead of changing the whole structure.

Summary

Here is a mobile app metrics checklist of the main aspects and key performance indicators worth considering to develop a high-performative mobile application and their brief explanation. Clearly, all of these aspects and fields of metrics are important, yet it is possible to highlight that the major aspect, that secures the performance of your application and impacts it the most - is the quality of your code basis.

Talking about the most common tools, that can be used for performance testing, apart from manual on-device testing, there are various emulators and third-party software. For instance, Robotium for automated Android testing, or the monkeyrunner API(also Android devices only). For the applications, based on iOS it is possible to use the Automator. In fact, the list of such tools is much bigger, yet it is not the main subject of this article.

Additionally, it is worth mentioning that the tech stack used for the development is also important and directly impacts the performance of the future app. For instance, it won’t be a secret that native applications are more reliable and productive than hybrid ones. The quality of various assets, APIs, libraries, or frameworks, as well as the programming language and its support by the platform, may highly impact the overall performance of the app.