Re: Support for page/resource size

Ilya,

This is not a Chromium bug. It’s a side effect of the fix I made to this issue: https://code.google.com/p/chromium/issues/detail?id=312327. In a nutshell, I had to change the Resource::Type of the LINK rel=subresource request to be the type that would eventually be needed in rendering the page in order to fix the problem of de-duping not working in the renderer’s memory cache. My assumption is that the design work you are doing on preload hints will change the way this is implemented so I’m not going to worry about this issue for now.

As far as how we can determine that a preloaded or pre-rendered object is used, any thoughts on my proposal below about indicating when an object comes from the “ephemeral cache”?

Peter


On Aug 12, 2014, at 7:31 PM, bizzbyster@gmail.com wrote:

> Okay. The initiator in this case is not “link”. I will create a Chromium bug report.
> 
> IG: "Used" is complicated. Say I initiate the fetch via XHR (initiator: xmlhttprequest)... how does the UA know when and if the response is "used"? The app could fetch it, sniff the response, and throw it away - we wouldn't know any better. Same for images: the resource is fetched but is inside a hidden div which is never seen by the user - is that "used"? And so on.
> 
> I wonder if both cases could be adequately handled by simply indicating when a resource is served from the ephemeral cache, which in Chromium is the renderer’s MemoryCache. In general every sub-resource will be retrieved via a network fetch, via an HTTP cache lookup, or via a read from the ephemeral cache. We can then infer that a preload/pre-render object is “used” or not by whether or not it has a corresponding subsequent sub-resource that was retrieved from the ephemeral cache.
> 
> Does that make any sense?
> 
> Peter
> 
> On Aug 12, 2014, at 6:04 PM, Ilya Grigorik <igrigorik@google.com> wrote:
> 
>> 
>> On Tue, Aug 12, 2014 at 2:07 PM, <bizzbyster@gmail.com> wrote:
>> Another hole in the ResourceTiming API is that I can’t tell if objects requested via LINK rel=subresource were subsequently used by the page. ResourceTiming API treats preloaded resources the same as regular resources on that page. Also, there is no indicator that the initiator was a LINK tag.
>> 
>> Seems like an implementation bug. I think the spec covers this case already: "If the initiator is an element, on getting, the initiatorType attribute must return a DOMString with the same value as the localName of that element."
>> 
>> Hint-initiated fetch should return "link". Yes, it doesn't tell you if it was subresource or prefetch, but same constraint applies to other elements (and CSS initiated downloads in particular). I'm not sure if we need to expose more? 
>> 
>> In summary, there is no way to figure out that preload hints were successfully used or not.
>> 
>> "Used" is complicated. Say I initiate the fetch via XHR (initiator: xmlhttprequest)... how does the UA know when and if the response is "used"? The app could fetch it, sniff the response, and throw it away - we wouldn't know any better. Same for images: the resource is fetched but is inside a hidden div which is never seen by the user - is that "used"? And so on.
>> 
>> ig
>