What makes an app feel fast

Two apps can do the same work in the same time and feel completely different. One responds the instant your finger lands. The other sits there, then catches up all at once. The stopwatch says they're equal. Nobody experiences them that way.

Perceived speed is a design problem more than an engineering one, and most of it comes down to a handful of decisions.

The first 100 milliseconds decide everything

There's a threshold, well established in interface research, at around a tenth of a second. Respond inside it and the reaction feels caused by the touch. Miss it and the two events separate: first the tap, then, some time later, the result.

This is why a button that changes state immediately feels fast even when the work behind it takes a second and a half. The screen has acknowledged you. Everything after that is waiting, and waiting is tolerable. What isn't tolerable is uncertainty about whether the tap registered at all, which is exactly what a screen that does nothing for 300ms communicates.

So the ripple, the press state, the slight scale change — these aren't decoration. They're the app saying yes, heard you, before it knows the answer.

Animation duration is where most apps lose

The common mistake isn't too little animation, it's too much duration.

A transition around 200 to 300 milliseconds reads as smooth. Push it past 400 and it starts to feel like the app is deliberating. At 500 you've built a delay and called it polish. The animation looks lovely the first time. It's an obstacle the two-hundredth time, and the two-hundredth time is the one that matters, because that's the relationship people actually have with an app they keep.

A useful rule: small movements should be quicker than large ones. A checkbox ticking needs about 100ms. A full-screen transition can take 300. Applying one duration everywhere is what makes an interface feel either twitchy or sluggish, depending which number you picked.

Motion that can be interrupted also helps enormously. If someone taps again mid-transition, the app should follow the finger, not finish its animation first. Interfaces that insist on completing what they started feel bureaucratic.

Spinners advertise waiting

A spinner is a way of saying "something is happening and I can't tell you what or for how long". Sometimes that's the honest answer. Usually there's a better one.

If the wait is under about a second, show nothing. A spinner that flashes up and vanishes reads as a stutter, and it draws attention to a delay nobody would otherwise have noticed. Let the content arrive.

If the wait is longer and you know the shape of what's coming, draw that shape. A list of empty rows tells the eye where things will be, and the page then fills in rather than replacing itself. The total time is identical. The experience isn't, because the layout stopped being a question halfway through.

If you know how far along you are, show that instead. A progress bar that moves is worth five spinners.

Don't wait for the round trip

When an action almost always succeeds, show the result immediately and reconcile afterwards. Tapping a favourite should fill the star at once. Deleting a row should remove it at once. If the write fails, put it back and say so, which is rare and cheap to handle.

The alternative — disable the control, spin, wait, then update — makes every action cost the length of a network call, and it makes an app feel slow in exactly the moments when it's doing the least interesting work.

Cold start is the impression that sticks

The first launch of the day is the one people judge. An app that opens to a blank white rectangle for 800 milliseconds has already lost, whatever happens next.

Two things help more than any amount of optimisation elsewhere. Make sure your launch background matches the first screen, so the gap before your interface appears looks like the app rather than a hole. And don't do work at startup that isn't needed for the first frame — analytics setup, preference loading, database migrations, all of it can wait until after something is on screen.

Where the real time goes

None of this excuses genuinely slow code, and there's a point where perception can't paper over the gap. Two things are worth measuring before anything else: work on the main thread, and layout done more than once per frame. Everything else is usually noise by comparison.

But the ordering matters. A well-optimised app with a 450ms transition on every screen feels slower than a mediocre one that answers instantly and animates in 200. Users don't experience your frame times. They experience the delay between doing something and seeing something.

The test

Use your app one-handed, on a mid-range phone, on a bad day, doing the thing you built it for. Not the demo path. The boring one you'll repeat a hundred times.

If any part of it makes you wait without telling you why, that's where the work is.