Perceived Performance - Don't Forget the User

Typically when it comes to web performance, speed is everything. We usually recommend not obsessing over GTmetrix, PageSpeed, or Pingdom scores that much and instead focusing on how fast your website is loading. However, one exception to that rule is that you also need to consider perceived performance. In today's post, we will explore why perceived performance can be crucial to your website's success and the best overall experience for your visitors.

Perceived performance

Perceived performance can be described as simply how fast does your website feel when it loads? This can be slightly different than how fast your website actually loads. Perceived performance is all from the perspective of the user, not from a website speed test tool. Generally, the two go hand in hand, but that's not always the case. Below are a couple examples of things that might speed up your site, but not necessarily help your perceived performance.

Psychological time in our brain usually differs from objective time on the clock.

- Denys Mishunov

Time perception in the active or passive state

We know that we humans perceive time differently depending on the type of activity we perform. An activity can be active (for example, calling up a web page) or passive (for example, waiting for the page to load). Research in the study Dynamics of temporal experience in active and passive waiting situations shows that, especially at the beginning of a passive activity, the passage of time is perceived as slower. Studies also show that users take about one second to transition from an active state to a passive state.

Now, what does this knowledge about the different perceived times depending on an active or passive activity bring us? An important conclusion is not to bring users from the active to the passive state from the first second, in which we make them aware by spinners or loading bars that they are waiting (i.e. they are in the passive state).

It can be concluded that not only is it unnecessary to show the loaders to the user if the waiting (loading) time is less than one second, but it may also affect the perceived performance.

Lazy loading

A good example of a faster website with worst perceived performance is how lazy loading is sometimes implemented on websites. The images below were taken from the unveil.js project, which is a lightweight plugin to lazy load images for jQuery. This plugin uses an animated spinner to show that the image is still loading. Notice how when we captured the screenshot the below images loaded, but the top one is still waiting. Just by having the spinner there it immediately gives us a feeling that there is a delay. This is not what we want visitors to feel.

Luke Wroblewski learned this first hand when they were experimenting with their Polar app, which has now been acquired by Google. They added a spinner to let people know things were loading. However, this was the feedback they got:

There seems to be an excessive amount of waiting around for pages to refresh and load - it doesn't seem as quick as the previous version.

By adding the progress indicators people started watching the clock, and in the end, it had the reverse affect. Lazy load can be an effective way to speed up a website by not loading all of the assets immediately, but we recommend skipping the loading indicator altogether and tweak the viewport so that they don't see them loading as they scroll down. Perceived performance means thinking like the user.

Instant feedback

We now know it's smart to keep the user from going into the passive state. The best way is to give the user immediate feedback as soon as they act.

A very simple way to implement instant responses in your user interface is to add an :active selector to link elements and buttons.

The active pseudo-class indicates that an element has been activated by the user, in which the button's background color or border color changes when the user clicks it (thus activating the active pseudo-class). He thus gets immediate feedback that something is happening.

Web fonts

Another common example we see of perceived performance vs actual performance is when it pertains to how you load web fonts. A lot of people tend to follow guidelines from tools such as Google PageSpeed and others so closely that they just move the CSS for their Google fonts to the footer. While this does fix the render blocking issue it also creates FOUT, flash of unstyled text, because you are loading the fonts towards the end of your DOC load.

FOUT can be very annoying, distracting, and also again make it seem like it is taking longer for your page to load. Another example of this is Typekit. Even though it loads asynchronously, FOUT can be detrimental to your visitors. There are better ways to both correctly load web fonts and achieve fast load times, see our post on web font performance.

How fast should your website load?

Kyle Peatt summed it up quite nicely:

They don't care about how many requests your website makes or how fast the screen repaints. But they do care about what those things impact - their perception of performance.

Ilya Grigorik, a web performance engineer at Google, had a great talk at Fluent 2014 on the subject of Speed, Performance, and Human Perception. In it, he crafted a formula to better define perceived performance.

perceived performance = f(expected performance, UX, actual performance)

He made the point that achieving good performance, both actual and perceived, includes not only the web developers but also the designers. It should be a collaboration, as most developers tend to lean towards actual performance and designers learn more toward perceived. Collaborating can help you achieve a better balance.

Now with that in mind, the "actual performance" still does matter. That is of course why we operate a content delivery network. Forbes ran a test in which they started adding delays intentionally to their pages to see how it would affect their conversion rates.

As you can see, the lower conversation rates directly correlated with the slower load times.

In Google's Site Performance for Webmasters video, Maile Ohye, states that "2 seconds is the threshold for ecommerce website acceptability. At Google, we aim for under a half second." And that was back in 2010! So if you are approaching the 3 second mark you probably have some work to do. Generally aiming for under 2 seconds is at least a good benchmark to begin with.

Summary

As you can see there is a big difference between perceived performance and actual performance. Both are equally important, both from a systems point of view and UX. If you have one without the other, most likely your website will not perform as well as it could. Remember, when it comes to using website speed test tools, don't always blindly follow their advice, otherwise you could be hurting your perceived performance.