What Is the Background Sync API?
Learn how the Background Sync API retries failed requests via a Service Worker once connectivity returns, with a code example.
Expected Interview Answer
The Background Sync API lets a web app register a deferred task with a Service Worker so that a failed or offline action, like submitting a form, automatically retries in the background once the device regains connectivity, even if the page itself has since been closed.
A page calls `registration.sync.register(tag)` on its Service Worker registration to schedule a one-off sync tagged with a name. The browser then fires a `sync` event inside the Service Worker as soon as connectivity is available, which may be immediately or much later, and the Service Worker’s `event.waitUntil()` handler performs the actual retry logic, such as re-sending a queued POST request from IndexedDB. Crucially, this happens independent of whether the originating tab is still open, because the Service Worker runs in its own lifecycle separate from any page. If the sync attempt fails again, the browser automatically retries with backoff, and only clears the registration once it succeeds or the app explicitly gives up. Support is uneven — Safari does not implement the one-off Background Sync API — so many production apps pair it with an `online` event listener and manual retry as a fallback for unsupported browsers.
- Guarantees a retry attempt without the user needing to keep the tab open
- Removes the need for aggressive client-side polling to detect reconnection
- Works even if the original page is closed, since the Service Worker owns the retry
- Integrates naturally with offline-first write queues stored in IndexedDB
AI Mentor Explanation
The Background Sync API is like handing a scorecard correction to the ground staff with instructions to post it to the official league system the moment the stadium’s network link comes back, even if you’ve already left the ground. You don’t have to stand there waiting for the connection — staff hold the correction and retry posting it in the background until it succeeds. If the first retry fails, they try again automatically rather than giving up. That register-now, retry-in-background-until-success pattern is exactly what the Background Sync API does for a failed request.
Step-by-Step Explanation
Step 1
Register a sync tag
The page calls `navigator.serviceWorker.ready.then(reg => reg.sync.register("sync-tag"))` after a failed or offline write.
Step 2
Browser waits for connectivity
The browser holds the registration and fires a `sync` event in the Service Worker once online, regardless of whether the tab is open.
Step 3
Service Worker retries the request
Inside `self.addEventListener("sync", event => event.waitUntil(retryQueuedRequests()))`, the queued write is re-sent.
Step 4
Automatic retry on failure
If the retry fails, the browser automatically schedules another attempt with backoff until it succeeds or the app cancels it.
What Interviewer Expects
- Understanding that Background Sync runs inside the Service Worker, independent of the page
- Ability to explain the register → sync event → waitUntil flow
- Awareness of automatic retry-with-backoff behavior on failure
- Knowledge of Safari’s lack of support and the need for a fallback
Common Mistakes
- Assuming Background Sync fires instantly rather than “as soon as the browser deems connectivity reliable”
- Forgetting the retry logic must live in the Service Worker, not the page
- Not providing a fallback (e.g., an `online` event listener) for browsers without support
- Confusing one-off Background Sync with the separate Periodic Background Sync API
Best Answer (HR Friendly)
“The Background Sync API lets an app say “try this again once you’re back online,” even if the user has already closed the tab. So if someone submits a form on a spotty connection, the browser quietly retries sending it in the background the moment the network is back, without the person having to do anything.”
Code Example
// In the page
async function submitOrder(order) {
try {
await fetch('/api/orders', { method: 'POST', body: JSON.stringify(order) })
} catch (err) {
await saveToOutbox(order)
const reg = await navigator.serviceWorker.ready
await reg.sync.register('sync-orders')
}
}
// In the Service Worker
self.addEventListener('sync', (event) => {
if (event.tag === 'sync-orders') {
event.waitUntil(retryQueuedOrders())
}
})
async function retryQueuedOrders() {
const orders = await getOutboxOrders()
for (const order of orders) {
await fetch('/api/orders', { method: 'POST', body: JSON.stringify(order) })
await removeFromOutbox(order.id)
}
}Follow-up Questions
- How does one-off Background Sync differ from Periodic Background Sync?
- What fallback would you build for browsers without Background Sync support?
- How would you avoid duplicate submissions if a sync retries a request that actually succeeded?
- How does Background Sync relate to offline-first write queues in IndexedDB?
MCQ Practice
1. Where does the actual retry logic for a Background Sync run?
The Service Worker receives the `sync` event and performs the retry inside `event.waitUntil()`.
2. What happens if a registered Background Sync’s retry attempt fails?
The browser keeps retrying with backoff until the sync succeeds or is explicitly abandoned.
3. Which major browser notably lacks support for the one-off Background Sync API?
Safari does not implement the one-off Background Sync API, requiring a fallback strategy.
Flash Cards
Where does Background Sync retry logic live? — Inside the Service Worker’s `sync` event handler.
How is a sync scheduled? — `registration.sync.register(tag)` from the page.
What happens if a page closes before sync fires? — The sync still fires later because the Service Worker is independent of the page.
Key browser gap? — Safari lacks one-off Background Sync API support.