Behaviour with regards to caching

[Krinkle]

It's unclear to me what the expected behaviour is from user agents with regards to cached resources.

Current behaviour as observed in Chrome and Firefox:

Natural first view (cold cache):

• Chrome
  • Network inspector shows 200 OK entries for images.
  • performance.getEntries() includes these (no size fields yet per chromium #467945).
• Firefox
  • Network inspector shows 200 OK entries for images.
  • performance.getEntries() includes these.

Natural second view (cache primed, navigating to the same page again):

• Chrome
  • Network inspector shows 200 (cached) entries for images.
  • performance.getEntries() includes these.
• Firefox
  • Network inspector shows no entries for images.
  • performance.getEntries() does not include these.

Manual reload:

• Chrome
  • Network inspector shows 304 entries for images.
  • performance.getEntries() includes these.
• Firefox
  • Network inspector shows 304 entries for images.
  • performance.getEntries() includes these (as expected with a small transferSize but with full *BodySize).

The spec has wording about "relevant application caches", and it seems both browsers implement this for the reload/304 scenario. But the behaviour for natural cache hits is inconsistent (e.g. where the resource is within the local max-age and therefor no request goes to the network).

I'm also not sure what the expected behaviour should be. On the one hand it seems useful to be able to instrument actual network activity (as observed in the timeline). On the other hand it also seems useful to be able to calculate all resources used by the user agent (regardless of where they come from).

Also with Web Manifesto in mind, it seems best to include them all - which will allow authors to satisfy both uses cases (by calculating the field of interest, either transferSize or *BodySize)

[yoavweiss]

Firefox
Network inspector shows no entries for images.
performance.getEntries() does not include these.

I believe this is a bug in the Firefox implementation. I recently fixed a similar bug in the WebKit ResourceTiming implementation.

As a consecutive second view's resources are often fetched from the memory cache (at least in Blink/WebKit), adding entries for these resources requires specific code to handle that case.

@Krinkle - could you open an issue on Mozilla's bugzilla and see their response?
@marcoscaceres / @eliperelman - who should we ping on the Mozilla side for this?

[igrigorik]

Resources that are retrieved from relevant application caches or local resources must be included as PerformanceResourceTiming objects in the Performance Timeline [PERFORMANCE-TIMELINE-2].

The expected behavior is that cached resources (app cache, http cache, memory cache) should be shown in the timeline. Once we resolve #39, this will be much more clear, but in the meantime the above still applies.

[Krinkle]

Thanks @yoavweiss, @igrigorik.

Looks like it was reported already - https://bugzilla.mozilla.org/show_bug.cgi?id=1113676.

[igrigorik]

Looks like FF is landing patches to address this. Closing, please feel free to reopen if there is more to address here.

[sunnybear]

2020-10-16, still have this issue with Firefox 81.0