(presenter) We're making good time.

We're on time for our next speaker to start bang on time, which is good, because Paul Bakaus, who you may know as a Google Developer advocate, lots of background with animations, with building things in the UI-- you'll remember his work on jQuery UI some years ago and building games in the browsers and all those kind of things.

Paul's going to give us a talk with the title of the illusion of speed.

Last night when we were talking about what was in this there was a lot of content, and I think at one point it was a much longer talk, and so the illusionist speed may be apped to the fact that this talk has to be squeezed down into 20 minutes, but yeah, talking on that subject, please make him very welcome, Paul Bakaus.

OK, I'm going to try to compress time as much as possible.

So let's get to this quickly.

I even have a minute more, so that's actually great.

Thanks, Tobias.

So let's start with part one.

I have four parts for one.

Part one is about the actual why-- what's actually happening, are we perceiving time differently than we think.

So for years, my team and I have been trying to convince people to make websites faster-- and hash tag perfmatters.

And this is about hard speed.

This is about actually improving the speed of your websites.

That's one of the things, but what is that assumption that faster websites are better websites is actually for? Is faster always better? Well, let's start with a simple example, page load.

If you look at page load, where do you measure page load? Is it the time to first ping, which can be automatically measured? Is it time to first useful ping, which is a completely different value? Is it time to first view port? Time to interactive, which is really important for games, which is the first time you can actually do something? Or is it the actual page load? Most of the time, the actual page load is completely irrelevant to the user.

It makes no sense whatsoever to measure that.

It's still the primary thing that people measure, which is sad.

So this is just a very simple example where perceived time is much more important than actual time.

And doing my research about motion, I created an article called the illusion of motion that was all about motion perception.

I found out that there's much more to cover, and so this time I'm going to cover even broader topic.

And it turns out that the overall perception of time and speed is as twisted as motion perception, if not more.

So similar to my illusion of motion article, Dennis Mishunov wrote an excellent series on the perception of time on "Smashing Magazine."

Who has read that article? Anyone read the article? Yeah, a few.

So super interesting.

Very long form.

Similar to my illusion of motion talk, it was already pretty long form, and so I definitely recommend checking out.

It comes in three parts and gives you a huge topic instruction, but I include a 10,000 feed summary of this and some current key terminology in his talk, but a lot of it will be new, as well.

So the way now our brains perceive time is completely different from the time that we measure with a stopwatch.

Perceived performance is actually so important that even Apple writes about it in their developer guidelines, saying the perception of performance is just as effective as actual performance in many cases.

And so time is a highly abstract concept for humans.

The way we perceive past, present, and future is not like it seems.

So if you're seeing a post card like this that says, hey, live in the moment-- and there's lots of other ways to phrase this.

I'm sure you've seen a post card like this.

Well, I have some sad news for you.

That's actually impossible, because we're all living in the past.

Our consciousness lags 80 milliseconds behind actual events.

When you think an event occurs, it has already happened.

(audience) That's going to keep me up at night.

(paul bakaus) Yeah.

So, live in the moment that was 80 milliseconds ago would be a more technically correct term, but it doesn't make the card beautiful.

So, yes, our brains actually have a time buffer, and so that time buffer is really important to collect all of our sensory information from eyes, from touch, from your ears, and make sure that they're all connected.

For instance, if you touch your feet, that feels instant.

It's not actually instant, because there is an electrical pulse going up that has arrived in your brain, but because of that buffer, it feels instant, and so this has some really interesting really messy-- and this will hopefully blow your mind even further-- implications, and here's one example.

As long as a hand clapper is less than 20 meters away, you hear and see the clap happen together, but beyond that distance, the sound arrives more than 80 milliseconds later than the light, and the brain no longer matches sight and sound.

What is weird that the transition is abrupt.

By taking a single step away from you, the hand clapper goes from sync to out of sync.

So it's not as seamless transition.

It's really just you do one step beyond the 30 meters, and it's completely out of sync.

That's because of the time buffer in your brain.

A practical example is day trading-- so a business where thousands of decisions are made each day in a matter of milliseconds.

Because we don't experience the now, we're simply too slow to make those decisions.

So this is where algorithms come into play.

