When actual performance is more important than perceived performance
Over the last few years, web developers have been told that perceived performance is the holy grail of web optimization. And indeed, I have been preaching this concept myself for years and it has served me and my customers well.
What is perceived performance?
Perceived performance is a metric of how fast a user thinks your site is and not actually how fast it loads according to your measurements. The main concept is to make your users think your website is fast by showing them progress bars, loading images in the back, getting data asynchronously and so on. Indeed, focusing on perceived performance is a very good practice and in many aspects is more important than actual performance.
The concept of perceived performance has been utilised for a while now and I really recommend watching Eli Fitch’s presentation Perceived Performance: The only kind that really matters (Fluent Conf 2017).
Sounds awesome! So what’s the problem?
Sometimes, no matter how much you invest in perceived performance, your users will grow tired of waiting for your website. The reason for this is an important metric called Time to Interactive. (TTI)
According to Google, “Time to Interactive is defined as the point at which layout has stabilized, key webfonts are visible, and the main thread is available enough to handle user input”.
A simple example is when you go to Google’s home page. The time from which you clicked on a link which brought you to www.google.com until the time you were able to click on the main search input and start typing is the TTI. Even if there are a thousand other things which are happening in the background (like fetching your avatar, recommendations, notifications, etc), the thing which interests 99% of users is the ability to click on the search field and start typing. One might say that this is perceived performance because the user “measures” your performance by it, however, this is actual performance. You can’t use tricks here. You need that search field to appear as fast as possible and to be interactive as soon as possible.
I see what you did there… What can I do?
The first thing you need to do in order to improve your TTI is to do a little “R” (you know, that first letter in R & D?). You need to try to get into your users’ head and try to ‘guess’ what interests them most to see/do in each one of your pages first.
The Google example is pretty obvious. For Facebook, you probably want to load the feed as fast as possible and make it scrollable and then get the other stuff. It’s important to leave space for the other things to come in so your page doesn’t “jump” and feels choppy.
These are simple examples. However, as your website/web app is more complex, it might be more difficult to figure this out. Logging BI events is really important here. In many occasions I was sure I knew what my users wanted to do first, but after studying BI events, I realised I was wrong.
OK, I think I got it! How do I test it?
The good people at Google have realised that TTI is very important and have provided a very nice way of measuring it built right into Chrome — The Audit Tab in the developer tools.
I won’t go over all the great features that are offered in this tool, however, I would like to focus on the TTI. I decided to run the tests on this actual Medium post page and see the results. In order to run it, just open the Chrome Dev Tools, click on the ‘Audit’ tab, and ‘Perform an audit’. Here are my results:
So Medium is doing pretty well on ‘Accessibility’ (things like ARIA attributes, color contrast, meta tags, etc) and fairly well on ‘Best Practices’ (using https, allowing users to paste passwords, etc) but not so much on ‘Performance’ and ‘Progressive Web App’.
Let’s look at the ‘Performance’ results:
As you can see, the TTI is about 8.5 seconds. That’s a lot. Part of the reason for this big number is probably the ‘First meaningful paint’ which took about 5.5 seconds. One might argue that the ‘First meaningful paint’ is the actual TTI here because the user can already read text which is somewhat of an interaction, however, between the 5.5–8.5 seconds marks, you won’t be able to scroll/tap on the screen. The important question here is what YOU consider to be the TTI. For the main page of medium.com, the TTI could be considered the time it takes to see the story suggestions, however, if a user sees a story he like and wants to read but can’t click/tap on it, that’s pretty bad and then you might consider the ‘real’ TTI to be more interesting.
Here are the results for medium.com
So if we consider the time where a user can see the suggestions, the interesting time would be almost 6 seconds, but, if we consider the time until a user can interact with the page, you will have to about 3.5 seconds more.
Chrome gives you some suggestions which are usually spot on and will help you reduce you load time.
Summary
For years, perceived performance has been regarded as one of the most important metrics in the web development world, and it still is. Time to Interactive is only beginning to gain momentum and web developers need to be aware of it and plan their web apps accordingly with help from their BI teams.
