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.

> I would prefer if we defined this in Fetch and SW just does the marking. Mainly to keep response defined in a single place.

OK. I was trying to make it so that FETCH doesn't have to be modified every time we add a new service-worker metric. Should the struct live in FETCH as well?

> Is it correct that this information gets lost if a network error is returned instead at some point?

This is only exposed through Navigation Timing. So, if there's a network error, the document won't be loaded and these values would be meaningless. In other words, correct.

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