Why Fast Hardware Still Feels Slow

Your phone processes more data per second than a supercomputer from the 1990s. Your laptop is faster than the machines that ran entire corporations a generation ago. And yet these objectively extraordinary devices routinely feel slow: the progress bar stutters, the app takes a beat to open, the cursor lags a fraction behind your finger.

My British lilac cat, Pixel, has a cleaner relationship between intention and result than any of this. When she wants something, she moves, and the gap between wanting and acting is nothing at all. No loading screen, no animation to sit through. Her interface has zero latency, and it’s worth being precise about why ours doesn’t, because the reason isn’t really about the chip.

Three different things called “speed”

Hardware manufacturers mean operations per second: clock cycles, floating-point throughput, memory bandwidth, numbers that improve reliably every year. Software developers often mean algorithmic efficiency: getting the same result in fewer steps. Users mean something else again, the gap between an action and the visible result of that action, and that third meaning is the only one that determines whether something feels fast, because it’s the only one anybody actually experiences.

The disconnect is structural rather than accidental. A powerful chip running inefficient software over a slow network can feel worse than a modest chip running tight, local code, because perceived speed is a property of the whole chain, not any single link in it. Specifications describe a component. Experience reflects the system the component sits inside, and the gap between those two is where most of the frustration with “fast” hardware actually lives.

The chain is only as fast as its slowest link

Total latency is the sum of every delay between an action and its visible result. A single tap on a phone passes through touch sensing, touch processing, the operating system, the application itself, rendering, and the display’s own refresh and pixel response, and each of those adds its own delay on top of the last.

The cruel property of a chain like that is that the slowest link dominates regardless of how fast everything else is. A faster chip does nothing if the display refreshes slowly. A faster display does nothing if the network round-trip is the actual bottleneck. Modern software routes through dozens of these handoffs between components, and the aggregate easily crosses into territory a user experiences as a delay, even when most of the individual pieces are, by their own specifications, extremely fast.

No single spec sheet reports the total, because no single component owns it. The chip vendor reports chip numbers. The display vendor reports display numbers. Nobody reports the sum, which is the only number that was ever going to determine how the thing actually feels.

Animation is a deliberate delay wearing a design justification

Animations exist to make transitions feel smooth, and often they just make an interface feel slow instead, because a 300-millisecond transition adds exactly 300 milliseconds to every interaction that triggers it, on purpose, by design.

The justification holds up to a point: an instant, abrupt cut can feel jarring. But the threshold where a transition starts reading as a wait is lower than a lot of interface design assumes. Motion under roughly 100 milliseconds tends to read as instant; motion past 300 tends to read as something you’re waiting on, and a great deal of shipped interface design sits comfortably on the wrong side of that line without anyone having measured it against the line at all.

The effect becomes obvious the moment you compare the same task on two systems with different animation durations. Identical underlying performance, and the one with faster transitions reads as snappier, because duration, not computational power, is what’s actually being perceived. It’s also why power users reach for the “reduce motion” setting so often, not out of a stripped-down aesthetic preference but as a straightforward latency optimisation: removing a 300ms tax from every single interaction adds up to real time across a working day.

Your mental model is doing half the judging

People carry an internal expectation of how fast a given action should feel, built entirely from prior experience, and when reality falls short of that expectation, the result feels slow even when it’s objectively fine by any absolute measure.

Modern software regularly violates expectations set by older software. An app that opened instantly on a previous OS now takes a couple of seconds because complexity accumulated underneath it. A feature that used to respond locally now waits on a network round-trip because it moved to the cloud somewhere along the way, and the mental model never got the memo. The experience quietly regressed even while the hardware underneath it kept improving on paper.

Feature additions are a common invisible source of this: sync makes saving slower, analytics makes launching slower, verification makes logging in slower, and none of that shows up anywhere the user can see it coming. The mental model doesn’t include the addition, so the slowdown reads purely as the software getting worse, which, from the user’s seat, it kind of has.

The network is the part specifications can’t fix

Network dependency has become the dominant source of felt slowness, and no amount of local hardware speed compensates for it, because the two operate on entirely different orders of magnitude: local hardware latency lives in the single-digit-millisecond range, network latency lives in the tens or hundreds.

Modern apps touch the network constantly, for authentication, sync, feature flags, analytics, sometimes for things that look entirely local from the outside. And network latency is unpredictable in a way hardware latency isn’t: the same app can feel instant one moment and sluggish the next, purely on connection conditions nobody at the table controls, which makes the experience feel unreliable even when the average is genuinely good. There’s also a hard physical floor under all of this: light takes real, measurable time to cross real distance, and no amount of clever engineering gets around that for a user sitting far from the server they’re talking to.

Put simply: software has grown more network-dependent at roughly the same rate hardware has grown more powerful, and the two trends have been quietly cancelling each other out for years.

Somewhere around 100 milliseconds, “instant” ends

There’s a real threshold in human perception, somewhere around 100 milliseconds, below which a response reads as connected to the action that caused it, and above which it reads as a separate event with a gap in between.

Getting under that threshold is genuinely hard in a modern stack. Display refresh alone can eat ten to fifteen milliseconds. Touch processing adds another ten to twenty. The lightest possible application response adds ten to fifty more. A single network round-trip adds anywhere from fifty to several hundred. Add those up and most everyday interactions clear the threshold before the software has done anything wrong, purely by accumulation.

Meeting the threshold anyway takes real architectural choices: local-first processing instead of network-dependent processing, optimistic updates that show the expected result immediately while confirmation happens quietly in the background, content preloaded ahead of the moment it’s needed rather than fetched on demand. None of that is free, and none of it is the default, which is most of why so much software simply doesn’t clear the bar. And the threshold behaves as a hard cutoff rather than a gradient: being slightly over it and being far over it both just read as “a delay,” which means there’s limited value in shaving milliseconds off something that was already past the line to begin with.

