My notes on Ilya Grigorik’s talk (@igrigorik)
What follows are my notes from watching Ilya’s presentation:
“Performance” means many different things to different people full-stack perf is complicated is there such a thing as “fast enough”? context matters: — 10fps matters in games, 10fps matters much less in ecommerce Devs often forget about the wetware running their ui’s (human brain) Joked about it using some sort of IE6
Task Oriented Reaction Times:
intent > action > response
Delay — User Reaction 1-100ms — Instant 100-300ms — slight perceptible delay 300-1000ms Task focus, perceptible delay 1s+ mental context switch 10s+ I’ll come back later…
Visual and audio processing have different perceptive resolutions:
- 24fps (~40ms) — minimum stutter-free FPS
- 60fps (~16ms) — silky smooth experience
- 1ms+ jitter — Audible sound discontinuity
Perceived perf equation:
Perceived performance = f(Expected Performance, UX, Actual Performance)
the UX is the glue between expectations and silicon
Performance is not just milliseconds, frames, and megabytes. It’s also how these milliseconds, frames, and megabytes translate to HOW THE USER PERCEIVES THE APPLICATION.
Who’s responsible for perf of UX layer? everyone.
Hacker news case study:
- Hacker news is fast due to its simplicity, renders reliably in under 500ms.
- Experience actually sucks on mobile. Takes a few seconds to realize the page is loaded and text is too small, then zoom in, then swiper to read the headlines.
- actual time to complete task is around 5-10s, and I hate it.
- fulfills technical aspects, but fails on completing task in a performant manner.
Finally, as a community, we have moved past the onload time.
- What are the primary use tasks for your application?
- What is the time to task completion? What is the expected time to task completion?
- determine primary core tasks you want user to achieve. measure the time it takes for them to be available, and how long it takes to complete them.
Blogger case study:
- creating a new blog was almost instant, it returned almost immediately.
- Users expected important things to take a little bit of time. task was a big commitment.
- users thought experience was broken because it returned too fast. had low user satisfaction.
- Simple fix: add a spinner on a page that does absolutely nothing, and user satisfaction went up.
- The user/wetware expectation was different from the ui result, so satisfaction is low.
phpMyAdmin case study:
- because the db queries take different, inconsistent amounts of time, the feedback was inconsistent.
- You must give users feedback, and also feedback to inform their expectations.
- if something will take a long time, let them know.
- give feedback in metrics, units that are very clear to intended users, ie seconds, minutes instead of gigabytes for consumers.
Perceived Performance = f(Expected Performance, UX, Actual Performance)
Experience = f(Perceived Performance, Task Completion)
- What is the task the user is trying to achieve?
What does the wetwear between our ears expect?
- What is the technical performance of the components required to fulfill the task?
Megabytes, milliseconds, frames?
- How can we design the app to best connect perceived and actual performance? Did it succeed in helping me complete the task?
- Developers: learn about the wetwear (user brain). Think about the user tasks. < performance is when these two meet in the middle>
- Designers: learn about the technical and wetwear (user brain) constraints, design for task completion.