initiatorType definition doesn't define initiator in multiple element scenarios

[yoavweiss]

While digging around WebKit's resource timing code, I realized that initiatorType is not well defined in scenarios where the same resource is requested by multiple initiators.

e.g. If an image is requested first by <img> and later on by a CSS url(), which initiator type should it have? To me it makes sense that it would be defined to be based on the first element that initiated that fetch, so in the above scenario it would be "img" rather than "css".

[yoavweiss]

I wrote up a short test at http://jsbin.com/tanuweletu/1/edit?html,console

It seems like Firefox maintains "img" in that field, similar to WebKit's (not-yet-shipped) implementation. Blink's implementation OTOH is flaky and results in either "img" or "css" :/

[igrigorik]

If an image is requested first by and later on by a CSS url(), which initiator type should it have?

Personally, I'd expect it to report "img" for the first request and "css" for the second. The fact that the latter may have been served from one of many caches (memory, serviceworker, http, whatever) is completely orthogonal.. What matters here is who initiated the fetch, not whether it hit the network.

[toddreifsteck]

My expectation matches @igrigorik

[toddreifsteck]

Note that Microsoft Edge is "img" and only lists 1 resource timing.

My 100% guesstimate on the basic structure of why most browsers would see 1 resource timing is that one download or the other kicks the download then the other one waits on the file until it completes. The "download" code is most likely recording the resource timing.

[yoavweiss]

It's not a second fetch served from one of the caches. The CSS url() is reusing the same resource object (similar to multiple <img> tags with the same src value).

[igrigorik]

But the reused resource must come from somewhere, right.. a shared cache? In this instances it's probably the memory cache, but it also doesn't have to be - e.g. evicted and falls through to HTTP cache.

Fetch does not "explain" memory caches today, it should.. This is also related to https://github.com/w3c/preload/issues/30.

[yoavweiss]

It is coming from the memory cache, but I don't think we want to expose each call to the memory cache in resource timing. (e.g. that's also where the preloader is placing preloaded resources, and where later DOM nodes find them when they are needed)

FWIW, HTML has a concept of "list of available images" that touches on the memory cache a little (as some of the behavior there is Web exposed). But I totally agree that it should be more explicitly explained.

[igrigorik]

It is coming from the memory cache, but I don't think we want to expose each call to the memory cache in resource timing...

I'm not saying we should expose calls to the memory cache. Rather, something triggers a request... that something is the initiator. Whether the response for this request comes from memory/http/whatever cache is beside the point. Also, there are probably some potentially privacy issues with leaking the "first" initiator for subsequent requests..?

[igrigorik]

@yoavweiss assigning you as owner on this; I believe you had an AI from the F2F to write up how different browsers behave, what we want to see, etc?

[noamr]

This is yet another side effect of the memory cache not being defined.