You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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.
When enabling service worker to proxy http requests, the connectStart/End, domainLookupStart/End returned from
performance.getEntriesByName
is the same asworkerStart
. 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.
The text was updated successfully, but these errors were encountered: