Perceived Performance

The only kind that really matters.

Hi, I'm Eli.

I like to make things on the internet

Today I'll be howling about

Why focusing on perceived performance is smart
How humans perceive time
A box of tricks to manage perceived loading time
Predictive preloading

Why Perceived
Performance Matters

Web Performance
is a matter of time.

Time is a funny thing.

Objective time
vs.
Subjective time

We've gotten INSANELY good at objective performance.

HTTP/2

Service workers

Code minification

Image optimization

Critical Rendering Path

Tree shaking

Code splitting

Lazyloading

Edge node caching

SVG spritesheets

We optimize for objective time.

What if users don't notice?

Just Noticeable Difference.

Objective Time differences of 20% or less are imperceptible.

Steve Seow, Microsoft

Shoot for 30% speedup.

We don't live inside of a web performance blog post.

Don't chase diminishing returns.

Focus on the subjective.
Better 💥 for 🤑.

How Humans
Sense Time

Active phase
vs.
Passive phase

Humans tend to overestimate passive time by 36%.

Richard Larson, MIT

Takes about ~1 second to transition to a passive state

Nielsen Norman Group

How do we use this

Keep users in an active state, keep them from entering a passive state.
Make passive phases feel faster than they actually are.

Keep users active

Key for short durations.

What we can do

Don't tell users they're waiting.
Respond to users immediately, even if nothing is happening.
Keep users in flow with more responsive event listeners.

Resist loading
indicators

Woah. Woah. Woah.

Slow down here.

Don't use loaders?

But perceived perf?

Loaders tell users
that they have to wait.

Adding a loader prematurely
puts them in a passive state.

As waits approach ~1 second,
start to use loaders.

Immediate
Feedback

Immediacy keeps users from entering a passive state.

Stay :active, kids!

Optimism!

Optimism!

Optimism!

Better Event
Listeners

Takes ~1 second to
enter a passive state.

React as soon as
the user signals intent.

Mousedown gives you a
100-150ms head start.

:active animations
buy you more time

~200ms duration gives you a +50ms bonus

Works on touch devices too!

Begin on touchstart.

Cancel on touchmove.

Un-suck passive waits

You start to lose people
at ~1-4s of waiting.

Critical to get this right.

What we can do

The right loading animation can make time pass more quickly.
Adapt loading scheme to each user.
Distract with shiny objects.

The Perfect
Progress Bar

Uncertain waits feel longer.

David Maister

Progress bars give
users certainty.

Animation makes a difference.

Bars with accelerating
bands feel 12% faster.

Chris Harrison, Zhiquan Yeo, and Scott Hudson, Carnegie Mellon

But what about spinners?

Meh.

Spinners aren't versatile

< ~1s? Don 't indicate loading.
> ~2s? Really need a progress bar.
Only useful between 1 and 2 seconds.

Real progress bars
can be overkill.

Most progress bars are fake.

Many are pretty 💩y.

Adaptive loading

Keep it real…ish.

Measure requests.

						
const API_EXPECTED_TIME = 1000;
const SOME_OTHER_EXPECTED_TIME = 2000;

function getImage() {
	let t0 = performance.now();
	fetch(`${GET_IMAGE_API_URL}`).then(response => {
		const apiRoundtrip = performance.now() - t0;
		setPerformanceScalar(apiRoundtrip, API_EXPECTED_TIME);
		// Do stuff
	});
}

function setPerformanceScalar(observed, expected) {
	this.performanceScalar = observed / expected;
	// ...
	// tuck this away in app state, local storage, a global variable, etc
}

//...

So what's going on here is we record the time that an api request starts, and then on the response we use performance.now to take another high resulotion timestamp. We then save it, setting a performance scalar that is the observed time divided by the expected time. So if we expected this request to be 1 second, and it took only half a second, the performance scalar for the next progress bar would be 0.5, making the animation duration go twice as fast. We can use that to modulate progress bar durations and all sorts of other stuff.
Gives you a very basic idea about what a client's connection speed is.
You can normalize this with the size of a postbody as well if you need to.
You can use this information to set your loading scheme for the next request.
This is a super simple example, you could also use something much more fancy, liek the resource timing api, but this is sufficient just to drive fake loading indicators, and is still a very powerful tool.

Some tips

Set baseline times with your test runner.
Normalize for resource or payload.
Adapt your whole loading scheme.

Occupy Users'
Attention

Reticulating splines.

We can learn from gamedevs.

If this feels like cheating,
that's because it is.

You dirty cheaters, you.

Predictive
Preloading

React as soon as
users signal intent.

