Perceived Performance

You shaved your p95 query from 400ms to 90ms, code-split the bundle, added an index, and the app still feels sluggish to everyone who isn't you. You're staring at the network tab where the numbers got better. They're staring at a screen that sat frozen for half a second and then snapped. Same milliseconds, opposite verdicts.

Here is the thing most engineers refuse to internalize: speed is not a number, it's an experience. The user never sees your p95. They see whether the button reacted, whether the screen looked alive while it waited, whether the thing they clicked seemed to acknowledge them or ignored them like a busted elevator call. You can win the benchmark and lose the feeling, and the feeling is what they pay for. The most expensive mistake in this whole chapter is optimizing only the part you can measure and ignoring the part the user actually judges you on.

The trap: a faster backend behind a frozen screen

Picture the typical case. The user clicks "Generate report." Your handler is genuinely quick. But the UI does this: the click registers somewhere, nothing visible happens for 600ms, then a tiny centered spinner appears, spins for 300ms, and the report pops in. Total wall-clock: under a second. Reported feeling: "it hangs."

What went wrong is not the server. Three things went wrong in the interface, and all three are free to fix:

• The click had no immediate acknowledgment. For 600ms the user couldn't tell if it registered.
• The wait was a void — a spinner is a shrug, it tells you nothing is happening that you can understand.
• The arrival was a jolt — content slammed in and shifted the layout, which reads as instability, not speed.

A spinner is the interface equivalent of "I don't know, hold on." It conveys that the system is busy and conveys nothing else — not how long, not what's coming, not even reliably that your action is the reason it's busy. Drop a bare centered spinner on a fast operation and you've taken a 700ms task and made it feel like a 3-second one, because uncertainty stretches time. Anxious waiting always feels longer than informed waiting.

This is where developers go wrong: they treat latency as a single quantity to minimize, when the user experiences it as a sequence of moments to be managed. The first moment — did it hear me? — matters more than the total.

POA is not permission to ship a slow backend. Actual speed still sets the ceiling on how good perception can get, and at some point no amount of choreography rescues a five-second wait. But between "instant" and "obviously broken" there is an enormous range, and inside that range the design of the wait decides everything. Two apps with identical response times can land on opposite sides of "feels professional," and the difference is entirely in how they spend the wait.

Instant feedback: acknowledge inside 100ms

There's a rough hierarchy of human time perception that's worth committing to memory because it converts directly into rules:

• Under ~100ms feels instantaneous. The reaction seems caused by your action.
• Up to ~1 second feels like a connected delay — you stay in flow, but you notice the wait.
• Past ~1 second your attention starts to drift; you need to be reassured the system is still working.
• Past ~10 seconds you've mentally left, and the task needs to hold its place for your return.

The single highest-leverage rule lives at the top: every interaction gets a visible response within 100ms, even if that response is only "I heard you." The acknowledgment does not have to be the result. It almost never can be the result. It just has to prove the system is alive and your input landed.

Acknowledgment is cheap. A button that's been clicked should change immediately: depress it, dim it, swap its label, show an inline spinner inside it. The point is that the pixel under the cursor reacts before the network does anything.

function SaveButton({ onSave }) {
  const [state, setState] = useState("idle");
  async function handleClick() {
    setState("saving");           // visible in the same frame as the click
    try {
      await onSave();
      setState("saved");          // brief confirmation, then settle back
      setTimeout(() => setState("idle"), 1200);
    } catch {
      setState("error");
    }
  }
  return (
    <button onClick={handleClick} disabled={state === "saving"}>
      {state === "saving" ? "Saving…" : state === "saved" ? "Saved ✓" : "Save"}
    </button>
  );
}

That setState("saving") paints in the same frame as the click. The user sees the label flip to "Saving…" instantly, and the actual save can take 300ms or 800ms — it no longer matters as much, because the interaction already felt responsive.

The same principle covers the small stuff that developers skip. Hover states must respond on hover, not after a transition delay. A :active style on every clickable thing gives a free tactile "press." Inputs should echo keystrokes with zero perceptible lag — never block the main thread on keypress to do validation or filtering; debounce the work and let the character appear now.

There's a subtler footgun: the 100ms budget is a budget for the main thread, not just the server. If your click handler synchronously runs an expensive filter, re-renders ten thousand rows, or parses a giant JSON blob before yielding, the screen freezes and no acknowledgment paints — your spinner can't even spin because the thread is blocked. Acknowledge first, yield to the browser, then do the heavy work. Order matters as much as speed.

Skeletons over spinners: show the shape of what's coming

Once you've acknowledged the click, you still have a gap to fill while data loads. The instinct is a spinner. The better answer is almost always a skeleton: a gray-block placeholder in the exact shape of the content that's about to arrive.

A spinner says "something is happening." A skeleton says "this specific thing is happening, and here's roughly what you'll get." It previews the layout, which means the page already looks like itself before the data lands, and when the data does land it fills predrawn slots instead of shoving the layout around.

This is the same instinct as The Four States Rule — every data view needs an empty, loading, error, and ideal state — applied to the loading state with care. The loading state is not a throwaway. It's a designed screen that happens to be missing its data. Treated that way, it does real work: it sets expectations, holds the layout, and shortens perceived wait by giving the eye structure to read.

A skeleton is not hard to build. It's the real layout with text and images replaced by neutral blocks and a slow shimmer to signal "live, not frozen."

