Perception is everything, when you’re talking performance

1 comment · · Tagged: , , ,

A month ago I made a big call on Twitter,

That was in reaction to Facebook’s failed attempt at making a hybrid app for Android and iPhone that used HTML5… when LinkedIn, Google and others apparently have done the same, very well, and Sencha did something similar (although not perfect).

I felt like I had to back it up.

I started this blog post a month ago too, but it was hard to put into terms what I was thinking, until it hit me what the worst complaint I had about Facebook’s apps.

It always looked slow.

You loaded the app, you got told it was Loading. Go to the Newsfeed, Loading. You see a notification waiting for you, tap that… Loading. Read a comment, Loading. Loading. Loading. All the time, you get hit with the Loading screen. And it’s no better even in the latest all-native apps. They’re still Loading, Loading, Loading.

I learnt while working on Trade Me Touch that faking speed is just as good as having real speed.

What I mean when I say Perceived Performance is when the app preempts you, it’s aggressively caching everything, it’s loading but you’re doing things anyway that make that wait not noticeable.

iOS on the iPhone and iPad utilise this to the max, especially on the apps that come with it (because they have special things they can do that other apps cannot). You load the Mail app and it looks like it’s ready to go right off the bat. It isn’t, iOS lies to you. When you apparently close a built-in app on iOS, it takes a snapshot and uses that as its splash screen. You may have caught this when you go scroll through that list of emails but you cannot, it’s because it made you think it was ready to go, but it wasn’t just yet.

In fact, how often do you even see a built in app on iOS say the words “Loading”? When you, pull down to refresh in the Mail app? Load a web page in Safari? The fact is, iOS appears fast because it is appearing fast. That’s not to say it isn’t actually fast, because it is actually fast… the perceived speed merely blends it.

So how does Trade Me Touch appear to be fast?

  • It’s caching your user profile, so it still has something to show on the homepage… it’s not 100% accurate information, but it was at a time and it isn’t necessary to be 100% accurate all the time. It will refresh this in due course of loading the homepage. Just not immediately.
  • The reason why Browsing the category tree is fast is because it’s already preempted you. It’s already downloaded all the templates required, it’s already downloaded the category tree. It’s simply grabbing the two from memory and mashing them together (it even stores that across sessions too).

These are just a couple of ways that made it appear to be fast. Now, if I was at Facebook, how would I have made the mobile apps appear to be fast?

  • Cached the living daylights out of all HTML+JS+CSS resources. You don’t need to redownload it all the time.
  • If you had Notifications or Friend Requests, preemptively download those information sets. Then when I click on Notifications, you don’t come across the Loading screen. If they still haven’t loaded, at least give the last set of Notifications so you can see if you missed any of them.
  • Remember information from one page to give to another. Something that Trade Me Touch doesn’t necessarily do just yet, but had a framework set up before I left. If I have a photo, surely I don’t have to reload the photo again on the next page?

Interestingly, Facebook the actual mobile web version does do some of the preemptive downloading. It just doesn’t do the aggressive caching. They just didn’t do it in the apps, which is strange. Also, not even the native app (at least for Android) does some of these things.

In short, use preemptive loading and cached assets to your advantage when working on mobile. Even on desktop you’ll get a nice performance boost. It’s not all about what you code, but how you code. Perception is everything.