Speed as a form of respect
What loading metrics actually measure, what they miss, and why a fast site can still feel slow.
Speed is discussed as a technical property. In practice it is a form of attitude: how much of a person's time the product considers normal to take, and how honestly it says so.
What the metrics measure
The source states
The Web Vitals set describes three different events: largest element paint, interaction response delay and accumulated layout shifts. That is not one property called "fast" but three independent characteristics.
| Metric | What it records | What a person experiences |
|---|---|---|
| LCP | Largest element paint | "The page appeared" |
| INP | Response delay after an action | "I was heard" |
| CLS | Layout shifts after paint | "Nothing jumps under my finger" |
A practical consequence follows: a page can show good paint numbers and still irritate because it answers a tap late. And the other way round — a page with heavy first paint feels composed if it reacts instantly.
What the metrics miss
None of the metrics measures the time the interface adds by itself: the transition between screens, the pause before a tooltip, the reveal animation. That time does not count as "loading" but is experienced exactly as waiting.
Interpretation
We assume the gap between numbers and feeling comes from this added layer. It is designed by a designer; it does not arrive from the network.
Where animation helps
Motion works when it explains a relation: where an element came from, where it went, what changed. It stops working when it becomes a mandatory pause between intent and result.
- Response to an action — instant, with no entrance animation.
- Context change — a short transition that shows the link between screens.
- Secondary content appearing — animation is fine, because nobody is waiting for it.
Opposing view
There is a fair objection: a short animation masks an unavoidable delay and lowers irritation. It holds when the delay is genuinely unavoidable. More often animation is added on top of a result that is already there.
An interface does not have to be fast. It has to be honest about how much longer the wait is.
How we check this
The method is simple and repeatable — you can apply it to your own project in one evening.
- Pick the three actions a person performs most often: open, send, switch.
- Record the screen and count the frames from the tap to the first change on screen.
- Separately count the frames until the screen is actually usable.
- Repeat with animations disabled and compare both intervals.
The difference between the two measurements is the layer design added. If it exceeds the first interval, the animation has stopped explaining and started delaying.
Unverified
We give no threshold values: we have no sample on which to establish them. Naming specific milliseconds here would pass a feeling off as a measurement.
What to do about it
We separate two intervals and look at them apart: time to first visual response to an action, and time to screen readiness. The first governs the feeling, the second the metric. Both need work, but the first comes first.
Editorial conclusion
A fast interface answers immediately and says honestly how much longer the wait is. Cutting total time without that produces numbers, not a feeling.
Hypothesis
If the delay to first response drops below the threshold of noticeability, total load time stops affecting speed judgement within reasonable bounds. Under test.
Sources and notes
Links lead to the authors’ own materials. QVORIX publishes original texts, summaries and analysis; third-party materials are not republished in full.
About the author
QVORIX editorial
Collective author of the studio