Sub-100ms Micro-Interactions: Designing for Instant Feedback
What can happen in under 100ms, why the first frame matters, and how to design micro-interactions that feel instant without hiding real latency.
Core Takeaway
Under 100ms, the goal is confirmation, not choreography. Start the visual response in the same frame as the input, keep the first change small and obvious, and use optimistic UI only when you can roll it back. A short spring or an instant state change beats a 300ms animation when the user is waiting for the interface to acknowledge them.
Why 100ms matters
Nielsen Norman Group's classic response-time limits put about 0.1 seconds in the instantaneous range: the user feels that the system reacted, not that they waited. About 1 second keeps the flow of thought, and about 10 seconds is where attention starts to drift. For a button press or a toggle, the first visible change should land in that first range. A delayed start feels like a dropped input even if the animation is beautiful.
What can happen in 100ms
You cannot tell a story in 100ms, but you can confirm a tap. A scale change, a colour shift, a pressed state, a checkmark appearing or a row highlighting are all readable. The mistake is trying to fit a full enter-and-settle sequence into the same window. Do the acknowledgement immediately, then let the longer transition continue if it has more to say.
- Pressed state: scale, colour or elevation change
- Selection: highlight or indicator movement
- Toggle: thumb position and track colour
- Input: focus ring and caret response
- Optimistic action: the item appears in the list immediately
Start on the first frame
The first frame of the response should be triggered by the input event, not by a timer or a network callback. If you wait for a request before showing anything, the interface appears dead. Show the pressed state immediately, then move to loading if the action takes longer. This is a state machine concern: pressed, loading and success are different states, and the first one should not wait for the last.
Optimistic UI has a cost
Optimistic UI shows the result before the server confirms it. It feels instant, but it needs a rollback path for failure. If the action can fail in a way the user must understand, show the optimistic state and a clear recovery if it does not stick. Do not use optimism for irreversible or high-stakes actions where a false success is worse than a short wait.
When to slow down
Not every interaction should be instant. A destructive action may need a confirmation. A long-running task needs progress, not a fake completion. A success moment can be celebrated briefly if the user is not waiting to continue. The 100ms target is for acknowledgement, not for the whole experience.
How to measure it
Record the interaction at a high frame rate and count the frames between input and the first visible change. Test on a mid-range phone, not only on a desktop. Check the main thread: a long task before the state update will delay the first paint even if the animation code is fast. The number that matters is the time to first visible feedback, not the duration of the animation.
Key Principles to Remember
- About 100ms is the range where a response feels instantaneous
- Under 100ms, confirm the input; do not try to tell a full story
- Trigger the first visual change from the input event, not a network callback
- Use optimistic UI only when you can roll it back
- Measure time to first visible feedback on a mid-range device
Frequently Asked Questions
Sources
- Response Times: The 3 Important Limits — Nielsen Norman Group
- The Role of Animation and Motion in UX — Nielsen Norman Group
- RAIL performance model — web.dev