Computers might not be smarter than traders, but they're definitely faster, and one anecdote here is Project Express, which is a trans-Atlantic cable multi-billion project that was built by a couple of private companies to make the internet faster just for them, and all they squeezed out of it was five milliseconds, but that was enough to warrant the multi-billion investment, simply because of that fact.

So here's another postcard.

Never let memories of the past define our view of the future.

Well, that's another card that's actually pretty hard to do, because that's impossible.

Why is that impossible? Because there's no future without the past.

Turns out our whole concept of future is dependent on being able to draw from memory and visualize the past.

People who cannot recall long term memories cannot envision the future and themselves in it.

So there's been studies with people who were in car accidents that just couldn't have a long term memory, and they cannot envision the future.

Our future is literally made of our past.

We create the future by thinking about the past.

So our memories are highly subjective and volatile.

Henry Roediger said, when we retrieve a memory, we also rewrite it, so that the next time we go to remember it we don't retrieve the original memory, but the last one we recollected.

So each time we tell a story we embellish it while remaining genuinely convinced of the veracity of our memories.

And important to us-- the way we perceive past time is somewhat counter intuitive.

So events where nothing happened are actually remembered as long.

So you have one long continuous activity, and that's actually-- sorry.

There's a mistake here.

So lots of my memories in the short activity.

So we have a day of stuff that's happening-- lots of cool things happening.

That is actually remembered as long.

I kind of switched them around.

And if you have one continuous activity, which is, let's say, you're driving, and you're driving for a couple hours.

Nothing has really happened.

Your brain actually squeezes that, because it only keeps track of the memories, and that's actually perceived as quick afterwards.

So this is really confusing.

The slides are vice versa.

So unfortunately, that means that, even if you have a very long process in your app or a very short process, the implications mean that if user recalls from memory they could be switched around.

[CRICKETS] What's that sound? So we suck at being a clock.

We're pretty really bad at this, but still we're trying to come up with really hard numbers.

For instance, 60 FS animation target-- one second load time, 100 milliseconds for response time.

Those are guidelines that we came up with in Rail and the performance model the Chrome team came up with, but some of those numbers are fairly reliable.

So right now we're looking at reaction time, where less than 200 milliseconds tends to feel instant.

Then you have less than one second, which is immediate-- sort of, hey, yes I can connect this to the action that I'm currently doing.

Five seconds-- everything below five seconds is a part of the user flow, and less than 10 seconds is the attention span, but it turns out that the attention span has changed.

So the attention span is now shorter than it was, and there was a study made that was looking at attention span in 2000 versus the attention span in 2015.

So 2000 was actually 12 seconds, and 2015 was eight seconds.

Thanks a lot, MTV, but it turns out that those numbers are not really hardwired for thousands and thousands of gears.

They can change.

So part two-- there's even further complications to this.

First one-- so let's take a basic example of something waiting for, which is load-- one second load time.

Well, think about the context of that.

Am I at a bus station or at a train station? Is that where I'm looking at the one second? Or am I just running? Am I at a dinner table? Or am I at the couch and actually at my home? All those contexts matter, because if I'm at a bus station, and I'm looking at a website, and I have a 10 second wait, I'm just going to skip it.

I'm not going to look at it.

I'm going to leave it, but if I'm at home, and I want to play the next RPG in my home console, and it takes a minute to boot up the console, whatever.

I mean, I know I'm going to play for a couple hours, so it's going to be fine.

One minute feels like nothing.

The context is really important.

And here's another example.

It takes five seconds to switch my channels on my TV.

Now, we can probably all agree that that sounds really slow.

That's horrible.

Why does it take me five seconds to switch? But if you'd see this statement-- this guy made me a burrito in five seconds-- well, there's no way he could make that burrito in five seconds.

That burrito has to be premade.

There's just no way.

I mean, I feel tricked.

So, wait.

I'm talking about performance, but I'm saying some things can be too fast? That sounds crazy.

Well, sometimes speeding up decreases the value of a service, and that's not all.

Wait for it.

Longer wait times can build up anticipation, and it's an important dramatic element, especially when creating-- here's a buzzword alarm-- narrative driven experiences.

So I give you two examples here.

I have a lot more, but two examples in particular that are actually pretty cool.

One is Coinstar, which is an automatic coin counting machine.

