How to get correct connectStart/End, domainLookupStart/End value when service worker is enabled?

[xiaofud]

When enabling service worker to proxy http requests, the connectStart/End, domainLookupStart/End returned from performance.getEntriesByName is the same as workerStart. And if I disable service worker, these values become "normal". My question is how I can get the real connection time metrics when service worker is involved?

Below is a screenshot when service worker is enabled.

[yoavweiss]

I believe you can get those values when looking at Resource Timing entries in the SW itself. Does that make sense?

[xiaofud]

I believe you can get those values when looking at Resource Timing entries in the SW itself. Does that make sense?

Hello, thanks for your reply. Could you please provide an example? I'm a backend developer. I asked our front engineer to add logs in service worker. See pic below. But we still get the same connectStart and connectEnd. Anything I miss here?

[noamr]

This is WAI. The problem with service worker responses is that they could have been fetched and cached before you even started your client fetch.

One thing I was thinking we can do (WDYT @yoavweiss @nicjansma @tunetheweb?) is include something like an originalEntry in a resource timing entry that comes from a service worker response, which points to the internal service-worker timing info. It would use the time origin of the client, but the timing might be before the fetch start of the main resource timing entry, and perhaps even have negative values if this response was cached before navigation.

[tunetheweb]

Sounds reasonably to me. But would be interested to hear @nicjansma 's view as to whether this would actually be useful.

[nicjansma]

Yeah that sounds ideal to me as well.

Would the originalEntry be part of the ServiceWorker's RT timeline, or the RT entry in the page's timeline?

[tunetheweb]

Would the originalEntry be part of the ServiceWorker's RT timeline, or the RT entry in the page's timeline?

Let's get @noamr 's opinion of this when he's back. I originally (misread?) "client" as being the service worker and so the timestamps were not altered to match the page, but re-reading it seems like I might be wrong there.

include something like an originalEntry in a resource timing entry

Not loving the originalEntry name to be honest. For a page-initiated request, handled by routing it through the service worker, then there's ambiguity as to which is the "original" request. Maybe workerEntry?

[noamr]

Would the originalEntry be part of the ServiceWorker's RT timeline, or the RT entry in the page's timeline?

Let's get @noamr 's opinion of this when he's back. I originally (misread?) "client" as being the service worker and so the timestamps were not altered to match the page, but re-reading it seems like I might be wrong there.

I'm back soon!

In the SW timeline you can already see the entry. So originalEntry would be in the page's timeline. The timestamps would be alterred to match the page's time origin.

include something like an originalEntry in a resource timing entry

Not loving the originalEntry name to be honest. For a page-initiated request, handled by routing it through the service worker, then there's ambiguity as to which is the "original" request. Maybe workerEntry?

Better!

[noamr]

Summarizing conversation from the WG, there seems to be good sentiment towards having something like originalEntry, but perhaps it's better if it doesn't survive cache save/restore, as the timestamps for that might be less useful.

So the idea would be that the timing info is assigned to the response object, and gets copied when a service worker creates the client response object in respondWith (see potentialResponse in https://w3c.github.io/ServiceWorker/#dom-fetchevent-respondwith).