Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
xiaofud opened this issue Nov 23, 2022 · 8 comments

Comments

@xiaofud
Copy link

xiaofud commented Nov 23, 2022

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.

image

@yoavweiss
Copy link
Contributor

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

@xiaofud
Copy link
Author

xiaofud commented Nov 23, 2022

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?
image

image

@noamr
Copy link
Contributor

noamr commented Apr 18, 2024

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
Copy link
Member

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

@nicjansma
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

noamr commented Jun 6, 2024

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
Copy link
Contributor

noamr commented Jul 10, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants