Perceived performance part 1: what is perceived performance?

I have this talk I first gave late last year called Client-side performance for back-end developers, of which those slides are just the first iteration. A notable topic I haven’t included, is the importance of perceived performance. Yet it’s something I’m very conscious of, and I’ve been working continuously to improve it for My basic question is always, “How does it feel to use this?” And this is a principle that cuts across the whole site, especially the games. I want it to feel great: I want it to feel slick, fast, responsive on all devices and browsers.

Running across this piece by Brian Jackson (formerly of keycdn) the other day brought the topic of perceived performance back to the forefront of my mind, and reminded me was something I should write about. So in this series of posts I want to cover what perceived performance is, and how I’ve improved it on

OK, so let’s start off with perhaps the most important question: what is perceived performance?

Well, one way to look at it is it’s the answer to the question, “How fast does this feel?” So, it’s not about how fast some process really is, but about how fast a user perceives it as being. And so it can sometimes be surprising when real, objective, measurable performance and perceived performance don’t always correlate. Now with that being said, it should be obvious that in many cases improving real performance can often help with the perception of performance too, but sometimes you can improve perceived performance significantly without improving real performance in any way (and sometimes whilst making it slightly worse).

You might legitimately wonder why this matters but, when it comes to the web, the fact is that slower websites lead to dissatisfied visitors who don’t hang around, and fewer conversions (however you define conversion for your site). And never mind how fast it is or isn’t, if your website even feels slow, you’re going to lose out. People will vote with their attention by directing it elsewhere.

The key point I’d like to make - and I hope this isn’t too controversial - is that your users’ perception of your web app’s performance is actually more important than its real, measured performance. Like I say, perceived performance is key to a great user experience.

How have I approached this for Well the first thing to say is that I have, and continue to, expend effort on making everything actually, measurably, really faster, and these are things that I’ll talk about in other posts. Beyond that, and it’s really something you do when you’re out of options for making something measurably faster, I’ve used a few tricks and techniques to improve perception:

  1. Load assets resources out of band/asynchronously or on demand.

  2. Load key above the fold content as quickly as possible, and give the user immediate feedback that something is happening.

  3. Gracefully degrade the experience on slower devices to keep performance up.

  4. Load and render key above the fold content first, delay everything else, even if this means the page load takes multiple seconds overall.

I’m going to talk about each of these techniques in more detail in the follow-up posts, so you can see exactly what I’ve done. I’ll also highlight areas where improvement is still needed (I’m nothing if not honest!).

For now though, I’m just going to leave you with this take home…

PRINCIPLE: Improving real performance will generally improve users’ perception of performance. Where real performance improvements are not possible, selectively loading and displaying content, or otherwise indicating that activity is taking place, can improve their perception of performance even at a small cost to real performance.

Read the rest of this series on perceived performance:

THIS POST: Perceived performance part 1: what is perceived performance?

NEXT: Perceived performance part 2: load assets asynchronously or on-demand

NEXT: Perceived performance part 3: load key content first and give the user immediate feedback