Order Dashboard in a Background Tab: Pause Polling, Resume With a Freshness Check
The situation
Imagine a small bakery, invented for this example, that takes pre-orders through its own website. The owner keeps an order dashboard open on a shared laptop. It asks the server for new orders every 15 seconds. Most of the day the tab sits behind a spreadsheet or a browser window for suppliers. Nobody is looking at it, yet it keeps asking.
The operational question is not how to make polling faster. It is what the dashboard should do when nobody can see it, and how it proves its data is current when someone looks again.
What the platform documents
MDN describes the Page Visibility API as sending a visibilitychange event when the user minimizes the window, switches tabs, or the page is fully covered by another window. The page can read document.hidden and document.visibilityState, which reports visible or hidden. MDN lists a dashboard that does not want to poll the server while the page is not visible as a use case for this API.
MDN also says browsers typically apply their own background policies. Timers such as setTimeout are throttled in background tabs, and budget-based throttling exists in Firefox and Chrome. Tabs using WebSockets or WebRTC, playing audio, or running IndexedDB work are described as exempt. MDN notes that blur and focus events tell you a window lost focus, not that the page is hidden.
Recommended decision (engineering judgment)
The following are recommendations, not documented behavior.
- Treat hidden as "nobody can see this right now," nothing more. Visible does not prove a person is attending, and hidden does not prove they left. Do not log it as employee presence or use it for any staff measurement.
- On hidden, stop the polling timer and cancel any request in flight that you can safely cancel.
- Never rely on a background timer to deliver an order alert. If missed orders matter, the bakery needs a channel that does not depend on a browser tab, such as an email or phone notification, decided separately.
- On visible, immediately request fresh data once, then restart the regular timer.
- Show a clear "last updated" time and a manual refresh button so the owner can judge freshness without trusting the page.
Freshness check on return
When the tab becomes visible, show the previous list marked as possibly outdated until the first response arrives. Ask the server for orders changed since the last successful sync, using a server-provided timestamp or sequence number rather than the laptop clock, which may drift. If the server reports a gap, such as a very old marker, reload the full list instead of merging.
Failure handling
- Refresh fails on return: keep the old list, label it stale, retry with growing delays, and show the last successful time.
- Responses arrive out of order: ignore any response older than the one already applied.
- Two tabs are open: each pauses and resumes on its own. Accept duplicate requests, or let the server tolerate repeats, instead of coordinating tabs.
- Visibility events are unavailable or unreliable on a particular device: fall back to a modest polling interval and the manual button.
- Order actions such as marking an order ready should be validated server side against current state, so a stale screen cannot overwrite newer changes.
Proposed acceptance checklist (not performed)
None of these checks has been run. They are proposed for whoever implements this.
- Polling stops when the tab is moved to the background and when the window is minimized.
- Exactly one immediate refresh occurs when the tab returns, followed by normal polling.
- The stale label appears until the first fresh response and disappears afterward.
- A simulated network failure on return leaves the old list visible with an accurate last updated time.
- A late, older response never replaces a newer one.
- Marking an order from a stale screen is rejected or reconciled by the server.
- No presence or attention data is stored.
- Behavior is reviewed on the browsers the shop actually uses, since background throttling details vary.