What if we could
predict their intent?

Gamedevs do this all the time.

You may have done it
without realizing.

Login form

Predictive form demo:

We predict that if a user fills out all the fields, they want to move to the next step. This demo will load the second step of the form after the user has inputted text into all the form fields. Note that we wouldn't be sending their data to the server when they fill input fields, we'll still wait for a click to do that (don't want to transmit data that is then revised). BUT in the real world we'd still use this as an opportunity to load the assets necessary to render the next step in the form.

To be clear, this is not for pre-emptively sending a server data that a user hasn't finished entering, it's for loading resources you need for the next page

In my testing I was able to accomplish about 50% of the loading process before users even clicked "Next step", which is a huge gain.

~4+ second head start!

CTA Button

Exploiting behavioral quirks

People tend to watch hover & active animations.
People necessarily slow their cursor as it approaches a target.

People watch hovers.

Fancy hovers buy you
up to 600ms extra.

Cursors slow down.

Perceived Performance

The only kind that really matters.

Hi, I'm Eli.

I like to make things on the internet

Today I'll be howling about

Why Perceived Performance Matters

Web Performance is a matter of time.

Time is a funny thing.

Objective time vs. Subjective time

We've gotten INSANELY good at objective performance.

HTTP/2

Service workers

Code minification

Image optimization

Critical Rendering Path

Tree shaking

Code splitting

Lazyloading

Edge node caching

SVG spritesheets

We optimize for objective time.

What if users don't notice?

Just Noticeable Difference.

Objective Time differences of 20% or less are imperceptible.

Shoot for 30% speedup.

We don't live inside of a web performance blog post.

Don't chase diminishing returns.

Focus on the subjective. Better 💥 for 🤑.

How Humans Sense Time

Active phase vs. Passive phase

Humans tend to overestimate passive time by 36%.

Takes about ~1 second to transition to a passive state

How do we use this

Keep users active

Key for short durations.

What we can do

Resist loading indicators

Woah. Woah. Woah.

Slow down here.

Don't use loaders?

But perceived perf?

Loaders tell users that they have to wait.

Adding a loader prematurely puts them in a passive state.

As waits approach ~1 second, start to use loaders.

Immediate Feedback

Immediacy keeps users from entering a passive state.

Stay :active, kids!

Optimism! Optimism! Optimism!

Better Event Listeners

Takes ~1 second to enter a passive state.

React as soon as the user signals intent.

Mousedown gives you a 100-150ms head start.

:active animations buy you more time

~200ms duration gives you a +50ms bonus

Works on touch devices too!

Begin on touchstart.

Cancel on touchmove.

Un-suck passive waits

You start to lose people at ~1-4s of waiting.

Critical to get this right.

What we can do

The Perfect Progress Bar

Uncertain waits feel longer.

Progress bars give users certainty.

Animation makes a difference.

Bars with accelerating bands feel 12% faster.

But what about spinners?

Meh.

Spinners aren't versatile

Real progress bars can be overkill.

Most progress bars are fake.

Many are pretty 💩y.

Adaptive loading

Keep it real…ish.

Measure requests.

Some tips

Occupy Users' Attention

Reticulating splines.

We can learn from gamedevs.

If this feels like cheating, that's because it is.

Why Perceived
Performance Matters

Web Performance
is a matter of time.

Objective time
vs.
Subjective time

Focus on the subjective.
Better 💥 for 🤑.

How Humans
Sense Time

Active phase
vs.
Passive phase

Resist loading
indicators

Loaders tell users
that they have to wait.

Adding a loader prematurely
puts them in a passive state.

As waits approach ~1 second,
start to use loaders.

Immediate
Feedback

Optimism!

Optimism!

Optimism!

Better Event
Listeners

Takes ~1 second to
enter a passive state.

React as soon as
the user signals intent.

Mousedown gives you a
100-150ms head start.

:active animations
buy you more time

You start to lose people
at ~1-4s of waiting.

The Perfect
Progress Bar

Progress bars give
users certainty.

Bars with accelerating
bands feel 12% faster.

Real progress bars
can be overkill.

Occupy Users'
Attention

If this feels like cheating,
that's because it is.

Predictive
Preloading

React as soon as
users signal intent.

What if we could
predict their intent?

You may have done it
without realizing.

Fancy hovers buy you
up to 600ms extra.

Detect decelleration
with Futurelink!

Elaborate Hover + Futurelink
At least ~1.5 second head start!

Perceived perf is
low hanging fruit.

Tailor your solution
to individual users.

Introduce predictive preloading
bit by bit.