Felt Speed Is an Honesty Problem: Perceived Performance
Nov 2026The three time limits, the surprisingly mixed research on skeleton screens, and why I think the real variable is whether the interface keeps its promises.
Why this is on my mind
"Add a skeleton screen" is advice I've given and received many times. Reading the actual research changed my mind about how confident that advice should be.
What's true right now
The time limits are old and still hold. Jakob Nielsen's response-time limits are 0.1 seconds (feels instantaneous), 1 second (the user notices but stays in flow), and 10 seconds (the edge of attention). Nielsen Norman Group still publishes them as three important limits in interaction design. The accompanying guidance is to show a progress indicator for anything over about a second, looped animations like spinners for roughly 2 to 10 seconds, and percent-done indicators beyond that, as summarized in a recent guide to skeleton screens.
The skeleton evidence is mixed. A widely cited test by Viget with 136 participants found people perceived the longest wait with a skeleton screen compared with a blank screen or a spinner, and were slowest to finish the task afterward. The authors concluded skeletons are not a silver bullet and should be used thoughtfully. A separate academic study (Mejtoft and colleagues, 2018) reported the opposite: pages with skeletons scored higher on perceived speed and ease of navigation. Practitioners have settled on a narrow window: roughly 1 to 10 seconds, on layouts whose shape you can reproduce exactly, with a short delay before painting so quick loads don't flash.
Optimistic UI is convention, not law. One research-backed UX reference is candid that no formal research validates optimistic UI; it's practitioner convention based on perceived-performance benefits.
What the mixed results suggest
If skeletons help in one study and hurt in another, the technique itself probably isn't the variable. My guess is the variable is match: does what the interface showed you during the wait resemble what actually arrived? A skeleton that mirrors the final layout promises something and delivers it. A generic gray bar promises structure and then delivers something else, and that mismatch reads as slowness.
A match check you could run today
Illustrative: my own sketch, not a sourced fact.
Overlay the two states. Take the waiting state and the arrived state of one screen and lay them over each other. Where the blocks line up, the wait was telling the truth. Where they do not, the wait promised something that was not delivered. It is a crude check, but it takes minutes and needs no participants. It is a blunt tool, and a screen can pass it and still feel slow for other reasons. I like it because it turns a vague argument into something you can point at.
Count the surprises. Each place where content jumps, resizes or appears where no placeholder was is a small broken promise. I would rather fix three of those than argue about whether to use a skeleton at all, because the argument tends to treat the technique as the variable. I would add one caution. Fixing the jumps by padding the skeleton with extra blocks can make it match worse, so the aim is accuracy, not more shapes.
Where I would not trust this reading
My opinion, based on the tradeoffs above.
It is a guess built on two studies. The match idea fits the conflicting results neatly, which is exactly why I am cautious. A story that explains everything after the fact has not yet been tested, and the studies may differ in ways I cannot see from their summaries. The research I read is a handful of studies with different setups, so I would treat my reading as a way to organise the questions, not as an answer.
Honesty may not be the only driver. Plain visual preference, the length of the wait, and what people were doing before could all matter. I would hold the honesty reading loosely until the three-way test is run, and I would be fine if it turned out to be one factor among several. If the three-way test turned out ambiguous, I would not be surprised. Real products mix all of these factors, and a clean result in one narrow task may not carry over.
My hypothesis
This section is my opinion, not a sourced fact.
Perceived performance is mostly a function of how honest the waiting state is, not how fast it is.
Concretely: feedback that accurately predicts the result shortens perceived waits. Feedback that misleads (a fake progress bar, a skeleton of the wrong shape, a spinner that hides that nothing is happening) lengthens them, even when the clock time is the same. That reframes the job. Instead of "how do we make this feel faster?", the question becomes "does this state tell the truth about what's coming?"
It also explains why AI products, where outputs are unpredictable in shape, struggle here: the interface often can't know what the result will look like, so a skeleton would be a guess.
How I'd test it
Run the same 3-second load with three treatments: an accurate skeleton, a mismatched skeleton, and a spinner. Measure perceived wait and task time. I'd expect the mismatched skeleton to lose to the spinner, which would support the honesty reading.
What would change my mind
If the accurate and mismatched skeletons perform the same, then match isn't the driver, and I'd go back to treating it as pure visual preference.
What I would do for AI outputs
My opinion, a sketch of an approach rather than a tested method.
If the shape is unknown, say so. When the interface cannot predict what the result will look like, a skeleton is a guess. A plain, honest state that says work is happening, and perhaps what kind, avoids promising a layout that may not arrive. That also means being willing to show less. A modest, truthful indicator may beat an impressive one that implies more knowledge than the system has.
Commit as soon as the shape is known. If the first part of a response reveals its structure, that is the moment to show the real layout, not before. The waiting state then moves from a general signal to an accurate one, and the user is never asked to trust a prediction the system could not make. It is the same logic as the rest of the post. The waiting state is a small promise, and the interface should only make the ones it can keep.
References
- Nielsen Norman Group, The 3 Response Time Limits in Interaction Design
- The Plus Addons, Skeleton Loading Screens: The CSS, And What The Research Actually Says
- Viget, A Bone to Pick with Skeleton Screens
- skills.cat, feedback-design (summary of sources including Mejtoft et al. 2018)