-
Notifications
You must be signed in to change notification settings - Fork 30
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
What should transferSize, encodedBodySize and decodedBodySize in Navigation + Resource Timing represent for responses where a Service Worker is involved? #124
Comments
I think "0" makes clear sense for I could see the case for making The Anyway, that's all just my opinion. @yoavweiss do you know if there is a reason to keep these as 0? For example, do measurement frameworks assume they are not populated for service workers in order to infer service worker existence? |
I'm not aware of a concrete reason. What you outlined above makes sense to me. |
Not sure what this means. If its the output of a |
Hi all, I'm interested in fixing this isssue in Chromium, and want to cofirm what other implementors think before starting implementation. So far, I think what @wanderview mentioned in #124 (comment) makes sense. Regarding semi-synthetic response case, as @wanderview mentioned, In terms of spec change, some tweaks in the spec for |
I agree with @wanderview too. In terms of encoded/decoded body size, it feels like we should use the transmitted and total bytes stored in the body - https://fetch.spec.whatwg.org/#concept-body-transmitted. Rather confusingly, body transmitted bytes seems to map to Cases where
If the body is constructed from a new Edit: I got the rest wrong because I thought transfer size included the request. Unfortunately, the fetch spec doesn't currently track total transfer size. This will need to be stored initially on the request (counting bytes for headers and such), then that number should be passed to the response, which adds on its own bytes from headers, and Cases where transfer size should be retained:
Since this data should be stored on the response, it will be lost in methods that only copy the body, such as |
I also agree with @wanderview. @jakearchibald, I don't understand what you're referring to in |
@asutherland ohh, I think I got confused by the stuff about redirects and HTTP overhead. If it's purely related to the response, that makes things much easier. |
(belated) Notes from Service Worker WG meeting on Nov 20:
|
Added a few failing tests for this: web-platform-tests/wpt#33283 |
Keep track of chunk sizes as the response stream is being read. Closes w3c/navigation-timing#124
I updated the fetch spec in this PR to account for encoded/decoded body size for constructed responses. Thoughts welcome there. |
This is fixed now. |
The specifications for Navigation Timing API 2 or Resource Timing API 2 does not make it explicitly clear what is the definition or the expected value to be observed for
transferSize
,encodedBodySize
anddecodedBodySize
parameters in both Navigation + Resource Timing APIs for responses that have been synthesised using a Service Worker.The expected values are not clear either, considering how request interception through Service Workers opens up possibilities of zero-to-many fanout of actual network requests and subsequent response synthesis by combining resources from network and/or cache in any number of ways.
Should a page document (the service worker client) be aware of the actual network transfer costs for a request originating from it which can cause zero, one or more actual network request(s) based on Service Worker logic, or should it simply be opaque to all the Service Worker magic and consider whatever it received to be coming as if from the network? Sadly, none of these behaviour definitions has made clear sense to me so far, and there must be a better way of defining the behaviour here.
Current implementation on latest builds of a number of popular browsers (Chrome, Chromium, Firefox, Edge, Samsung Internet) seem to allude to this fact by simply reporting a "0" for all these parameters when a Service Worker is involved in between. A few examples of use-cases include:
encodedBodySize
ordecodedBodySize
for a resource that passes thetiming-allow-check
algorithm should not logically return 0, because there is a payload for those resources.transferSize
parameter is also thrown off in all these cases because it always returns 0 even if thetiming-allow-check
algorithm passes.In effect, this means that today any website which uses a Service Worker (a large number of website do) will not be able to use certain important capabilities of the Navigation Timing or Resource Timing APIs correctly, which is a sad trade-off considering practical use-cases of website latency/performance improvements and metrics collection (in the process of doing so) can often tie website owners to a need of having to use these things together!
The text was updated successfully, but these errors were encountered: