An app's performance is key to making users want to use it, say Meta engineers Dave LaMacchia and Jason Patterson. This includes making the app lightning-fast, battery-efficient, and reliable across a range of devices and connectivity conditions.
To improve Threads performance, Meta engineers measured how fast the app launches, how easy it is to post a photo or video, how often it crashes, and how many bug reports people filed. To this aim, they defined a number of metrics: frustrating image-render experience (FIRE), time-to-network content (TTNC), and creation-publish success rate (cPSR).
FIRE is the percentage of people who experience a frustrating image-render experience, which may lead to them leaving the app while the image is rendering across the network. Roughly, FIRE is defined as the quotient of the number of users leaving the app before an image is fully rendered by the sum of all users attempting to display that image. Measuring this metric allows Threads developers to detect any regressions in how images are loading for users.
Time-to-network content (TTNC) is roughly the time required for the app to launch and display the user's feed. Long loading time is another experience killer that may lead users to abandon the app. Reducing the app's binary size is paramount to keeping the binary small:
Every time someone tries to commit code to Threads, they’re alerted if that code change would increase our app’s binary size above a configured threshold.
Additionally, they removed unnecessary code and graphics assets from the app bundle, resulting in a binary one-quarter the size of Instagram.
As to navigation latency, this is possibly even more critical than launch time. Meta engineers carried through A/B tests to find out that:
With the smallest latency injection, the impact was small or negligible for some views, but the largest injections had negative effects across the board. People would read fewer posts, post less often themselves, and in general interact less with the app.
To ensure that no changes cause a regression in navigation latency, Meta engineers created SLATE, a logger system that tracks relevant events like triggers of a new navigation, the UI being built, activity spinners, and content from the network or an error being displayed.
It’s implemented using a set of common components that are the foundation for a lot of our UI and a system that measures performance by setting “markers” in code for specific events. Typically these markers are created with a specific purpose in mind.
Creation-publish success rate (cPSR) measures how likely it is for a user to successfully complete the process of posting some content. On iOS, posting a video or large photo is especially tricky since the user could background the app after posting their content without waiting for the upload to complete, in which case the OS may terminate the app.
Here, the approach taken by Meta was aimed at improving the user experience in those cases when posting failed. This was accomplished by introducing a new feature called Drafts to allow users to manage failed posts in more flexible ways instead of just providing the option to retry or abort the operation.
We discovered that 26 percent fewer people submitted bug reports about posting if they had Drafts. The feature was clearly making a difference.
Another approach was trying to reduce perceived latency, as opposed to absolute latency, by showing a request that was received when the data upload was complete but before it was processed and published.
Last but not least, Meta engineers saw a great improvement in app stability after they adopted Swift's complete concurrency, which, they say, does a great job at preventing data races and reducing hard-to-debug problems caused by data races.
