Re: [w3c/ServiceWorker] Maintain timing for worker start/ready, for navigation requests. (#1575)

@noamr commented on this pull request.



>        <h4 id="service-worker-events">Events</h4>
 
       The Service Workers specification defines <dfn export id="dfn-service-worker-events">service worker events</dfn> (each of which is an [=event=]) that include (see the <a href="#execution-context-events">list</a>):
           * <dfn export id="dfn-lifecycle-events">Lifecycle events</dfn>: {{install!!event}} and {{activate!!event}}.
           * <dfn export id="dfn-functional-events">Functional events</dfn>: {{fetch!!event}} and the [=events=] defined by other specifications that <a href="#extensibility">extend</a> the Service Workers specification. (See the <a href="#execution-context-events">list</a>.)
           * {{message!!event}} and {{messageerror!!event}}.
     </section>
-  </section>
+    <section>
+      <h4 id="service-worker-timing">Timing</h4>
+
+      Service workers mark certain points in times, that are later exposed by the {{PerformanceNavigationTiming|navigation timing}} API.
+
+      A [=/response=] has an associated null or [=service worker timing info=] <dfn export for=response>service worker timing</dfn>, initially set to null.

@jakearchibald I want to make sure we're OK with how this whole process works, and then I'll publish:

1. A SW PR that defines the new struct
2. A FETCH PR that associates the struct with a response and adds arguments to the SW FETCH call
3. The marking part of the SW PR

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1575#discussion_r612402054