.skeleton {
  background: linear-gradient(90deg, #eee 25%, #f5f5f5 37%, #eee 63%);
  background-size: 400% 100%;
  animation: shimmer 1.4s ease infinite;
  border-radius: 6px;
}
@keyframes shimmer {
  0%   { background-position: 100% 0; }
  100% { background-position: 0 0; }
}

function CardSkeleton() {
  return (
    <div className="card">
      <div className="skeleton" style={{ height: 120 }} />
      <div className="skeleton" style={{ height: 18, width: "70%", marginTop: 12 }} />
      <div className="skeleton" style={{ height: 14, width: "40%", marginTop: 8 }} />
    </div>
  );
}

Two rules make skeletons feel right instead of cheap. First, match the real dimensions — if the loaded card is 120px tall, the skeleton block is 120px tall, so nothing shifts when data arrives. A skeleton that's the wrong size just relocates your layout-shift problem. Second, don't over-detail it. A few gray blocks suggesting the structure is enough; a pixel-perfect ghost of every element looks uncanny and draws attention to the wait. Suggest the shape, don't render the corpse.

There's a threshold worth respecting. For a load you expect to resolve under ~300ms, showing a skeleton at all can backfire — it flashes in and out and reads as a flicker, which feels less stable than just letting the content appear. Reserve skeletons for waits long enough that an empty screen would otherwise read as broken, roughly 300ms and up. Below that, the fastest-feeling thing is often nothing at all, then the content.

Optimistic UI: assume success, reconcile later

The fastest possible feedback is no wait at all — show the result of the action immediately, before the server confirms it, on the bet that it'll succeed. This is optimistic UI, and for the right actions it's the single biggest perceived-speed win available, because it takes the network latency to zero in the user's experience.

The pattern: when the user acts, update local state right away as if it succeeded, fire the request in the background, and only do something visible if it fails — at which point you roll the change back and tell them. The like-button toggles instantly. The to-do checks off instantly. The renamed item shows its new name instantly. The request is still in flight; the user has already moved on.

function useToggleLike(post) {
  const [liked, setLiked] = useState(post.liked);
  async function toggle() {
    const prev = liked;
    setLiked(!prev);                         // optimistic: update now
    try {
      await api.setLike(post.id, !prev);
    } catch {
      setLiked(prev);                        // reconcile: roll back on failure
      toast("Couldn't update — try again");
    }
  }
  return { liked, toggle };
}

The judgment call is when this is safe and when it isn't, and the line is sharper than it looks.

Optimistic UI is safe when the action almost always succeeds, the cost of a rare rollback is low, and rolling back is honest. Toggling a like, checking a checkbox, reordering a list, renaming a thing, adding an item to a visible collection — these fail rarely, and when they do, snapping the state back with a small "couldn't save" message is a fine recovery. The user loses nothing but a second.

It is not safe when the outcome is consequential, irreversible, or genuinely uncertain. Do not show a payment as succeeded before it clears. Do not show "Email sent" before the send is accepted. Do not optimistically render the result of an operation whose answer you can't predict — a server-side calculation, an availability check, a unique-username claim. Lying optimistically about money, deletion, or anything the user would act on is far worse than an honest wait. The recovery — "actually, that didn't happen" — is more jarring than the spinner you were trying to avoid, and it costs you trust, which is exactly the Competence Tax you're supposed to be paying down, not running up.

Two implementation notes save pain. Keep the pre-change value so rollback is exact, not a refetch — the snippet above stashes prev. And when the real response arrives, reconcile to the server's truth rather than trusting your guess forever; the server may have normalized something, and if you never reconcile, optimistic state drifts out of sync with reality over a long session.

Designing the longer waits

Some waits are genuinely long — a report that takes four seconds, an upload, an export, a cold serverless function. You can't fake those to zero. You design them so the time passes well and, where possible, so the user never hits the wait at all.

Show determinate progress when you can. A progress bar that actually moves beats a spinner badly, because a bar that's at 70% promises an end. Even a coarse, stepped progress — "Fetching data… Rendering… Almost done" — feels faster than an opaque spinner, because each step is a small arrival that resets the user's patience. Indeterminate spinners feel longest of all; give the eye something that advances.

Prefetch the likely next view. The fastest load is one that already happened. If a user is hovering a link, parked on a list, or one step from a predictable next screen, start fetching that screen's data before they ask. Most frameworks and routers give you prefetch on hover or on viewport entry almost for free.

<Link
  to={`/invoices/${invoice.id}`}
  onMouseEnter={() => queryClient.prefetchQuery(
    ["invoice", invoice.id],
    () => fetchInvoice(invoice.id)
  )}
>
  {invoice.number}
</Link>

The ~200ms between hover and click is usually enough to have the data in cache by the time the navigation fires, so the destination renders instantly. The wait still happened — it just happened during a moment the user wasn't watching.

Serve stale, then revalidate. When a user returns to data they've seen, show the cached version immediately and refresh it in the background, swapping in fresh data when it lands. The screen is never empty and never blocks; "stale-while-revalidate" is the whole idea. It's the right default for any view where slightly-old data for a few hundred milliseconds is harmless, which is most read-heavy views — dashboards especially. This is part of how a dashboard manages to Answer the First Question in one glance: the answer is on screen instantly from cache, then quietly corrected if needed, instead of making the user watch it load every visit.

Mask latency with transitions. A short, intentional animation can cover a load and turn a jarring swap into a smooth one — a 150ms fade or slide as content arrives reads as "polished," not "slow," and it hides the exact moment of data arrival so there's no jolt. Two cautions. Keep transitions in the 150–250ms range; longer than that and the animation itself becomes the wait you were trying to hide. And never animate to deliberately stall — a fake 2-second "processing" theater to make a free action feel weighty insults the user the moment they notice.

Put these together and you have a layered defense against the feeling of slowness: acknowledge in 100ms, fill the gap with structure not a void, take latency to zero optimistically where it's safe, and for the irreducible waits, show progress, prefetch ahead, serve stale, and smooth the seams. None of it requires a faster backend. All of it changes the verdict.

What to do Monday morning