Browser support and limitations
The Background Synchronization API is supported by browsers including Chrome and Edge. Safari, including iOS, and Firefox currently support neither this API nor Periodic Background Sync. Both features require HTTPS and a registered service worker.
A closed page is different from a fully terminated browser. The browser decides whether and when a background event runs. Persist pending operations and provide a retry when the app is next opened.
Current compatibility data: Background Sync and Periodic Background Sync.
One-off Background Sync
The application first stores a pending operation, such as a message, locally. It registers a task through registration.sync.register(). A sync handler in the service worker can retry the transfer later. IndexedDB can hold the queue; a service worker does not create it automatically.
event.waitUntil() associates asynchronous work with the event. The browser still limits execution time and retries. It does not guarantee completion of long uploads, successful delivery or execution at a specific time.
Show users which operations are pending. Remove an operation from the queue only after confirmed success and avoid processing it twice on the server if a transfer is retried.
Periodic Background Sync
This separate API can refresh content in advance while a network connection is available. In Chrome, it requires a PWA that has been installed and launched as an app. Engagement, network conditions and power state affect whether and when an event runs. Safari on iOS currently does not support it.
Check registration.periodicSync and register a task with a unique name and minInterval. The minimum interval is not a schedule: neither a daily update nor a particular execution time is guaranteed. Without this API, refresh content when the app is opened.
See the Chrome documentation for Periodic Background Sync for requirements and registration details.
Checking support and permissions
Check the sync property on ServiceWorkerRegistration for one-off tasks and periodicSync for periodic tasks. BackgroundFetchManager belongs to a different API and does not indicate Background Sync support.
API support and permission are separate checks. Registration can be rejected; catch errors and use a fallback. In Chrome, check Periodic Background Sync permission with navigator.permissions.query() and the name periodic-background-sync. This does not imply a general consent prompt for every sync task.
Web Push has its own requirements and notification permission. Push support does not imply that Background Sync is available.
Offline content and pending operations
A cache stores selected resources for offline access. A queue stores user operations that have not reached the server. These are separate concerns: an app can work locally without a connection, but it cannot send data to a server while offline.
Account for storage limits and possible data deletion. Keep pending status visible and also synchronize when the app opens or a connection is restored.
Testing Background Sync
Testing background sync is essential to ensure applications function properly under various network conditions. Techniques to simulate offline scenarios include using browser dev tools to throttle network settings or disconnecting from the network intentionally to observe sync behavior.
Common issues when testing background sync include missed sync events or unexpected errors due to network fluctuations. These can be debugged through logging and monitoring network requests. Ensuring robust background sync functionality involves thorough testing, regular updates to service workers, and addressing user feedback regarding sync performance.
Simulating Offline Scenarios
In Chrome DevTools, selecting ‘Offline’ from the Network tab allows developers to simulate offline scenarios effectively. This feature helps in testing the background sync functionality under real-world conditions.
Additionally, using airplane mode to disconnect from the network can provide a practical way to test offline scenarios. This ensures that the background sync features perform as expected, even when connectivity is lost.
Debugging Sync Issues
If the work passed to event.waitUntil() in the sync handler fails, the browser can trigger a later attempt. The number and timing of retries are limited. Keep the operation queued until success is confirmed and allow a retry when the app opens.
Periodic background sync activity can be logged in the event log table in DevTools. This helps in monitoring and debugging sync issues, ensuring that the synchronization process is reliable and efficient.
Best Practices for Implementing Background Sync
Implementing background sync effectively requires adherence to best practices. Testing background sync in real-world network conditions is crucial to ensure reliability. Tools like Chrome DevTools can simulate various network scenarios, helping developers fine-tune their implementations.
Use retry logic with increasing delays for failed transfers. Keep the pending state visible and provide a manual retry if the browser stops dispatching background events. A retry policy cannot guarantee delivery.
Progressive Enhancement
Progressive enhancement is an essential approach when implementing background sync. This method ensures that web applications remain functional even if advanced features like background sync are not available. By building applications that degrade gracefully, you can ensure a consistent user experience across various browsers.
Utilizing a Progressive Web App allows web applications to leverage background sync features where available while maintaining basic functionality in unsupported environments. This approach promotes a resilient and versatile application design that caters to a broader audience.
The browser controls timing
minInterval sets a minimum interval for periodic tasks, not an appointment. It cannot promise a particular time or synchronization alongside a user’s alarm. Keep tasks short and refresh content when the app opens as well.
Background Sync with WordPress and Joomla
Available miTT PWA sync options depend on the plugin variant and browser. See the miTT PWA documentation for Joomla configuration. Periodic refreshes require a connection and are scheduled by the browser.
Installing a PWA does not automatically make forms, chats or uploads work offline. Those features need their own storage of pending operations, retry logic and conflict handling. On iOS, the website must provide updates without Background Sync.
Frequently asked questions
Background Sync can retry a failed transfer later in supporting browsers. The app must store pending operations itself. The browser controls execution; successful delivery is not guaranteed.
The app stores a pending operation and registers a task through ServiceWorkerRegistration.sync. A sync handler in the service worker retries the transfer when the browser dispatches the event.
Typical cases are short transfers such as messages or form data that are stored locally first. Background Sync alone is not sufficient for long uploads, fixed deadlines or guaranteed delivery.
Periodic Background Sync is not supported by Safari on iOS or Firefox. Chrome requires an installed and used web app. A minimum interval does not guarantee execution at a fixed time; the browser considers engagement, network and power state.
Caching makes previously stored files and pages available offline. New server data can only be downloaded with a connection. Pending user operations also require an application-managed queue and error handling.
More articles about PWA (Progressive Web App)
Progressive Web App indispensable for any website?
A PWA offers many advantages over a classic website.
Launch a Joomla PWA
Realization of the Progressive Web App with push messages in Joomla for a local authority.
15 tips for optimizing a PWA
Here are 15 suggestions for enhancing a Progressive Web App (PWA) to deliver a seamless native app experience.