Loading States and Perceived Speed — Why Feedback Matters More Than Milliseconds

Short answer: an action that takes two seconds with immediate feedback feels faster than one that takes one second with none. If a user clicks and sees nothing, they assume it failed and click again. Acknowledge every action instantly, show the shape of what is loading, and tell the user what is happening on longer waits. Find the gaps by looking for repeated clicks on the same control.

Table of Contents

1. Actual Speed and Perceived Speed
2. How Long Is Too Long
3. Types of Loading State
4. Finding Frozen Moments
5. Common Mistakes
6. Key Takeaways

Actual Speed and Perceived Speed

Actual speed is measured in milliseconds. Perceived speed is the user's experience of waiting, and it depends on whether they can tell something is happening.

Uncertainty makes a wait feel longer. A blank screen with no sign of progress prompts the question "is it broken?" within a second or two. The same wait with a clear indication of progress is tolerated.

You should still make things faster. But feedback is often cheaper to add than real speed, and both matter.

How Long Is Too Long

Widely used rules of thumb:

Responsiveness is what the INP metric measures: the time from an interaction to the next visual update (what INP is). A visible change within a fraction of a second is the target.

Types of Loading State

Skeleton screens show grey placeholders in the shape of the content. They signal that the page is on its way and reduce layout shift, since the space is already reserved.

Optimistic updates show the result at once and confirm with the server afterwards. A "like" that fills in immediately feels instant. Use it where failure is rare and reversible.

Finding Frozen Moments

Slow, silent interactions leave a clear trace: the user repeats the action.

1. Rage clicks. Bursts on one button usually mean no feedback was given (how they are detected).
2. Repeated submits, sometimes producing duplicate records.
3. Recordings. Watch for a click followed by stillness, then another click.
4. The network timeline in a recording shows how long the request really took.
5. Real-user INP by page, on mobile (performance).
6. Abandonment during a wait. Sessions that end while a request is pending.

In DeepSync, session rows show rage-click counts, Highlights jump to those moments, and replays include the network timeline, so you can see the click, the slow request, and the second click together.

Common Mistakes

• No feedback on click. The single most common cause of duplicate submissions.
• A spinner over the entire page for a small update.
• Spinner with no end. A request failed and nothing handles it. Always have a timeout and an error state.
• Skeletons that do not match the content, causing a jump when it arrives.
• Flashing loaders. A spinner shown for a tenth of a second is distracting. Delay showing it slightly.
• Blocking the interface while something loads that the user does not need yet.
• Fake progress bars that race to 90% and wait.
• Losing the user's place when content finishes loading.
• Testing only on fast connections. Throttle the network and try again.

Key Takeaways

• Feedback makes waiting tolerable; silence makes it feel broken.
• Acknowledge every action immediately.
• Match the loading pattern to the length and type of wait.
• Repeated clicks reveal where feedback is missing.

Conclusion

Users forgive a short wait they understand. They do not forgive a click that seems to do nothing. Make sure your product always answers.

Start free with DeepSync.