Tags: ux web-dev concept

Loading and Perceived Performance

Date: 2026-08-17


How fast something feels, as distinct from how fast it is. Perception can be improved without touching the underlying speed — and that’s a legitimate tool, not a trick, because the experience is what the person actually has.


Perceived performance is the user’s sense of responsiveness. It correlates with measured performance and diverges from it in ways you can design for.

Actual performance is the foundation — no amount of perception work rescues a genuinely slow site — Core Web Vitals, The Critical Rendering Path.

The thresholds

~0.1s   instantaneous
        → no indicator

~1s     noticeable, thought unbroken
        → keep it responsive

~10s    attention lost
        → progress + estimate

>10s    they leave or act again

The 1–10 second band is where design earns its keep, because that’s where something is happening and nothing says so — Feedback and System Status.

Techniques that change perception

IMMEDIATE ACKNOWLEDGEMENT
  respond to the tap in <100ms, even
  if the work takes longer
  → the button state changes instantly

SKELETON SCREENS
  show the SHAPE of what's coming
  → feels faster than a spinner
  → and prevents layout shift
  — Cumulative Layout Shift

OPTIMISTIC UI
  show the result before confirmation
  → for cheap, reversible, near-certain
    actions only

PROGRESSIVE RENDERING
  show what's ready, fill the rest
  → text before images

PREFETCH ON INTENT
  hover or touchstart on a link →
  start fetching
  → the navigation feels instant

BACKGROUNDING
  let them keep working while
  something completes

See: Cumulative Layout Shift

Skeletons beat spinners when the result’s shape is known: they set the layout, communicate what’s coming, and read as progress rather than as waiting.

Where the shape is unknown, a spinner is honest — a skeleton that doesn’t match what arrives is worse than none.

Progress indicators

DETERMINATE      a real percentage
  → use whenever you can compute one

INDETERMINATE    a spinner
  → only when you genuinely can't

FAKE PROGRESS    a bar that isn't
                 measuring anything
  → acceptable ONLY if it never
    stalls or reverses. A bar that
    sits at 90% is worse than no bar

Progress that accelerates towards the end feels faster than linear progress covering the same duration — a real effect, and one that stays honest as long as the completion is real.

Where perceived performance work is illegitimate

The line is straightforward:

LegitimateNot
Making the wait feel shorterPretending the work finished
Showing partial results earlyShowing fake results
Optimistic UI with visible rollbackOptimistic UI that silently hides failure
Progress that reflects real workA bar timed to a guess, that stalls

Silent rollback is the one to watch. An optimistic add-to-basket that fails and quietly reverts leaves someone believing they have an item they don’t — discovered at checkout — Feedback and System Status.

The commercial case

Perceived and actual performance both move revenue, and the mechanisms differ:

ACTUAL SPEED     fewer abandonments
                 before anything renders
                 → Performance and Conversion

PERCEIVED SPEED  fewer abandonments
                 DURING an interaction
                 → the 3-second wait after
                   "Place order"

See: Performance and Conversion

The second is cheaper to fix and rarely measured. Time-to-interactive gets attention; the responsiveness of individual actions after load usually doesn’t — Interaction to Next Paint.

Accessibility

ANNOUNCE loading states
  aria-live, or aria-busy on the
  region — Screen Readers

RESPECT prefers-reduced-motion
  spinners and skeleton shimmer are
  motion — Reduced Motion

DON'T MOVE FOCUS unexpectedly
  when content arrives
  — Focus Management

See: Screen Readers · Reduced Motion · Focus Management

A silently-updating region is invisible to a screen reader user, who has no way to know whether the site is working or broken.

Measuring it

INP                      responsiveness to
                         interaction
LCP                      when the main
                         content appears
TIME TO FIRST FEEDBACK   from tap to any
                         visible change
                         ← the one that
                           matters here,
                           and rarely
                           instrumented
ABANDONMENT DURING       people leaving
PENDING ACTIONS          mid-request

Instrument time-to-first-feedback on your primary actions — add to basket, apply filter, place order. It’s the number this whole note is about, and it’s usually absent from the dashboard.