Optimising perception does not replace optimising the clock

What it is

Skeletons, progress and occupied waits can make the same clock interval judged shorter. They cannot turn four seconds into four hundred milliseconds, and they cannot turn a blocked main thread into an unblocked one. Perceived optimisation is a layer on top, not a substitute. Clock duration still decides: whether the instant window is missed, whether continuity of thought is punched through, whether people are forced to leave, whether occupied feedback itself becomes jank on a weak network or an old device. Changing the report to “users felt faster” with the clock unchanged is optimising testimony, not the wait.

Why it happens

The perceived ruler and the clock ruler drive different failures. The perceived ruler drives complaints and a reputation for “slow”. The clock ruler drives whether an action still binds as causation, whether a train of thought survives, whether a result lands before the attention ceiling. The second class does not vanish because the skeleton was drawn better: a 100 ms gap is still a gap; a ten-second job will still make people switch away. The clock also drives a physical ledger: radio time, battery, server occupancy, lock hold. If occupied feedback is built on heavier animation and decode, it can even stretch the clock — “felt slightly faster, actually slower”. That inversion amplifies on the next weaker device.

The perception layer can also be seen through. Fake progress, forever-99%, flickering indicators lower estimates for a while and then shut the trust channel. The clock layer has no room for that performance: milliseconds do not shrink because they are believed. So the two layers are governed in order: move the clock into the window first, then use perception on the stretch that is still long inside the window. The reverse is scenery over a house still being built.

Where it stops holding

When the clock is already inside the instant window, adding a perception layer becomes flicker; add nothing. When the clock is so long people must leave (background jobs), the perception target changes: leave, come back, notify on complete — not making thirty seconds “feel like eight”. Labs that use judged duration as the only metric will pick heavier animation; those picks make the clock worse on low-end hardware. Assistive tech and automation do not take the visual occupation path; they see clock and status text. Visual gains of the perception layer are zero for them, so substitution is even less tenable.

Applying it

• Set clock goals first: which actions must land inside the instant or continuity window. If they do not, cut bytes, cut blocking, split requests — do not lead with skeleton and progress.
• Stack the perception layer only on a clock that already passes, to handle the stretch past continuity but still inside the attention ceiling.
• Watch both curves: clock-duration distribution and post-hoc estimates. Estimates up, P95 down, is inversion — roll the perception layer back.
• How to check: turn off all wait chrome, leave the function. If core actions still fall out of the target window, no amount of perceived polish counts as done. Retest on a low-end device and a weak network to confirm the feedback itself did not stretch the clock.

Related

• Same group: I2.07.1 Perceived duration can diverge from clock duration · I2.07.2 A wait with feedback is perceived as shorter
• Nearby: I1.01 Instantaneity threshold · I1.02 Continuity-of-thought threshold · I1.03 Attention-holding ceiling
• Search terms: perceived versus actual performance · latency budget · progress as veneer