How Performance sets truly great Apps apart

Performance is a topic that often gets talked about at conferences or in articles about best practices – but the reality of day-to-day development often looks quite different.

Many things are agreeable in principle, but when it comes to actually fitting them into the busy schedule of real world software development, things that are hard to measure often fall by the wayside — no matter the initial aspirations.

Performance then, is a topic that is all too often looked at seriously for the first time when an app becomes unbearable to use. Too rarely is it taken into account from the start, and even if it pops up in the planning stages, it often loses priority once the app reaches production.

I put it to you that a focus on performance turns decent apps into great ones.

Let me explain.

Why Performance matters more than you think

Every time you interact with an app you notice its performance. Not always consciously, but you notice it. If an app is always or even worse sometimes slow, resentment towards it starts to build over time, to the point where even thinking of having to use Jira to do anything has me looking for ways to avoid opening Jira at all.

The inverse is true as well, though at first glance to a lesser effect. You may have heard of Linear — if you haven’t, you should check it out. It is everything that Jira isn’t, in the best possible way.

Linear has gotten very popular in the last 2 years for more reasons than one, but a singular theme is permeating almost every feature they implement: Speed

They give themselves 50ms to sync a view and have no spinners (aside from the one loading the app initially). Let that sink in. A fully cloud synced app with no spinners, that just renders effectively instantly. They can then build other things on top of this foundation of performance, like a really effective keyboard driven command palette that would be pointless in an app that isn’t fast.

Whenever I use linear, I am happier at the end of it, because the App gets completely out of my way. No frustration of sluggish views, slow searches, or waiting for updates to save or propagate. Everything feels instant.

Linear is just one example of the joy that fast apps bring to the table, but a particularly poignant one for me, because of the technology it uses: it is build on Electron, a tool that allows developers to use web technologies for desktop applications. Now that might not mean anything to you, but at least in the Mac community, Electron has a bad name. Most of the popular apps that use Electron have not focused themselves on performance like Linear has. They are sluggish and slow, like Slack or Atom often feel like. The community has been blaming Electron for this, thinking that if those apps were native, they would be faster. Of course, native apps tend to be faster than non-native apps, but what really makes these apps slow is the mindset that was taken when designing and building them.

Linear proves very clearly that the underlying technology is not always to blame. Focus on performance and you can make almost anything run really fast! More importantly: your users will love you for it. I have seen more people be ecstatic about Linear’s performance in the last year, than I have ever heard say anything positive about Jira in the last decade, simply because the app gets out of the way. That is the power of performance.

What it takes to achieve a performant App

Achieving great performance requires continuous effort across all teams: Design, Frontend, Backend, Product. They all need to have performance in mind for every major decision to achieve a really fast app. This is impossible if performance is treated as an afterthought. It also makes it much harder to restore performance, once it has been ignored for a while — undoing product decisions that harm performance is much harder than taking performance into account before they are made in the first place.

Once performance plays a role in decisions, it is very important to not let performance-slack come into play too much – it is all to easy to ignore a small performance decrease when your app is fast (and it is ok to so, sometimes) but you must avoid that becoming a regular occurence, otherwise all the hard work up front will get lost over time.

How to (possibly) convince your Manager

First and foremost: Performance sells. Faster and more responsive website see higher conversions as well as higher retention. That makes a lot of sense of course, faster websites are more fun to interact with, they let you do what you want without getting in the way.

Performance saves money. It saves money a variety of ways in fact: A better optimized database structure and backend saves money in server costs. Smaller frontend artifacts can also save in CDN costs, faster builds save in tooling and deployment times, not to mention salaries, by enabling faster workflows and happier developers.

You also save money and time by not having to rebuild. This is probably the biggest savings. I have been hired at various companies to rebuild products from the ground up, because they were a completely hopeless mess, that had gotten so out of hand that you couldn’t refactor it anymore, and all of these projects were horrendously slow – they all were less than 3 years old.

Spending the resources to rebuild an entire app is no joke. It is at least twice as expensive as the salaried time spent on the rebuild. No new features are being built while it is going on and you pay a high opportunity cost as well because you are stuck rebuilding: No adjustment to the market or new circumstances.

In Summary

Thinking about performance while designing & developing your product can have a huge impact. Better conversions, better publicity through excited customers’ word-of-mouth marketing, less costly rebuilds.

Please start doing it, faster apps are better for everyone.