(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.