Stop painting and have a Meaningful Interaction with me!

When it comes to performance, what do we measure? Our focus has changed over time as we get more of an understanding on the importance of perceived performance vs. some absolute “the bytes came down in X seconds and the view rendered in Y”.

We had a lot of performance related talks at Google I/O, and it was fun to see some of this evolution. There are a series of tricks at play, where you keep the user engaged by showing them progress versus a binary blank view becoming fully available and interactive:

• As developers we know that loading indicators are lies, but some of our users still buy them
• We can get something painted ASAP (e.g. a shell) and then spinner until other content shows up
• We can show fake UI component holders that are then filled in later
• We can show snapshots of past content (sometimes literally a prior screenshot) and replace when new data comes in
• We can show the visible content in the viewport and lazily load below the fold (AMP does this and much much more… learn what they do here and how they prerender)
• We can load tiny images scaled up, and then replace the full images when downloaded (e.g. what Medium does with its images).

There are a lot of tools such as these to give us some slight of hand, and they work especially well when we can progress through the stages. I find that they tend to break down the most when there is a huge delay in one step: e.g. the shell loaded pretty quickly but most of the page is a huge spinner going on and on and you can’t trust if anything is happening.

Recently, we spent a lot of time measuring the time to first paint, which is often great, but it can cause you to trick yourself into thinking you have done a great job when all you have done is sped up one step, and you could have actually slowed the illusion and done harm.

Paul Lewis shared a visualization of how various approaches can differ here:

This brings us to the new topic of the day: Time to First Meaningful Interaction.

Alex talks about the “time to interactive” measure at length in a fantastic talk, and it is a key subset.

Search for meaningful interaction, and you will see links to a lot of therapy and tips for how to communicate with others. Compared to first paint it is much vaguer and requires you to think through the details of each view and what interactions are meaningful. They may differ based on the type of user, or where they are coming from in a flow, or the time of year. This is the type of thinking that you go through when you are building your UX, not just your performance. It is strategic as well as tactical.

The answers to these questions may change your approach to how you deliver a given view or application.

For example, in a transactional system that doesn’t have a lot of content to consume, you will very much want to wire up application so the user can click that button asap, and you will wait to minimize the time between “I see the button that I need to click on!” and “Why doesn’t it do anything when I tap on it?”

On the other hand, if you have a content heavy site where a user will want to spend some time taking everything in before their next interaction with the application itself, then you will be rushing to paint valuable content and allow them to scroll around to read that content. The actions and other items can lazily load much later.

Often there will be a mix and match. When you get to a product page on an e-commerce application you can quickly load information such as description and price, and load other info later such as reviews and secondary details (dimensions etc).

The right choice here will be the difference between frustration and showing the right level of progress so the user can keep in some sort of flow in your experience.

This is why I am excited for us to search for meaning, rather than blindly rush to paint, and how the Web now has the capabilities to deliver reliable resilient performance.