Polling vs full page reload for live dashboards

Polling updates a slice of data. A full page reload rebuilds the whole tab from the server.

Live dashboards often mix both ideas in one sentence — “keep this board fresh” — but the mechanisms are different. Auto Refresh Turbo schedules a full tab reload with Chrome alarms and tabs.reload. It does not ship a custom API poller for every vendor board.

What polling usually means

In app code, polling is a loop that asks an endpoint for new rows, metrics, or status JSON, then patches the DOM. The URL stays the same. Layout, auth cookies, and client-side state often survive. Done well, it feels smooth and cheap on bandwidth.

Polling only works when the page already exposes that loop — or when you control the frontend. Many ops walls, ticket queues, and vendor status pages do not give you a clean public poll API from the browser toolbar.

What a full page reload does

A full reload asks Chrome to fetch the document again and re-run scripts. You see whatever a diligent human would see after pressing Refresh. Stale shells, stuck tiles, and half-broken SPA caches often clear because the document is new.

The tradeoff is visible: a brief flash, re-fetch of assets (unless cache helps), and loss of in-page draft state. That is why optional stop-on-click/type exists — so a reload does not hit mid-edit.

When reload is the right tool

The board is a third-party page you cannot patch
Live tiles stop updating until someone refreshes by hand
You need one interval that works across many unrelated sites
You care more about “looks correct on the wall” than micro-optimizing JSON calls

For that class of job, see also auto-refresh for dashboards.

When polling (inside the app) wins

The product already streams or polls correctly
A full reload logs you out or resets filters you need
Sub-second updates matter and a reload would thrash the UI

If the page is already live, lengthening or removing a scheduled reload is often better than fighting the site.

How Auto Refresh Turbo fits

The extension’s core loop lives in the service worker: you set an interval (or random min–max), press Start, and alarms fire tabs.reload for that tab. Sessions are independent per tab. Settings stay in local chrome.storage.

Optional on-page tools (visual timer, stop on interaction, suspicious-page heuristic) use a content script when enabled. They do not turn the extension into a generic XHR poller.

Practical hybrid

Many teams leave the app’s own refresh alone and add a slower full reload as a safety net — for example a 5–15 minute hard refresh if tiles look stuck after long idle time. Start gentle; tighten only when you prove a need.

Confirm whether the board already live-updates
If it goes stale, try a 30–60 second normal reload on a dedicated tab
Add a daily schedule so nights stay quiet
Use hard refresh only when cache keeps an old shell

Rate limits and challenges

Aggressive reload can look like abusive traffic. If you see captchas or errors, back off. Read rate limits and timed reload before you push sub-minute intervals on fragile endpoints.

Try it

Install Auto Refresh Turbo, then follow Start in about two minutes.