Mobile app performance: Get up to speed with these tools and tips

In my last article, I discussed some of the things to focus on to give your app a chance at performing well. In the final article of this series on mobile app performance, I go into some details of the tools to use. I’ll also provide some tips to help with creating a well-performing app. There are a number of tools that are available to implement for app performance testing. Some are well known and others maybe not so much, even among those of us in IT. Let’s go through a few.

Mobile app performance tools

New Relic is a big one in the application performance management space. However, it is also known to provide SDKs for mobile app performance. In addition to New Relic, other players providing mobile app performance tools are AppDynamics and Dynatrace.

New Relic mobile app performance monitoring
New Relic

Those are three vendors that have SDKs available for developers to add to their app and utilize them for performance management. These vendor SDKs collect information about the performance of your app and send the data to their servers on the web. Your account gives you access to see a number of performance statistics about your app and make any appropriate changes to address metrics that are not performing to your standards.

Crash SDK tools

Crashlytics, which used to be part of Twitter and is now part of Google, and Crittercism, which changed its name to Apteligent two years ago, are two mobile app performance vendor tools that provide app crash reporting, among other things. These tools also utilize SDKs, just like the above tools, to collect crash data about your app. They send crash data back to their servers and help point you to the cause of the crash, such as which part of your code that threw an exception leading to an app crash. This is very helpful information when you’re not sure where to start troubleshooting a crash event.

Crashlytics crash monitoring

Backend performance tools

WebPageTest and Wireshark are tools common to those of us who deal with application and network performance.

Do you WebPageTest?

If your app has a mobile backend, WebPageTest is a good tool to use. It’s an open source tool that you can use to test that mobile backend and see how responsive it is, especially if it’s your own backend. WebPageTest can be used to run simulated user transactions that can be performed by real users in your app. The result will help you figure out where in your app, and in what geographic location, your users could run into issues. You can address these before they become a problem.

Many developers use backend services for their apps. Kinvey and Google Firebase are a couple of the more commonly used backend services.

You can install the SDKs for these services into your app, and the tools above will help you identify if they are causing issues. But if you have your own backend infrastructure for your app, similar to the one HPE sells in the video I showed in the first article of this series, then using WebPageTest to test that backend is key.

Shark the surgeon

Now Wireshark basically is something that gets more into of what a friend of mine likes to call “the nitty-gritty.”

Wireshark really goes into extreme detail — piece by piece — of the communication that’s happening between your app and your backend service. You can see each individual request that is being sent across the user’s mobile network. It’s what we call “a surgical tool,” where you are getting more into the weeds of your app and how it’s performing. You can get the information you need to identify any issue of what’s going on between your app and your backend servers to help resolve any problems your app may be having.

All the dev’s tools

All of these tools in some way will help you get information such as crash occurrences, HTTP response time, app launch time, etc. This is the type of information that you want to make sure that you are able to get from whatever tool you use. You need information about all of these:

  • Is your app crashing?
  • How long is it taking for it to launch?
  • What are some of the resources that it’s using?
  • How is it using those resources?
  • What are the devices?
  • How fast is each of the individual screens themselves performing?
  • What are the various interactions?
  • What are the various screens that your app has?

It goes on and on!

There are a number of different things that tools like these can provide. It’s just a matter of choosing one that fits what you’re looking for.

If you don’t have any of these types of tools in your app, get one and use it! Some are free, others are freemium and paid. Whichever route you take — free or paid — get something to test and monitor your app’s performance. Give yourself a chance.

Performance tips

Mobile app performance

Above, I talked about some of the tools that are out there for you to use to test, monitor, and manage your app’s performance. Now, let me finish things off with some overall tips on good app performance.

To make sure that your app has the best chance to succeed, it must perform well. That has been the mantra from the beginning of this series of articles. At the end of the day, the goal is to design and develop a good app that has the features that you envision and that you think — or have tested — that your users want. But in addition to that, good performance is key. For that to happen, you need to follow some tips.

Cache me if you can

When analyzing an app for performance, whether web or mobile, one of the things I always look for is how much data is being cached. It’s always recommended to take advantage of device caching. This makes sure that for static objects like images — that your app is pulling from somewhere else, from say Amazon S3, Dropbox, or even your own backend server — your app is utilizing the device’s ability to cache some data locally. Whether your app is on Android or iOS, you need to specify exactly what caching you want done and for what objects.

Granted, at the end of the day, making sure that your app is caching data does tend to take more work. You want to be careful what you cache because user devices don’t have unlimited resources, as I’ve previously discussed. You don’t want to cache everything because that may adversely impact the device. However, there’s really no getting around that fact that you need to cache something. If not, if you just release an app without doing any caching, then objects like app images could reload each time a user goes to the screens that contain these images. This is bad for performance!

Caching can also save you when the user’s mobile connection goes bad. Your app can make a call to the local cache instead of a call over the network when it’s likely that nothing will happen. You will have an unhappy user if this happens, and nothing works. Again, bad for performance!

Get ’em low

Caching is great. But what if you don’t want your app to have to make any calls over the mobile network? You decide to include app images in your app directly, for example, so that it gets pulled locally on the first and every attempt.

If that’s the case, and your images are on the device itself as part of the app, one of the things to be cognizant of is that the bigger size your images are, the bigger your app file. So you must ensure that you’ve optimized your images to keep the sizes low. Depending on the type of app you have, you want to use PNG images over JPEG images. This is often recommended. However, JPEG generally does a much better job than PNG at compressing the image size. The quality may be reduced with JPEG, but if the app is not very image-focused, you may be able to get away with lower quality, but smaller size, images. Make sure to test to compare both image types. To ensure top mobile app performance, the bottom line is to make sure to keep those image sizes low!

Request reduce

The next thing is to minimize the number of requests that are going across the network. I’ve mentioned previously about some of the things you don’t have control over — your ads, your ad networks, the SDKs that you have in your app. This list goes on, too!

With SDKs, you may have a little more control. So you definitely want to try to reduce those SDKs if you can to improve mobile app performance. But if you have something that does what you need — say, a software SDKs like Apptentive that I mentioned before — then you want to implement them, but do so with care. Make sure to use your app performance management tool like New Relic Mobile to see what those SDKs are doing and how they’re affecting your app’s performance.

Compress that

You want to ensure that compression is not disabled. Something like compression tends to occur by default by both the mobile device and the backend server software. There should be no reason not to have this enabled. Data compression will ensure that if you do have large images or text-based files being sent to your app from the web, the app will request that this data be compressed so that it is as small as can be going over the user’s mobile provider network. So make sure that your backend server that is serving data to your app has compression enabled.

Set a target

Lastly, set performance targets at the very beginning of the app design and development process, if possible. When you’re creating your app, set some targets for how you want it to perform.

Tim Kadlec was the first I came across who coined a term he calls the “performance budget” for web app performance. What this means is that a web app has different pages, like an order page, where you specify what level of response time will be acceptable for that page. I use this term here for mobile app performance. You should set a performance budget for your app screens. Have an idea of how fast you want or need a screen to show up. While two seconds is the typical rule of thumb, go with whatever you think is appropriate for your ideal user. This will be your target for the app’s performance when it’s in the app stores.

These targets can be based on some initial testing or user research you’ve done. However you come up with them, you want to have some sort of performance targets that you can strive for, and that you’ve set for each individual screen and your app as a whole. This way you can make sure your app is as fast as possible for its users.

So go out there and make it happen — make your apps perform fast with these mobile app performance tools.

Photo credit: Pixabay

About The Author

6 thoughts on “Mobile app performance: Get up to speed with these tools and tips”

  1. Great write-up and summary of the many tools we need for mobile app performance, Jean.

    It’s worth mentioning that most of the mobile app performance tools you mention (New Relic Mobile, etc.) also handle crash reporting. That’s one less SDK to add and maintain in your mobile apps.

    I love the concept of performance budgets and I have a couple of questions.

    1. With a performance budget, you talk about setting a maximum response time for app screens. Do you have any tips on how to measure that on customer devices?

    2. When SREs talk about error budgets for software, we usually have some measure of accumulated error over time like “our budget is N crashes per hour or M minutes of downtime per month”. When you exceed that budget, you stop work and focus on improving reliability to get back under the budget limit.

    What happens when requests exceed your target time? Have you had experience with accumulating the excess time for slow screens and using that to drive improvement?

    1. Hi Jonathan,

      Thanks for the comments.

      You’re correct. Many of the enterprise mobile APM tools provide crash reporting and analysis, usually as one of their features. I just wanted to focus on the couple I know of that started out solely as crash reporting tools, such as Crashlytics and Crittercism.

      In response to your questions, here are my thoughts:

      1. To help with setting a max response time for your app screen, I would look to one of the tools I mentioned – New Relic Mobile. I’m not endorsing them or anything, but I know it has the ability to tell you how users interact with your app’s screens, and can provide details of response time for screens based on methods like ViewDidLoad.

      So if you use New Relic, you should be able to see this data. I believe you can get the same information with AppDynamics, and other such enterprise-grade tools.

      I just started looking into Google Firebase to see if I can get some of this same data as well.

      2. I’m not an SRE, at least not as it’s described today, so I’ve never been part of an organization where I can tell the dev team to stop work. My job then, and now as a performance consultant, is to help figure out why an app is performing slowly. You’re in an enviable position 🙂

      Anyway, that’s a long way of saying I don’t have any experience accumulating the excess time above your target as part of a process to drive improvement with a dev team. When a request exceeds the target response time, it’s more about trying to figure out why and how it can be resolved either at that time or sometime later, depending on user behavior.

      However, this is how I would approach it:

      First, I would start with alerting; not for responding to an incident for slow app screen performance, but more for logging. The alert will help you log how long above your performance budget the incident was.

      Next, I would monitor these alerts (or script something up), having knowledge of my performance budget for app screens, to see if the exceeded threshold is reached, such as X total seconds/minutes above the max response time.

      There would also need to be an understanding of what caused the target time to be exceeded. If a particular alert had nothing to do with anything the dev team did, it probably wouldn’t count toward their budget.

      Lastly, much of this is dependent on your industry, your app, and the type of users that use your app.

      Sorry for the long response. I hope I answered your questions, and that it helps.

      – Jean

  2. I like the concept of “performance budget.” I do think most apps should shoot for 2 seconds or less, but not all apps have to be lightning fast. Another tip I’d also suggest on top of everything you mentioned is to use the new tool, Apptim (, to easily test and analyze mobile app performance, preventing any issues from going live to your users. It gives you a full report on app render times, power consumption, resource usage, crashes and more and it doesn’t cost anything.

  3. Hi Kalei! I have not yet checked out Apptim. But I’m glad you mentioned it because I’m about to update one of my apps, and this will be a good chance to take a look.

    I believe we connected on LinkedIn. Reach out to me there, and I can let you know my thoughts when I’m done.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top