What Makes Software Feel Fast

Here is a thing that took me embarrassingly long to accept: a piece of software can win every benchmark you throw at it and still feel like wading through mud. And its clumsier cousin, the one with worse numbers on paper, can feel like it reads your mind.

Speed and the feeling of speed are two different things. They overlap, but they are not the same, and the gap between them is where most of the interesting work lives.

I think about this a lot because our whole job is building things people use, and "it feels slow" is a complaint you cannot answer with a spreadsheet. Nobody times your app with a stopwatch. They form an impression in the first second and carry it with them, fairly or not. So the real question is not "how fast is it" but "how fast does it feel, and to whom, and when."

The clock in someone's head

People do not measure time in milliseconds. They measure it in attention.

A wait feels long when you are staring at nothing, unsure whether the thing is working or broken. It feels short when something is happening, when you can see progress, when the machine has clearly heard you. Two waits of the exact same length can feel completely different depending on what fills them. This is old knowledge, honestly. It is why good elevators have mirrors by the doors and why a progress bar that moves feels faster than a spinner that just spins, even when the spinner finishes first.

The single most important trick is instant feedback. When someone taps a button, something must change within a breath, well under a tenth of a second. Not the finished result, just an acknowledgment. The button presses in. A row highlights. A tiny spinner appears exactly where the action was. The point is to close the loop between "I did something" and "the software noticed" before doubt has time to form. Miss that window and the person taps again, wondering if it registered, and now you have two problems.

This is also why the classic advice about website speed still matters, because the underlying page has to be light enough to react at all. I wrote more about that side of it in why slow sites quietly cost you sales. But raw load time is only half the story. A fast page that freezes for 300 milliseconds every time you tap it feels slower than a heavier page that answers every touch instantly. Responsiveness beats throughput in the felt experience, almost every time.

Getting ahead of the wait

Once you accept that the goal is the feeling, a few techniques stop looking like hacks and start looking like manners.

Optimistic UI is the big one. When someone sends a message, you show it in the thread immediately, styled as sent, and quietly confirm with the server in the background. You are betting the action will succeed, because it almost always does, and you spend the network delay behaving as if it already worked. If it fails, you roll it back and say so. The bet pays off constantly. This is how the good chat apps feel instant even on a train with two bars of signal: they are not faster on the wire, they just stopped making you wait to see your own words.

Skeletons are the other one, and they are easy to get wrong. A skeleton screen, those grey placeholder shapes that stand in for content while it loads, works because it tells an honest story about what is coming. Done right, the grey blocks are the same size and in the same place as the real content, so when the data arrives it simply fills in and nothing moves. Done wrong, you get a generic shimmer that looks nothing like the final layout, everything jumps when it loads, and you have added a flash of fake content on top of the real wait. A skeleton is a promise about the shape of the page. Keep the promise.

Then there is the quiet stuff you can do before the person even asks. Prefetch the next page when their cursor drifts toward a link. Load the data for a screen while they are still reading the one before it. Cache the things they just looked at so going back is instant. None of this is glamorous, and much of it depends on rendering choices further down the stack, which is part of why I keep coming back to server-side rendering, as I argued in the quiet return of server-side rendering. The work is invisible when it goes well. That is the whole idea.

The jank tax

Now the thing that undoes all of it: layout shift.

You have felt this. You go to tap a link and an ad loads above it, the whole page lurches down, and your thumb lands on the wrong thing. Or you are reading and an image finally decides to appear and shoves the paragraph you were on off the screen. Every one of these little jumps is a small betrayal. It says the software does not have its act together, and no benchmark score will save you from how bad it feels.

Most of it is preventable and none of it is clever:

• Reserve space for images and embeds before they load, so nothing has to move when they arrive.
• Do not inject banners, cookie bars, or promos above content that is already on screen.
• Load fonts in a way that does not cause a jarring reflow when the real typeface swaps in.

That is basically the list. It is unglamorous, it rarely makes a demo look impressive, and skipping it is the fastest way to make an otherwise quick app feel cheap.

There is a small philosophy underneath all of this, and I will just say it plainly. Someone's time and attention are not free resources for you to spend. Every spinner you show, every layout jump you allow, every extra tap you require is a tiny withdrawal from a person who chose to use your thing. Fast software, the kind that actually feels fast, is mostly just software built by people who took that seriously. It anticipates. It acknowledges. It holds still when you are trying to read. It gets out of the way.

The irony is that chasing benchmark numbers and chasing the feeling usually lead you to the same good habits: lighter pages, fewer scripts, sane rendering, careful loading. But you get there faster, and you make better calls along the way, if you remember what you are actually optimizing for. Not the clock on the wall. The one running in someone's head.

If you have a site or app that tests fine but somehow feels sluggish, that gap is exactly the kind of thing we like to hunt down. Tell us about it on our booking page and we will give you a straight read on where the time, real and felt, is going.