Open Bug 1666761 Opened 4 years ago Updated 3 years ago

Document critical path for ServiceWorker interception of the first loaded page at startup

Categories

(Core :: DOM: Service Workers, task, P3)

Product:
Core
Component:
DOM: Service Workers
Type:
task

Tracking

()

Status:
ASSIGNED

People

(Reporter: asuth, Assigned: asuth)

References

(Depends on 3 open bugs)

Details

When Firefox is first launched, we expect the latency of ServiceWorker interception of a page and its initial response to depend on the following things:

  1. ServiceWorkerRegistrar loading. The ability to determine whether to intercept is based on this. (Although if not loaded, it's possible to just not intercept.)
  2. Process launching. ServiceWorkers need to be launched into a process, and under fission this will almost certainly be a new process, and at startup we might not be able to depend on preallocated processes.
  3. Permission transmission.
  4. Worker launching. The act of spawning the worker thread in the content process.
  5. Script loading.
    • Cache API opening for the given origin.
    • QuotaManager storage and temporary storage initialization, which has to happen before the Cache API can start accessing its files. Note that investigating this is covered by bug 1666208 and bug 1666211 and won't be part of this bug's efforts.
  6. Fetch request serialization / deserialization.

This bug tracks documenting the above in more depth, attempting to document our general understanding of which is always fast, always slow, or can vary based on factors and what those factors are. This bug may result in telemetry spinoffs but telemetry and dashboards aren't intended to be a deliverable of this bug.

Depends on: 1666208
Depends on: 1666211

Preliminary data gathering from about:serviceworkers on bug 1506892 is showing that ServiceWorkers largely appears to be off the critical path:

  • There is 0 wait time for ServiceWorker registration loading which is initiated as soon as the profile is made available. ServiceWorkerManager doesn't get around to asking until ~300ms later, and experiences effectively zero delay.
  • On gmail, the first interception:
  • The Cache API Context acquires the directory lock in 0-4ms.
  • The ServiceWorker spawns and has loaded its top-level script within 47ms.
  • The synthesized response is received in the parent and starts pumping after ~62ms (which includes the SW spawning).
  • The synthesized response completes pumping after ~109ms (inclusive of the previous times).
Depends on: 1506892
You need to log in before you can comment on or make changes to this bug.