Silent refresh in the background, with a change hint, beats forcing a wait

What it is

Paint the cache first; do not pin people on a spinner while it validates. Ask the server in the background. If nothing changed, the mark becomes confirmed, and people need not even know a request happened. If something changed, then hint — a light “update available”, a new row in the list, a conflict note — rather than swapping the whole page into a wait and yanking the words being read. The path is often called stale-while-revalidate: use stale, validate behind, speak only on change. It beats “wait for latest on every open”, because latest is often identical to the copy already on screen, and the wait is empty.

Why it happens

Forced wait assumes every open must see the server’s bytes in the first frame. For objects that rarely change, that assumption buys zero new information and pays a stretch of blank. Silent refresh lifts “confirm still true” off the presentation critical path: presentation walks the cache, confirmation walks the background. Confirmation forks. Unchanged: the world matches what is being read; only drop or refresh the freshness mark to “just confirmed”. Changed: the copy in use has to be corrected. If correction replaces silently, the sentence being read, the form being filled, the button being aimed at change owner under the eyes — rougher than having waited a moment at the start. A hint turns correction into an acceptable update, not a hijack.

Hint dose follows kind of change. One more row can insert and be briefly pointed at. A field being edited that changed remotely must stop and speak conflict, not overwrite in silence. Dose too high (every field flashing) turns refresh itself into noise; people start ignoring hints, which equals no hint.

Where it stops holding

Safety- and time-critical data must not paint stale then silence — the fourth leaf bans that path as default. When people explicitly want latest (pull to refresh, open a statement), the wait is requested; silence would hide this confirmation. If background refresh fails, keep stale plus mark plus a nearby retry; do not yank already-painted content into a whole-page failure because refresh failed. On a form being typed, a silent successful field replace swallows keystrokes; those blocks must be excluded from automatic replace. Energy and bandwidth still apply: silence is not free. Pages opened often should throttle validation.

Applying it

• Opening a page that may be stale: paint cache, validate in the background; unchanged, update freshness; changed, hint locally then replace. No whole-page spinner.
• Fields being edited or focused: on remote change, speak conflict. Do not overwrite input.
• Explicit “want latest” (pull to refresh) waits for latest, and does not go silent.
• How to check: open a list that will be changed on the server while someone is reading. The right path is the list appearing first, then an “update” line or a new row, reading position held. If it spins first, or the words silently become another version under the eyes, this path is not beating a forced wait.

Related

• Same group: I2.12.1 Cache speeds presentation but risks disagreeing with the server · I2.12.2 Stale content needs a readable freshness mark; it is not the same as latest · I2.12.4 Safety- or time-critical data must not default to a stale cache
• Nearby: I2.07 Perceived performance · I3.04 Sync conflicts · I4.07 Freshness levels and consistency expectations
• Search terms: stale-while-revalidate · silent refresh · update available hint