You can pass every Core Web Vitals threshold and still hear “the site feels slow”. Speed as measured and speed as experienced are different things, and the gap between them is design, not engineering. Users do not perceive milliseconds. They perceive waiting without information, movement that blocks them, and interfaces that do not answer when touched.
The response budget people actually feel
Human tolerance for delay has well established thresholds, and they have not changed since they were first documented in the 1960s.
Under about 100 milliseconds feels instant: the response seems caused by your finger. Up to around one second keeps flow intact, though the delay is noticeable. Beyond that, attention starts to drift, and by ten seconds people leave or switch tasks.
The practical implication is that the most important interval in your entire product is the first 100 milliseconds after an interaction. Something must acknowledge the tap immediately, even if the real work takes two seconds. A button that visibly depresses, then shows a loading state, feels faster than a button that does nothing for 400 milliseconds and then succeeds instantly.
Skeletons beat spinners, and both beat nothing
A spinner communicates “something is happening” and nothing else. It has no shape, no progress, and no end, so time spent watching one feels longer than it is.
A skeleton screen, the grey outline of the content that is coming, does more work: it shows the layout arriving, tells the eye where to look, and gives the brain something to parse while it waits. It also prevents the layout jump that happens when content lands, which is the same instinct behind reserving space for images and embeds.
Use skeletons for content that has a predictable shape (lists, cards, dashboards, tables). Use a spinner only for short, indeterminate waits inside a small area, like a button. Use a progress bar whenever you genuinely know the percentage, because a determinate wait is tolerated far longer than an indeterminate one. And below roughly 300 milliseconds, show nothing at all: a loading state that flashes and vanishes reads as a glitch.
Optimistic updates: assume it worked
The single biggest perceived speed win in modern products is refusing to wait for the server before updating the interface.
When someone renames a project, ticks a checkbox, or sends a message, show the new state immediately and reconcile in the background. Nearly all of those requests succeed, so nearly all users get an interface that responds at the speed of their own hands. Handle the rare failure honestly: revert the change, say what happened, and offer a retry, which is exactly what a well designed error state is for.
Be careful where the stakes are high. Payments, deletions, and anything irreversible should show real confirmation rather than an optimistic guess, particularly in products handling money.
Load what people are about to need
Perceived speed is often just work done earlier.
Prefetch the page behind a link when the pointer hovers or when the link enters the viewport, so the next navigation is already in memory. Prioritise the content people see first and defer the rest, which is most of what a static first architecture buys you. Serve correctly sized, modern format images, since the hero image is the usual culprit behind a slow feeling first impression. Cache aggressively, and make returning to a previous page instant rather than a fresh download.
The order matters as much as the total. A page that paints its headline in 400 milliseconds and finishes at 2 seconds feels dramatically faster than one that shows nothing for 1.4 seconds and then completes at 1.5.
Motion sets the tempo
Transitions can make a fast interface feel slow. Anything longer than roughly 300 milliseconds on a routine action starts to feel like waiting, and repeated hundreds of times a day it becomes the defining texture of the product.
Keep functional motion short, use easing that starts fast, and never make an animation block input. Save the longer, expressive moments for places where they carry meaning rather than for every state change, which is the line between motion that helps and motion that hurts. Respect reduced motion preferences too, both for accessibility and because some people simply find it faster without.
Test on the device your users actually have
Perceived performance dies on mid range Android phones and hotel wifi, not on the developer’s laptop. Throttle the connection, throttle the CPU, and click through the real flows.
Then watch a person use it. They will hesitate exactly where the interface fails to acknowledge them, and those moments never show up in a metric. That habit is why the dashboards we ship get their loading states designed alongside their populated ones, and it is the same discipline that keeps a marketing site feeling immediate on a mid range phone.
Want to know why your site feels slower than it scores? hello@beconfidency.agency.
If you want performance owned properly rather than patched, that is exactly what our SEO and performance service is for.