Waiting is not a natural user experience.
It is an active one, and an unpleasant one, which is why the difference between a page arriving in one second and four is not four times worse but something closer to categorically different.
Understanding website speed and user experience means understanding perception rather than only measurement. The stopwatch and the visitor disagree more often than performance writing admits.
Website Speed and User Experience: What Evidence Shows
Uncertain waits feel longer than known ones
This is the most useful finding to carry into web work.
A progress bar showing genuine progress is easier to tolerate than a blank screen of identical duration, because the blank screen provides no information about whether anything is happening or how long it will continue. That’s a poor user experience (UX).
The practical consequence is that showing something early beats showing everything at once. A page rendering its heading and first paragraph immediately, then filling in imagery, feels responsive while still loading. One that waits for completeness feels broken for the same number of seconds.
This is why render-blocking resources matter disproportionately. A stylesheet or script that must download and parse before anything displays converts a partial wait into a total one.
Attention spans have a short leash
There is a rough threshold, somewhere around a tenth of a second, below which a response feels instantaneous, and another around one second below which a thought is not interrupted.
Beyond a few seconds, attention wanders and the person becomes aware they are waiting. Once they are aware, they start weighing whether to continue adding double to your user experience.
This is why unresponsiveness reads worse than slowness. A page that takes three seconds to load and then answers immediately feels better than one that appears in one second and ignores the first tap, because the second breaks the connection between action and result.
The effect on user experience, honestly stated
People leave slow pages. That is well established, and the size of the effect varies considerably by sector, device, and how motivated the visitor is.
Somebody comparing three suppliers behaves differently from somebody already decided and looking for a phone number. Published percentages describe particular studies of particular sites, and treating them as predictions for your site is where a lot of performance business cases go wrong.
The reliable statement is that reducing delay reduces abandonment, and that measuring your own before and after is the only way to know by how much.
Who bears the cost of a poor user experience?
Not evenly distributed, which is the part usually left out.
Somebody on a pay-as-you-go plan pays for your unused code in money. Somebody on a four-year-old phone waits longer because parsing and execution take longer. Somebody in an area with patchy coverage may not receive the page at all.
The visitors most affected are frequently the ones with the least margin, which is an argument for restraint that stands without needing any conversion statistic behind it.
Accessibility runs alongside
Predictable, stable pages help people using screen readers, people with cognitive differences and people with motor difficulties, for the same reason they help everybody: less unexpected change to the process.
Layout shift is worth singling out. Content moving while somebody is reading or reaching to tap is disorienting in general and genuinely disabling for some.
Work towards WCAG 2.1 Level AA on its own merits, and note the overlap rather than claiming one produces the other.
What follows practically
Get meaningful content on screen early rather than optimising for a total load time nobody perceives directly.
Acknowledge input immediately even when the underlying work is slow, since a control that responds feels functional while one that waits feels broken.
Reserve space for images and embeds so nothing moves as it arrives.
Test on a real mid-range device on mobile data, on a first visit with a cold cache. Where performance and environmental impact both apply, treat them as the same lever: reducing unnecessary data transfer and processing supports a faster experience while lowering estimated digital carbon, though environmental figures remain modelled rather than directly measured.
Our sustainable web development work measures perceived website speed alongside total page weight, since the two diverge.