Nic Jansma

@mfalken: > Apologies for missing this. I see w3c/resource-timing#119 has been linked to which explains some of the issues around here. As that issue notes,fetchStart-workerStart to measure startup time is...

@mfalken: >I may be missing something, but the two specs seem to have workerStart after fetchStart. NT says workerStart is when the service worker was started up, or when the...

Tried to summarize where we're at for the WebPerf WG https://docs.google.com/presentation/d/1r3FwT1UTo7lpjZvYe-YV7cNAee8co-qCxIU5SdERalQ/edit

We had a further discussion on this as well on March 18th 2021 in the WebPerfWG call, with ServiceWorker folks: https://w3c.github.io/web-performance/meetings/2021/2021-03-18/index.html I will address that and @noamr's feedback in this...

@noamr: Thanks for putting your suggestions together! Overall I agree on the simplification. > For worker-served responses, workerStart should be the time before the request was handed to the worker,...

Yoav and I will review the previous discussion and will present options in a future WebPerf WG call to move this forward.

Discussed on Apr 28 WebPerf WG call: https://w3c.github.io/web-performance/meetings/2022/2022-04-28/index.html Summary: * It seems fine to expose prefetch and Critical-CH signals orthogonally.

Network Error Logging could help for gathering analytics of failed navigations and failure status codes, but it does have some limitations. As an example, some of Akamai's mPulse (performance analytics)...

@mmocny As a generic analytics provider (Akamai is also the CDN in only _some_ cases), we don't know whether a website's URL is a "good" or or "bad" one --...

Related https://github.com/w3c/resource-timing/issues/90