Update rate should match how fast the content actually changes
Aliases: update cadence · refresh rhythm · source bandwidth · freshness cadence
What it is
Once the channel is chosen, there is still the question of how often the interface should chase the facts. Matching update rate to change rate means the refresh beat follows how the content actually moves, not how fast the stack can go. Material that changes on an hourly scale, refreshed every second, is a realtime performance. A match that changes on a hundred-millisecond scale, asked every ten seconds, is playing deaf. The channel is the means; matching is the policy.
Why it happens
Content has its own temporal structure. Chat arrives in clusters with long silences; a price is dense in the open session and still after the close; “someone else is editing” is true only while someone is moving. One uniform high frequency covering all of that spends redraws and requests on silent periods, and may still lag the peaks. Matching means sampling density follows the source’s bandwidth: quiet source, quiet UI; dense source, dense UI — with a ceiling so events cannot flood paint.
Mismatch fails in two directions, and they feel different. Too dense: numbers or lists change before they have been read; attention is captured by refresh itself; battery and traffic drain with no gain. Too sparse: people, given the content type, already expect change, and the UI is still on the old frame, so they pull to refresh. Manual refresh is a symptom of matching failure, not a feature.
Where it stops holding
Regions on the same screen can have different change rates (a conversation stream versus a sidebar headcount) and must not share one frequency; the sidebar can be sparser. Change rate jumps with phase (open / close, match start / end); a fixed match is immediately wrong after the jump, and should follow the source’s state machine. If every refresh causes a screen reader to re-read a whole region, a dense match becomes unusable; coalesce changes before announcing. Compliance and audit sometimes want a snapshot at a moment, not “latest”; matching latest would break that product constraint.
Applying it
- For each content type, write the source’s typical change interval and the UI’s acceptable delay. Those two should line up — not “we have push, so always latest”.
- Lower or pause refresh in silent periods; raise it when the source peaks, with a coalescing window on paint so not every event triggers layout.
- Treat “only pull-to-refresh yields new content” as a matching-failure signal: check whether the rate is below the source before checking whether the channel is down.
- How to check: in a period when the source barely moves, requests and redraws should be nearly quiet. When the source densifies, UI lag should stay inside budget, and a screen reader should not be drowned by per-event refresh. Raise the rate far above the source — people should start complaining of flicker. Drop it far below — frequent manual refresh should appear.