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

> Thanks for the PR, and sorry for the delay reviewing. @mfalken and I took a look.
> 
> It isn't clear to me how these values will be read. I'm slightly worried that there's one service worker, therefore one "start time" and one "ready time", but many requests. It feels like "start time" and "ready time" might be overwritten by another request in a race.

OK, I will change it to mean the "first" start/ready time. These values are only meant for Navigation Timing, I'll prepare a Navigation Timing PR that reads them to make it clearer. (they would have inter-dependencies so this one would have to go in first).

> 
> Maybe these values should instead be associated with the response, since the timing is from the perspective of the request/response. But I'm just guessing, because I'm not sure how these values will be used.
> 
> For instance, if the service worker was started a year ago, and never closed for some reason, should "worker start" be the time a year ago, or should it be the time a given request decided it needed a service worker?

The service worker's start time would be a year ago, but Navigation Timing would expose the later time between that time and the time FETCH has handed control over to the service worker.


-- 
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#issuecomment-816668870

Received on Friday, 9 April 2021 13:07:51 UTC