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 · 4 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.

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

4 participants