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.
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.
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.
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.
WebPageTest and Wireshark are tools common to those of us who deal with application and network performance.
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.
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 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:
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.
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.
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!
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!
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.
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.
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
Organizations looking to unite application developers, security teams, and IT operations must implement DevSecOps best…
Our Microsoft 365 administration series continues with more on configuring Microsoft Teams. In this article,…
GFI FaxMaker is a powerful and complete solution that should meet the requirements of every…
There’s no rule that says that you have to make use of port ACLs, but…
If the cloud doesn't seem right and buying a server costs too much, maybe network…