20 Oct 26 
Real speed and felt speed are different problems. Here is how loading states, instant feedback, and skeleton screens make a site feel faster than the numbers alone would suggest.
UX
Last month I sat with a founder who was convinced his app was slow. We opened the network tab together and the numbers were fine. The data came back in a few hundred milliseconds, the server was quick, the payload was small. By every metric I usually care about, the thing was fast. But when he clicked around, it felt sluggish, and he was right. The problem was not the speed. It was that the screen did nothing for half a second after each click. No spinner, no change, no acknowledgment. Just a pause where the old screen sat frozen while the new one loaded in silence. People do not experience milliseconds. They experience whether the thing responded to them, and his app was staying mute at exactly the moment it needed to say something.
Real speed and felt speed are two different problems
I have spent a lot of time on the engineering side of performance, and I will keep doing it, because it matters. If you want the measurable version of that work, I have written about fixing a failing LCP and the real revenue cost of a slow page. But there is a second track running alongside the first, and most teams only invest in one of them. Real speed is how long the work actually takes. Felt speed is how long the person thinks it took. They are related, but they are not the same number, and you can win on one while losing on the other.
The uncomfortable truth is that felt speed is often the one that decides whether someone trusts your product. A page that loads in a second but shows nothing for that whole second feels broken. A page that loads in two seconds but reacts instantly, shows a shape of what is coming, and fills in as it goes, feels alive. The second one is objectively slower and subjectively faster, and subjective is what people act on. So the question is not only how do I make this faster. It is also how do I make the wait feel shorter than it is.
Acknowledge the click before you do anything else
The single cheapest win in all of this is the immediate response to an action. When someone clicks, something has to change within about a hundred milliseconds, or their brain registers a lag. It does not have to be the finished result. It can be a button that dims, a spinner that appears, a row that greys out, a subtle shift that says yes, I heard you, I am working on it. What kills the feeling of speed is silence. Silence after a click reads as either a dead interface or a mistake the person made, and both of those push them to click again, which makes everything worse.
This is really a question of feedback, and it connects to the same principle I lean on when I write about reducing cognitive load. An interface that keeps the person informed about what is happening asks less of them. They do not have to wonder, guess, or re-click. The system is carrying the uncertainty instead of handing it to the user. A good loading state is you taking that weight off their shoulders for the second or two it takes to catch up.
Skeletons beat spinners when you know the shape
For anything that takes longer than a flash, the kind of waiting indicator you choose matters. A spinner is honest but empty. It tells the person to wait without telling them what they are waiting for, and a spinner that runs too long starts to feel like a stall. A skeleton screen, the grey outline of the content that is about to appear, does something smarter. It shows the layout before the data arrives, so the page feels like it is already there and merely filling in. The person reads it as progress rather than delay, because the structure is visible and only the detail is missing.
The reason this works is partly psychological and partly practical, and I dug into the trade-off between the two indicators in skeleton screens versus spinners. Psychologically, a wait with a visible endpoint feels shorter than a wait into nothing. Practically, the layout stops jumping around, because you reserved the space before the content landed. That steadiness keeps people moving toward the action instead of flinching at every reflow, which is the same reason real page speed shows up in conversion numbers.
Design the wait, do not just allow it
The mistake I see most often is treating loading as an absence, a gap you tolerate until the real screen shows up. It is not an absence. It is a state your product is in, sometimes for a meaningful slice of every session, and it deserves to be designed like any other. Decide what the person sees in the first hundred milliseconds. Decide what they see at one second, and at three if it ever gets that far. Give slow operations a sense of motion and progress. Make failures honest and recoverable rather than leaving someone stuck watching a spinner that will never stop.
None of this replaces the hard engineering work of actually being fast. But the two multiply. Make the product genuinely quick, then design the small moments of waiting so they feel quicker still, and you end up with something that feels effortless to use. Effortless is what people remember, and it is what they tell other people about. Speed you can measure. The feeling of speed you have to build on purpose.