1608319 - When it's known that we will spawn a ServiceWorker, we should attempt to preload/preheat its Cache API storage

Status: NEW

(Core :: DOM: Service Workers, enhancement, P1)

Description

[Andrew Sutherland [:asuth] (he/him)]

If we're planning to spawn a ServiceWorker, it's a given that the ScriptLoader will need to open its (chrome-namespaced) Cache API storage. This entails potential contended QuotaManager IO-thread access to acquire the directory lock and the required disk I/O. We could attempt to recover some ServiceWorker startup-latency time by pre-emptively creating the cache::Manager for the origin in question and allowing this I/O to happen in parallel with the other interception and worker startup overhead.

In particular, if we reach the bottom of ServiceWorkerInterceptController::ShouldPrepareForIntercept in parent-intercept mode where IsAvailable() returned true and storage is allowed for the channel, it would make sense to trigger the preload iff:

• We have a "fetch" handler for the scope. (No point preloading if we're not going to spawn the ServiceWorker.)
• The ServiceWorker isn't already running.

This gets called by nsHttpChannel::Connect, which lets us get ahead of the async redirect, but it's really just the latency before we actually get around to kicking off the worker's script loader on the main thread of its target that I'm hoping helps us out.

Relatedly, there might also be some benefit from forcing us to skip the lazy-acquisition of the file descriptors for script loading if we aren't already. (We originally would acquire file descriptors for every Response returned by the Cache API, but this would potentially crash Firefox as it ran out of file descriptors in pathological cases of a lot of returned things, so we made that lazy. Note that this would be for the requests issued by the worker script loader, not the preheating.)

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Relatedly, there might also be some benefit from forcing us to skip the lazy-acquisition of the file descriptors for script loading if we aren't already.

This should already be there unless it was changed since I left.

FWIW, chrome is starting to do something similar when we see the match is from a "related" FetchEvent. When cache.match() is started we look to see if there are any outstanding FetchEvent objects with the same URL. If yes, then we say the match is related to some FetchEvent and treat it as higher priority.