The slow website manifesto
Fast is not always good. An argument for intentional slowness as a feature.
26 articles
I care a great deal about performance. I also think the industry has confused two different things: how quickly a page becomes usable, and how quickly a person moves through it.
The distinction
The first should be as fast as physics allows. The second is a design decision, and optimising it without asking is how you end up with interfaces that hurry people through choices they should have made slowly.
A page that loads in eighty milliseconds and is read for four seconds has not saved anyone any time.
Two different clocks
Time-to-interactive is an engineering metric and it should be ruthlessly minimised. Time-on-task is a design metric and minimising it by default is a category error.
Nobody ships a product to help people spend less time reading. They ship it hoping people will read. Yet the entire measurement apparatus is oriented around reducing the second number, because it is easier to measure than whether anything was understood.
Where friction earns its place
- Before anything irreversible — deletion, publication, payment
- Where a choice has consequences the person cannot see yet
- At the end of a long piece, where a pause invites a response
- Anywhere the fast path would be a mistake most of the time
Note that none of these are about loading. They are about pacing, which is a different lever entirely and one that mostly gets pulled by accident.
The honest version of the argument
I am not arguing for slow software. I am arguing that speed is instrumental, and we have started treating it as terminal. A page that loads instantly and pushes someone through a decision they regret has optimised the wrong number to four decimal places.
The measure I would rather have: did the person get what they came for, and would they come back. Both are harder to instrument, which is precisely why the industry optimises the ones that are not.