Bugzilla

When Firefox is first launched, we expect the latency of ServiceWorker interception of a page 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. QuotaManager initialization.  Cache API storage is where the ServiceWorker data lives, so any delay in acquiring a DirectoryLock will delay ServiceWorker startup.
3. Process launching and permission transmission.  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.

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 initialization, which has to happen for the Cache API can get a directory lock and access its files.  Note that investigating this is covered by bug 1666208 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.

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 initialization, which has to happen for the Cache API can get a directory lock and access its files.  Note that investigating this is covered by bug 1666208 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.

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 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.

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.