Need for Speed — Native App Performance
There’s no doubting we live a fast-paced life. Technology operates at speeds that were unimaginable 30 years ago, and our access to that technology has exponentially grown alongside it. Going back (almost) 30 years ago to 1992, IBM invented the world’s ﬁrst smart phone. In 1994, this trend setter hit the market and opened up the public’s eye to the possibility of timely information accessibility.
Then, at the turn of the century, when smart phones and the internet merged, this possibility started to become a reality. With this reality hitting the market, and the mainstream audience starting to buy in to the world of powerful smart phones, different applications of the smart phone started to emerge. Suddenly, a phone that wasn’t just suited to the professional market space, but it could be adapted to be used by anyone which is where we saw apps (or applications) take centre stage.
So, what makes a good app?
Before you consider those factors, be sure you’ve read up on the 10 steps to take before starting an app. Sure, the ability to jump onto a cloud-based web application via a browser mobile app works well, if that web application is mobile responsive, but the beneﬁt of a native app is that it does it faster. Speed and accessibility are the two aspects that shine brightest in a native mobile app as opposed to one that isn’t.
Refresh: A native app is designed specifically for the operating system of the mobile device (i.e. iOS, Android, Windows OS). It has the ability to access other apps on that device, such as Facebook accessing Photos to update a status.
You’ll also ﬁnd our Guide to Creating a Successful Software Product helpful for kitting your product up with the essential survival skills, available for free download.
So how do we measure speed?
Physics tells us that speed is the distance divided by the time, but what distance are we covering? Apps are intangible - we can’t lay out a measuring tape and watch the app travel from point A to point B. In actual fact, your app is going to many more places than one at any given time. When it gets there, what is it doing? Is it still performing as fast?
Below I have listed out a few ways we can quantify the performance of our native apps with regards to speed, or in other words, loading times.
Time to First Byte (TTFB)
This is the measure of how quickly the app launches when opened on a device from being fully closed (not partially open for background refreshing). For example, when opening an app such as Instagram, and you get the white screen with the logo presented ﬁrst and then it ﬂicks to the feed, this is an example of TTFB.
If you open an app that is already open in the background, therefore taking you back to where you left off (and if you are like me, have about 20 apps open at once), the load time metric would not qualify here.
Best practice says that aiming for a TTFB of <3 seconds is ideal, and that may be the case when we look at the metrics from the server’s point of view. But Time to Load, our next metric, is where this can be a little deceiving.
Time to Load (TTL)
TTL is the measure between loading a fully closed app, to the moment when a user interacts with it. This is really important when we are looking at the different kinds of devices users are accessing your app from, and comparing that to your server’s reported TTFB. For example, your app is operational on iOS, and its TTFB is trending pretty well according to best practice time, but the TTL ratings are not reﬂective of this; in fact, they are quite skewed.
A deeper dive into the skews of data, you see that certain devices are lagging in load time here, even though it seems that their operating systems are up to date. When creating an app, it is crucial to consider not just the operating system, but the model of that device(s). This is where market research is critical. Having an understanding of which devices and models your user base means you can be proactive about developments.
Here’s a hint! If you are using analytics programs to ﬁlter user behaviour data (if you aren’t already, now would be a great time to start), the model of device is usually a ﬁlter option. If it doesn’t give you this level of detail, it will most likely give you a screen size which is perfectly associated with the device model.
Total Availability (TA)
Hands up if you have been scrolling through social media in the very early hours of the morning? I would say most of us have, at some point. Wouldn’t it be disappointing if during those late night scrolls, the app crashed?
Crashes (otherwise known as downtimes) and uptimes are measures we would use to understand Total Availability (TA). Better performing apps demonstrate the ratio between uptime and crashes positively skewed towards uptime.
One of the biggest things we need to consider here is the amount of time users leave apps open for background refreshing. When this happens, the server strains with the load. Established apps such as Facebook combat this with ensuring their TA ratio is positively skewed towards uptime.
Reaction Time (RT)
What’s your reaction time? How quickly do you react when someone throws you a ball? If you’re anything like me, then it’s not great (hahaha). Optimally speaking though, we want to be quick on the mark like any coordinated athlete. Do our apps work the same? Ideally, we always want our apps to be reactive and agile, but this isn’t always the case.
Reaction Time (RT) measures how quickly the app responds from a user interaction. If I want to post a photo on Instagram, my app should bring up my photos instantly once I click the plus button. If it doesn’t, I assume the app’s not working and will probably try again later, or not at all.
The example apps I used in this blog have been well established in the market for years now, and as much as these metrics are important to them, they were so much more important when they were ﬁrst released into the wild (so to speak). Generally speaking, people are impatient (sorry!), especially when it comes to apps on their mobile.
If you are thinking about creating and launching an app, amongst all of the other data points you will be gathering such as subscriptions and users, heavily consider these speed associated datapoints.
Apps have the potential to go viral with a positive user group to support them. This won’t happen if they are slow, unresponsive or crashing out. There are plenty of ways to combat this - starting with measuring these time sensitive data points is a perfect place to accelerate that viral success.
We’re always on the other end of the line if you want to start creating a successful application — contact us here for a chat.