requestIdleCallback (equivalent) for ServiceWorkerGlobalScope

[jeffposnick]

While using service workers, I've come across a few scenarios in which there's "low-priority" work that I'd like to perform. This work, ideally, would be performed at a time that wouldn't block core service worker functionality. Some examples of the type of work I'm talking about:

• Resending one or more queued Google Analytics pings that failed while offline, and were saved in IndexedDB.
• Implementing a cache-expiration policy that clears out older entries based on some configuration.

I have written code to implement both of those scenarios. In first case I run the code whenever the service worker starts up, which introduces a delay before the service worker can handle events. In the second case I run the code inside a fetch event handler, after the event.respondWith(), which introduces a delay before any subsequent events could be handled.

Something akin to requestIdleCallback, but available within a service worker context, seems like what I'm thinking about, though that presupposes that the browser would be able to intelligently guess when a service worker is likely to be idle.

Alternatively, this kind of work could be performed in a hypothetical unload event, but that's previously been discussed and rejected.

The Background Sync API could be used for some types of work, but that feels like it's outside of the intended use case—if every service worker fired off a periodic Background Sync event just to wake up and, e.g., clean out its caches, that sounds inefficient.

Have other folks thought about appropriate eventsto hook into to do this sort of low-priority work? Is there any appetite from the spec maintainers/implementers to add in something like requestIdleCallback to the ServiceWorkerGlobalScope?

[wanderview]

This sounds similar to the other feedback we've heard about needing a Worker or SharedWorker from a ServiceWorker. Some work needs to be performed, but we don't want to delay handling fetch events, etc.

Alternatively we could do the idea about letting multiple service workers spin up so latency is less of a concern.

[domenic]

My opinion, blending in a bit of perspective writing non-blocking servers in Node.js:

• CPU-bound work should never be done in the service worker. It is only for reacting to fetch events (or other incoming events like push). Thus you really need Worker at least. requestIdleCallback will not cut it in the general case. (I am less sure about SharedWorker.)
• In theory the rest of your work should be doable fast, without blocking fetch events. E.g. all I/O should be async and return to the event loop immediately. So the cases listed in the OP should not need requestIdleCallback. In practice maybe browsers are not as good as Node.js in this regard.
• requestIdleCallback still seems like a bad API because unlike in the foreground thread, you have no guarantee that painting will occur at least 16 ms apart. Network requests could come in every 1 ms. You just never know.

[jeffposnick]

👍 from me to the idea of offloading work to new Workers that are constructed from within the ServiceWorkerGlobalScope. That sounds nicer than trying to forcibly adapt something like requestIdleCallback().

I hadn't previous seen #678, but that looks like details the feature request, so I'll close this issue.

[publicocean0]

I need a callback when service idle is terminated