Being interested in Web Performance as a developer is not really a choice anymore. If you, for example, decided to watch all the presentations from this year’s Chrome Dev Summit (a conference organised by Google Chrome Team), you would quickly realize that almost all sessions tackled the Performance in one way or another and it’s evident how seriously this topic is treated. I realize that one conference’s line-up is not a proof of a trend, but on the other hand Google and Chrome Team are powerful thought-leaders for the developers community. And I can bet that if someone starts their first research on the Performance, they will end up finding out about the Perceived Performance metric.

Perceived Performance as we (don’t) know it

The problem with the “Perceived Performance” term is that there isn’t one clear definition of what Perceived Performance really means in the context of the web. I tried to find a clear information on that metric and I failed. There are many write-ups about optimising for Perceived Performance, or how to measure it, but none of the articles really explains what Perceived Performance is. After looking into a lot of resources, I got an impression that it’s broadly understood that Perceived Performance is a metric that tells us whether the website FEELS performant to the user, no matter whether it really is fast or not. I know this is really vague definition, but believe me that I didn’t find anything more explicit. This definition is actually well-aligned with the meaning of the word “perceive”: to become aware of something, to notice, realize something. Users become aware of the speed of the website (or lack of the speed) and they “rate” its Performance based on their feelings. But the lack of common understanding of the term is not the only problem that we have in this matter.

Why so selective?

Imagine: you are going to a long-anticipated concert of your favourite artist. They make a great entrance and make everyone excited about what comes next (a lead singer flying in, fireworks, beginning of your favourite song, whatever you like). Then, after that amazing start of the gig, the lead singer starts to sing and you can’t hear it at all because the microphone doesn’t work. The two guitarists are not in sync so everything sounds a bit off. The decoration falls apart. Be honest with me: If someone asked you the next day if you liked the experience, what would you say? Most probably you would say that it wasn’t what you expected. You wouldn’t say that the concert was amazing, because the way the artist entered the stage was mind blowing.

You know it would be silly to rate the whole experience only by it’s first few moments. And yet, when we talk about the Perceived Performance, we are doing just that. Almost any article on improving the Perceived Performance focuses on metrics that are tightly bound with the the content load time. We have articles on faking an illusion of speed with the placeholder content or app shell approach, write-ups on using progress bars instead of spinners to make the app feel more prompt, advice on optimistic UI or uploading content as soon as the user selects the media on their device.

Unfortunately the user experience doesn’t boil down to the fast page load or response to user’s input. There is a whole spectrum of Performance issues that user might bump into, that we seem to ignore called Rendering Performance. Jank, scrolling Performance issues, reflowing content or a browser crash (due to the excessive CPU usage) are not uncommon problems. Believe me, even if the page load was really optimised and blazing fast, the user can still leave your service frustrated.

Pats on the back

I tried to figure out what might be the reason for so many people to overlook the mentioned Performance issues (and at the same time to put so much effort into optimising for the faster load times). The answer came to me when I was using the Lighthouse the other day: there are plenty metrics that let us measure the load Performance: First Meaningful Paint, Time to Interactive, Last Painted Hero and so on. At the same time, there are next to no metrics to tell us how our website is behaving after the document is ready. Think about it: it is way easier to work on something if we have some measurements available to us. We can easily spot how we are progressing with optimising our page speed by running a Lighthouse or a WebPageTest. We are the given numbers to compare. What is more, we know that these metrics can have an influence on SEO. We know that these metrics are something to share as a proof in the Performance optimisation case study that could go viral. These metrics feel real and give us satisfaction once we cross the threshold marked in green. It is no wonder that we focus on improving them. We sometimes forget why we even started measuring the Performance and we put and equality sign between the fast load time and the great user experience.

Unfortunately, for the Rendering Performance we don’t have appropriate metrics. The only metric that comes to my mind is measuring the FPS (frames per second) as we interact with the page. And even this metric isn’t a part of any report and is not something we usually remember (or know how to) check.

Think about the whole experience

To save your user a headache, you should work on a holistic approach when it comes to the Perceived Performance. The loading time is really important, I am not trying to tell you it isn’t. Many users will navigate away from the website if it takes too long to load. But they can also navigate away if it’s jumpy and the animated banner causes jank. If you would like to find out more about improving the Rendering Performance, there are resources available. I recommend reading the Web Fundamentals Rendering Performance guide from Google or watching my talk about Interaction Performance from performance.now() conference. I hope these materials will help you understand what is happening under the hood of the browser and leave you with some actionable advice for the future development.

ABOUT THE AUTHOR

Anna Migas (@szynszyliszys) currently works as a Front-end Developer and Designer at Lunar Logic. As of 2018, she has a title of Google Developer Expert for Web Technologies. In her spare time she is travelling, playing video games and reading sci-fi/fantasy books.

3 Responses to “How we perceive Perceived Performance”

  1. Frank Gomez

    Great Article. Couldn’t agree more. Functionality – how the website works is critical.

  2. Weekly Links #142 – Useful Links For Developers

    […] How we perceive Perceived Performance […]

  3. Performance Calendar » Gradient Image Placeholders

    […] you agree that progressive rendering helps with the perceived performance (what?, how?) then read […]