3 Things To Make Your App Feel Fast

Note: The three prompts are on this page. Open your app's repo in Claude Code, paste one at a time, and make each one show you what it found before it changes anything.

You spent weeks finding the first people who would actually try your app. Don't lose them in the four seconds it takes to open.

None of these three make your app faster. They change when the user sees something, and that's the part they feel. Jakob Nielsen wrote the numbers down in 1993 and they haven't moved: under 0.1 seconds reads as instant, one second is about how long you get before someone notices they're waiting, and by ten seconds their attention is gone.

Run them in order. The first one is usually the biggest jump.

1. Cache your data

Most apps go and fetch the same thing every single time you open a screen. Cache it and the screen paints from what you already have, then updates quietly behind it.

Find every screen in my app that refetches the same data each time it opens.
Cache those responses so the screen paints from saved data first and refreshes
in the background. List the screens you changed and what each one used to wait
on.

2. Use optimistic UI

Someone taps a heart, and the app just sits there waiting for a server in Virginia to say yes. It's going to say yes. Show it now, send the request after.

Go through every action where the user waits on the server before the screen
moves: saves, toggles, adds, deletes. Update the UI right away and send the
request in the background. If it fails, put the old state back and show the
error. Tell me any you skipped.

The rollback matters more than it sounds like it does. Skip it and a failed save looks exactly like a successful one, which is worse than being slow.

3. Skeleton loading

A spinner tells someone to wait. A skeleton tells them what's coming, in the shape it's coming in, so nothing jumps around when the real thing lands.

Replace every spinner and blank loading screen in my app with a skeleton shaped
like the real content of that screen, so nothing jumps when it loads. Render the
light parts first and stream the heavy ones in after. Show me each screen before
and after.

Notes on the three

The response time limits are Jakob Nielsen's, from chapter 5 of Usability Engineering (1993), and NN/g still publishes them: 0.1 seconds feels instantaneous, 1 second keeps your flow of thought uninterrupted, 10 seconds is the limit for holding attention at all. The three response time limits

If you're on React, the first two prompts mostly land on TanStack Query, which does cache-then-revalidate by default, and useOptimistic, which shipped in React 19. Name the library you're already using in the prompt (I do) or it will pick one for you.

One honest caveat on skeletons, because you'll see people state this as settled: it isn't. Bill Chung tested skeleton screens against a spinner and a blank screen and found skeletons were perceived as shorter, but not by much, and a 2017 Viget study he cites had skeletons coming last. What moved his numbers more was the animation — a slow left-to-right shimmer beat a pulse. I still default to skeletons because they hold the layout still, which is a separate win from perceived speed. Everything you need to know about skeleton screens

And if your app is genuinely slow, a 3MB image on the home screen or a query with no index, none of this saves you. This makes a fast app feel instant. It makes a slow app feel like a slow app with a nicer loading state.