A smoother frame rate is not the same as a faster response

Higher refresh rates make motion look better, and that’s a real, visible improvement. What they don’t necessarily do is meaningfully cut latency, because the actual reduction in delay from doubling a refresh rate is often single-digit milliseconds, nowhere near enough to move something across the 100ms line on its own.

The illusion runs in both directions. A smooth-looking interface gets rated as more responsive even when its measured latency is identical to a choppier one, and choppy motion at genuinely fine latency reads as slower than smooth motion at that same latency. Visual polish is doing real perceptual work here that has nothing to do with the actual number, which is exactly why refresh rate gets marketed so heavily: the improvement is real and easy to demonstrate, even when its effect on how “fast” something feels for a typical task is much smaller than the marketing implies.

Startup got heavier while chips got faster

Application launch time has crept upward even as the hardware running those applications has gotten dramatically faster, and the reason is almost entirely accumulated software weight rather than anything about the chip.

Starting up means loading code, loading data, initialising whatever frameworks sit underneath the app, opening connections, and finally rendering something. Every one of those steps got heavier over the last decade: more frameworks to initialise, more analytics connections to open before anything useful happens, more feature-flag checks that require a network round-trip before the interface can even decide what to show. Switching between several such applications across a workday means paying that tax repeatedly, and it adds up to real, felt time that a faster processor should, in principle, be eliminating and mostly isn’t, because the software got heavier at least as fast as the hardware got faster.

Everything running that you didn’t ask for

Modern devices run a constant undercurrent of background work: system services, sync, indexing, update checks, analytics, notifications, maintenance tasks, each one quietly claiming CPU time, memory, storage bandwidth, and battery.

Most of the time this stays invisible, right up until it collides with something you’re actually trying to do, and the powerful device stutters because a background index is eating disk bandwidth at the exact moment you needed it free. Every new capability a device gains tends to add its own slice of upkeep, and those slices accumulate faster than most people notice, until the sum of all that maintenance is quietly competing with the foreground task for the same limited resources.

Software got heavier faster than hardware got faster

This is the plainest version of the whole phenomenon: application size and complexity have grown dramatically, megabyte-scale tools became gigabyte-scale ones, and every added layer, a framework running on a runtime running on an operating system, adds its own overhead that was never free, whether hardware happened to be fast or slow that decade.

Frameworks that trade raw performance for developer speed, the Electron-style approach of running a browser to display what’s functionally a text editor, are a clean example of the trade being made deliberately: developer time is expensive, hardware is comparatively cheap, and optimising software to run lean on modest hardware costs real engineering hours that the economics usually don’t reward. The upshot is that a new machine often feels about as fast as the old one, despite genuinely better specifications, because the software running on it got correspondingly heavier at roughly the same pace.

What genuinely does feel fast

A few patterns reliably produce the feeling of speed, independent of raw specifications.

Native applications tend to feel quicker than web equivalents doing the same task, because there are fewer layers between the tap and the result. Local operations beat network ones almost every time a user can tell the difference, correctly, even without knowing why. Optimistic updates, showing the expected outcome immediately and reconciling in the background, buy the feeling of instant response without actually being instant underneath. Preloading content ahead of the moment it’s needed converts a network delay into something that was already sitting there waiting. And stripping animation out removes a source of delay that was never about computation to begin with, purely a design choice with a duration attached to it.

Where the responsibility actually sits

Perceived speed is mostly a design decision, not a hardware constraint, and every lever that determines it belongs to someone who could have chosen differently.

Animation duration is a designer’s choice, and a shorter one costs nothing in hardware terms. Network dependency is an architectural choice, and a local-first design reduces it without touching the chip. Framework and dependency weight is a developer’s choice, and a lighter alternative exists for most of the heavy ones in common use. Feature scope is a product choice, and a narrower product is very often a faster-feeling one. All four of these get decided, in most organisations, for reasons that have nothing to do with response time, aesthetics, convenience, developer productivity, competitive feature parity, and response time ends up an afterthought nobody explicitly chose to deprioritise. It just lost by default.

What’s actually in your control

Turning off animation helps immediately and is available on every major platform. Favouring native apps over web wrappers for the same task usually buys real latency. Closing unused background applications and trimming what syncs constantly frees resources for whatever you’re doing in the foreground. Favouring tools that work offline and sync later gives you consistency a constantly-online tool can’t promise. And, counterintuitively, an SSD upgrade often does more for a sluggish machine than a new processor does, because a lot of everyday slowness is storage-bound rather than compute-bound, which the spec sheet’s emphasis on processor speed tends to obscure entirely.

The honest expectation going forward

A few genuine trends point toward improvement: displays that adapt refresh timing to content rather than running flat-out regardless of need, more inference happening on-device rather than round-tripping to a server, runtimes getting closer to native performance for code that used to pay a heavy interpretation tax.

But the countervailing trend hasn’t stopped either. Software complexity keeps climbing, network dependency keeps expanding, and feature expectations keep growing to fill whatever headroom the hardware provides. The realistic future looks like small islands of genuinely instant interaction inside a much larger ocean of merely acceptable delay, some things crossing the 100ms line and staying there, most others not, with expectations adjusting quietly around the gap rather than the gap closing.

Pixel has no version of any of this to contend with. Her interactions with the physical world carry no perceptible latency, and her expectations are never violated by a delay she didn’t plan for, because her interface runs at the speed of physics rather than the speed of software. Ours runs at the speed of software, which is slower than physics allows and often slower than the spec sheet implies, and that gap will keep showing up in daily use for exactly as long as perceived speed stays a secondary concern behind the number printed on the box.