A scenario where transferSize is 0 for non cached loads (or may be not)

[Nithanaroy]

On LinkedIn Lite, I wish to change the app's functionality based on whether the current page was loaded from cache or network. As per https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-transfersize, transferSize === 0 should be a safe way to estimate this. But in situations when the user clicks on the link that is still being cached, Chrome reports the transferSize to be 0, even though it was downloaded from the network. Is there a native way to filter out these cases as non-cache loads?

[npm1]

@yoavweiss may know why we'd report 0 when it's not cached. It might be useful to provide a way to reproduce this issue

[Nithanaroy]

1. Programmatically initiate request r1 for url1, that can be cached
2. r1 queued by the browser
3. User clicks the url1 which initiates r2
4. Browser links the requests r1 and r2 and doesn't make a new network request
5. Once r1's response is cached, r2's response is delivered from the cache

is the sequence of events I observed.

[Nithanaroy]

In the attached screencast, the transfer size is as expected when the user goes to Notifications page after it was fully cached.

happy-case-zero-ts.mp4

[Nithanaroy]

This screencast shows the tricky case, where the user navigates to Notifications page before it is fully cached. The transferSize also shows zero here. As a developer, is there a native way to differentiate this from the above happy case?

trick-case.mp4

[yoavweiss]

@Nithanaroy - This seems like a Chromium issue, rather than a spec issue. Can you file a crbug?

[Nithanaroy]

@yoavweiss, filed one at https://bugs.chromium.org/p/chromium/issues/detail?id=1228610
I'm not sure though if they'll consider as technically spec doesn't enforce any behavior in this corner case. What Chromium is doing is a nice optimization to link r1 and r2 for better performance, instead of starting r2 from scratch.

[yoavweiss]

"they" == @npm1 and me :)

If after looking at this we'd see that there's spec clarifications to be made, we'd come back here with those conclusions.

[noamr]

See here.

Maybe we should clarify in a non-normative note that changing the cache state of a stored response should not affect the original response? It's not entirely clear in HTTP caching what it means to store a response, and which of its property are kept/lost with serialization.

[yoavweiss]

@noamr - Is the Fetch spec clarifying request coalescing beyond this bit on the HTTP cache? IIUC, the scenario we have here is that we have 2 requests that are being coalesced by the network, and I'm not sure what we should do here is properly defined and tested.

[noamr]

@noamr - Is the Fetch spec clarifying request coalescing beyond this bit on the HTTP cache? IIUC, the scenario we have here is that we have 2 requests that are being coalesced by the network, and I'm not sure what we should do here is properly defined and tested.

whatwg/fetch#1329 is the first step in addressing this.
This sort of issue is, generally speaking, part of the confusion caused by not being clear about whether a RT entry describes a response or a fetch. We clarified in the WG call that an RT entry describes a fetch - which means that if a response is reused by two fetches, the first one should have a transferSize and the second one shouldn't.

However, the issue specifically with response coalescing is that it's not a standard feature, but rather a Chromium implementation detail. So I would suggest to identify this behavior is a Chrome bug.

[yoavweiss]

I think there's no spec issue here, just an implementation bug, so closing for now. Let's re-open if we discover there are clarifications to be made.