Apparently they can total up the value of coins way faster than people believe, so to avoid skepticism they added an artificial calculating delay to increase believability.

Second one is locksmiths.

There's an interview being done with a locksmith, and there's been a few others that came out with the same story.

And what's really interesting is that that locksmith was penalized for getting better at his profession.

He was tipped better when he was an apprentice, and it took him longer to pick a lock, even though he would often break the lock.

Now that it takes him only a moment, his customers complain that he's overcharging and don't tip him.

So it's really about the perception of the value-- that something takes long or not that long.

And so, yes, context matters.

Speed matters, but how do we actually deal with this? Now that we know some of the why, how can we compress the perception of time? First concept here that is important is active phase versus passive phase.

Active means we're actively doing something.

For instance, you are coming from a plane, and then you're walking to get your baggage.

That walking is the active phase, and passive would be you're sitting in front of screen, watching a progress bar, and doing nothing.

They're fairly different in terms of how we perceive them.

Time is perceived much longer in a passive phase-- on average, about 36% percent longer.

And one way to improve perception, therefore, is shorten the passive phase, and lengthen the active phase.

So one solution here is preemptive start, which means start work before the user realizes it.

And so in this example, you see that perceived by the user is only the second half, so we're starting earlier than the user expected.

Second one is early completion.

Show stuff before all of it is ready.

So perceived by user is only the first block, even though the load might actually take longer for the whole load to finish, but I'm adding three new concepts to this that Dennis didn't cover in his block series even though precognition is sort of a special case of one of the above.

The first one an optimistic UI, which is showing an action has completed that really hasn't.

Next one is precognition-- visualizing the future before it happens-- and finally visual illusion, sometimes enough to change perception.

So theory is boring.

Let's give you some examples again-- the first one being progressive images, super easy example.

That's an early completion example where I'm showing you something before the load is actually done.

Everyone can do this.

Super easy to do.

Next, static layouting.

I'm working on AMP, accelerated mobile pages, and in AMP, we can control-- we can very tightly control what we render and how we deal with rendering, and preloading, and precaching.

And we came up with this static layout concept where we always know how big any element on the page will be.

So even if you have nothing loaded, no external resources, just a document, we can lay out the page in advance.

And so there would be no flash of on site content, and this is a very common concept in native environments on iOS, on Android, where you see the app shell before you actually see the content that is loaded into the shell.

And this is a very effective way of showing something to the user before you're fully loaded.

Next one is YouTube.

That's also early completion.

Video isn't loaded, but it starts playing right away because it's buffering the first segment.

It would be crazy if we had to wait for the entire video.

Preemptive start, now-- different technique, but same idea.

How about multi-page forms? What we could do is we're in the login form, and user spends time there.

Puts in his username, password.

It's crazy that I've seen no one use this technique.

So I haven't seen many websites-- I think I've seen-- actually no one has-- not completely true.

I've seen one or two, but very few websites load the assets of the locked in state while the user is typing in his credentials, which is really silly.

I mean, of course you shouldn't use any user data and load any user data, but you can load so much stuff usually from the login state in advance because you know that eventually the user will log in.

Same goes for-- yeah one step back.

The same goes for e-commerce, for instance, where you have a multi-step form in a checkout process.

You can preload all of the other steps because you know that your users will eventually arrive for them.

And then another situation, again, is here because of the static layouting in AMP in this example.

We can preload the first view port, and we can do that for multiple AMP docs at once because it's so cheap, because we know what's on the first view port.

This is why the Google search AMP carousel feels instant, or as we call it, instant, because instead of preloading all of those pages and entering contents, we can just preload the first view port.

And if you want to use some of those prefetching yourself and don't want to spend a lot of time building up your own framework, you can use resources, which is a new style now that's already in a lot of browsers to prefetch sometimes just a DNS entry, sometimes the whole page, or even the complete render.

You can tell the browser, hey, I don't just want to fetch the resource.

Please render the entire next page so I have it ready right when I need it.

Now, let's talk about the more advanced examples-- optimistic UI.

Instagram is a great example here.

Instagram always pretends to work.

When you're on the train, and you lose your connection, and you click on the like button on Instagram, it will show it as liked.

And it doesn't matter if the like didn't work.

Instagram just buffers in the background, and eventually-- it basically gives you the promise that eventually they will execute the action and actually do the server transaction.

Now, of course, this could backfire.

This could backfire if you're never out of the train.

You're stuck in the tunnel, and you will be forever stuck in the tunnel.

Well, that's a bad scenario anyway, but it also backfires if something just breaks and the server connection is lost.

So you have to be super careful, because sometimes a white lie can become fraud, and especially, for another example, messages on progress bars.

Very common thing that rotate at random intervals.

So you'll see it in Uber, or in Lyft, or on whatever other apps.

They rotate about random intervals, and they are an obvious lie.

It's very easy for users to detect that they're obvious lies.

So the lies are only great if you're not caught.

So don't hurt the user experience this way.

One very cool example is precognition.

Now, touch events are actually always subject to latency because of the hardware, but also because of the display refresh rate.

So if you look at the physical device and how touch events arrive in the browser, you're looking at something like this.

So you have the display refresh here, and this is the ideal example.

Let's say there's no processing time whatsoever required for the touch event to arrive, which is never true.

Now, just because of the fact that we have to do it after we got a VSync signal and then and then actually do the render after that, we always have that 60 milliseconds lag, but what modern operating systems do-- many of them, including iOS and Windows-- is this, which is a actual prediction of the future state of where your finger will be in the next couple frames, which is really cool, in my opinion.

So there's a lot of smart prediction being done.

On iOS 9, it was added to support the Apple pencil, because they needed much finer control for that, and this is a way of actually dealing with perceived performance in a very interesting way.

And another one is easing.

So this is just purely a visual illusion, but if you look at those three examples-- first one, second one, third one.

I'm going to try this again just so you see it.

First one.

Second one.

Third.

So if you think about which one of those fed fastest, I hope it's not the bottom one.

So the bottom one was linear easing, and the middle one was ease out, and to many people that feels fastest.

And the reason for that is the fact that the deceleration feels extremely satisfying, as it occurs in the real world.

And the visual weight is put on the first half of the animation.

So the fact that our cases where easing is more convincing and powerful than even the active passive switching of the phase-- take momentum scrolling, which is basically if you flick a page and it bounces.

Now, what you're doing here is you're dramatically extending the passive phase.

You're flicking, and then you're basically passive.

You're waiting for the scroll to end.

However, the naturally ease makes up for it.

It's so powerful sometimes, and ease in, which is another way to speed up things, is especially useful if you have very long processes, very long progress bars or long animations.

That's because studies have shown that your emotional state and perception of the last moment of a longer activity determines how you remember it.

So if you went to a concert and most of it was pretty meh, but the last song was amazing, you'll have fond memories of it.

So for longer animated progress bars is actually quite nice.

So very quickly skipping over this because I'm running out of time, time perception is a creative far reaching and complicated subject.

I'm trying my best to show you a few clear examples, but there are some situations that are not completely clear.

Some situations are trickier than others.

Browsers only unload the current page after the new page has started rendering, so if you click on a link, you won't see a white page in most browsers today because only when the new page starts rendering we actually show you the new page.

However, that leads to this.

It makes the load of the next page feel faster than it actually is because of the active passive, but it regresses responsiveness in that we don't get an immediate reaction up on link click.

So the problem here is that, if we reverse this, we have the same problem in the other direction.

We have the responsiveness, but then we have the white screen again, and we have that regression on the active passive phase.

So it's not that simple.

There have been a few proposals, though, and one potential solution comes from the native world again.

This is something called activity transitions, which animates from one state of a page to another state of a page.

So you animate seamlessly from a previous page to a new page.

It's originally proposed as navigation transitions on the web 2014, but unfortunately no progress has been made since, and if you want that, you should nag me, and I'm going to forward it because I think is really cool.

This is actually a great way to make perceived performance better in the browser.

So nobody cares about how fast your site is-- just how fast it feels.

Thank you.

[APPLAUSE] Thank you, Paul.

Do you want to take a seat, and we'll come back to you for questions later on.

Also, that's blown my mind a tiny bit.

I always suspected I had a buffer.

I think it's way longer than 80 milliseconds in my camp, but, yeah, that's kind of a bit of a mind bender.