In the last article in this series on mobile app performance, I wrote about how to ensure your app doesn’t fall in the category of those apps that users delete from their mobile devices and the various types of tests to run to help with that. Now, let’s focus on what you have to do when you run these mobile performance tests.
I mentioned a number of these different performance-related statements in the last article:
- Why performance matters.
- The importance of certain metrics.
- The need for testing early and often.
Well, what are some of the things that you should focus on when it comes to performance? You know the “why,” but what do you do about it? Where do you put your efforts?
One thing to focus on is launch time.
There are a number of different types of devices out there. You have the Nexus 5. Nexus 6. Your iPads. iPad Airs. You’ve got your iPhone 7s. Your Pixels, iPhone 8s, just to name a few. Phew!
You have all these different types of devices, and they all have different specs.
With mobile performance, you run into a lot of different challenges. You have a number of different things that can go wrong with your smaller screens and slower networks.
How fast is your app able to launch once the user gets it? Make sure you know how long it takes for this to happen.
Another area to focus on is the device resources.
All of the devices I mention above don’t have the resources of a laptop, let alone a workstation. You have limited resources on your devices. So be aware of them.
A third area is network usage.
I wrote previously about performance studies done with users in the United States. But obviously, there’s more out there than just the United States — and there are slower wireless networks in other parts of the world. So you need to be cognizant of that when developing your app.
Launch time, device resource usage, and network usage — these are three big ones that I recommend any developer focus on when developing an app for performance.
Let’s dig into these a little more.
It’s launch time. Do you know what the speed is?
For an example of how fast your app launches, let’s look at the ESPN app (from early 2017).
One key thing with app launches is that you want to focus on what I call above the fold performance. This term is used more on the website performance side of things, and not mobile app performance, but it is appropriate here. With “above the fold” for website performance, you want to ensure that when your website is loading, it loads the content the user sees first without having to scroll down the screen.
For mobile apps, you want the things in your app that show up on the first screen to load as fast as possible. Really, really, fast! And then, the other things that either require scrolling or are on other app screens, you can load in the background.
But the ESPN app is an example showing how this isn’t always done.
Blank screen of…
I love sports. I’m a big basketball and football fan. So naturally, I have the ESPN app on my mobile phone. But one of the things that bothers me with this app is that it can be very, very…very slow sometimes.
The image above is an example of me opening the app and seeing nothing but a blank screen for four seconds, in this case. This is something that happens quite often with the ESPN app.
For four seconds, I don’t see anything. If I were to show this app to someone and ask them within the first four seconds what app this is, they wouldn’t have a clue.
Obviously, ESPN and companies like them tend to have their own app-performance teams to handle mobile performance tests, as have some of the other companies that I’ve worked with in the past. They are a bigger company, and not a small or indie dev shop. So maybe it’s not as big of an issue for them.
But if you’re a smaller developer or app owner, this is something that could potentially kill your app. If it takes that long to load — going from four seconds and then all I get is the “ESPN” navigation bar, where the app isn’t responsive for something close to 10 seconds — that’s not acceptable!
With that performance, a lot of users would just delete your app and move on to something else. So your mobile performance tests should focus on your launch time and keeping it as low as possible.
Abusing device resources
Not overusing device resources — that’s something that you definitely want to focus on.
As I mentioned earlier, devices are limited in resources. When I look at some of the high-level specs of the iPhone 7, one thing that jumps out at me is it has a maximum storage capacity of a whopping 128GB!
My laptop hard drive crashed a few months back. I went on Amazon and bought a terabyte for something like $40 or $50. So my laptop has one terabyte of storage — and with the iPhone, I have my choice of 32, 64 or 128 gig. Ooohhh, yeah! That’s really something to get excited about, right?
So in your mobile performance tests you need to be aware of your devices’ resources and make sure that you are using those resources efficiently. You don’t want your misuse of the device’s storage — like including large images or caching too much data — to affect your users.
An example where it probably doesn’t matter as much — although they are aware of it — is Facebook.
In 2016, The Guardian, a British daily newspaper, discovered that the Facebook Android app was using up some 20 percent of battery life of the user devices with the app installed. Facebook said they knew about it, and they also said that they were working on resolving it, but you don’t want that for your app, if you are a developer or app owner — because unlike Facebook, your app could be deleted quickly by users. If your app is eating up 20 percent of a user device’s battery life, you can probably kiss that user goodbye.
Using the network — be a steward
Last thing to focus on, of the three I mentioned, is overuse of your users’ mobile network.
One of the things that you need to consider is that users across the globe have different types of networks, and all these networks say they’re the best. If you’re in the U.S., I’m sure you’ve seen the commercials…
Verizon says they are the best.
AT&T says no, they are the best.
Sprint says, “No, we are within 1 percent of Verizon,” so they’re the best since they’re cheaper.
T-Mobile says they are all those things, so “We are the best.”
It goes on and on.
They all say these things. But there have been studies by RootMetrics, a company that tests wireless network performance, that actually showed that Verizon performs the best overall, with AT&T taking a strong second.
But at the end of the day, users don’t care about that with your app. They won’t feel bad for you. You need to be cognizant of the networks that your users are on, and how typically fast and busy they are.
Mobile performance tests: Calls, APIs, and ads, oh my!
One way to do this is to reduce the amount of network calls, if your app has a backend service, for example.
If your app has photos that are stored online, and it’s downloading these photos to the user’s device, you want to ensure that you make every effort to reduce the download calls as much as possible. Each of those calls that are made slows down your app. Each call is using the device’s antenna and that in turn drains the battery.
You also need to watch your SDKs and APIs, too. These things can help reduce the amount of code you have to write, and thereby saving time, but make sure you have an idea of the types of calls that are being made over the user’s mobile network provider.
You also need to watch those ads. Many apps are monetized with advertisements. But you want to make sure that when those calls are made to your provider’s ad servers, those calls can be made as quickly as possible and that the ad shows up.
What’s the point of having the ad if, for whatever reason, the user’s network is too busy — or your app is doing some other stuff in the background — that when that ad request is made, the ad never shows up. The end result is the user doesn’t see the ad, and you lose a chance to make money in that instance. There is nothing for them to tap on and potentially provide you more revenue.
But how do you do all of these things? The way you go about doing this is to implement some tools. In the next article, I’m going to discuss some of the tools out there you can use to help you prepare your app for performance success.
Photo credit: Pixabay