Exposing Early Hints preloads to ResourceTiming

[yoavweiss]

As part of Chromium's Early Hints prototype, a good question rose: How can folks know that a certain resource was fetched using an Early Hint?

Initially, I thought that fetchStart for such requests would reflect the fact that they were fetched before the navigation's responseStart, but responseStart is defined to be the first byte of the response, so would include the 103 response that carries the Early Hints. That would keep things ambigous.

What do folks think about exposing a "was preloaded as an early hint" boolean directly on the ResourceTiming entry?

[colinbendell]

There are a few scenarios we will want to track:

1. early hint sent, but no resource downloaded (available in cache)
2. early hint sent, resource downloaded before html payload and
3. early hint, but resource downloaded during or after html payload.

with transferSize === 0 and fetchStart === 0, we will able to distinguish between {1} and {2}. If there was a RT of 'preload from early hint' then we would be able to distinguish between {2} and {3} (and we wouldn't need fetchStart to distinguish between {1} and normal requests w/o early hints)

[bashi]

A strawperson proposal.

enum PerformanceResourceTimingFetchedBy {
    // <link rel=preload> in a document or inserted by JS.
    "document",
    // `Link: </resource>; rel=preload;` in a 103 response.
    "early-hints",
    // `Link: </resource>; rel=preload;` in the final response.
    "headers"
};

partial interface PerformanceResourceTiming {
    readonly attribute PerformanceResourceTimingFetchedBy fetchedBy;
};

[yoavweiss]

That seems reasonable. I can also see a case for adding a "headers" value for resources fetched using (non-early-hints) Link: headers.

[bashi]

Thank you for feedback! Added "headers" value.

[colinbendell]

What is the overlap between this and the InitiatorType? Is there a use case where we would want to distinguish between an initiatorType of img or css AND have a fetchedby of document or early-hints or headers? I'm wondering if these really should be additional enums for initiatorType?

[bashi]

Can initiatorType be arbitrary value as it is DOMString? If we can set initiatorType == 'early-hints' I prefer it rather than adding a new attribute.

[yoavweiss]

Can initiatorType be arbitrary value as it is DOMString?

It can indeed.

Expanding initiatorType to cover this does indeed make sense.

[bashi]

Great. I think I can start prototyping on our side.

Please let me know if we need a spec work other than https://github.com/whatwg/fetch/issues/1225.

[yoavweiss]

I think that this will just fall out of the Fetch integration - you'd need to pass along "early-hints" as the initiatorType in the call to finalize and report timing.

[bashi]

I see, thank you for the pointer!

[yoavweiss]

Closing as there's no action on the RT spec.

[kinu]

Looks like it's closed now, but one thing that isn't too clear to me... so initiatorType string is different from initiator of the request but anything? Nothing is mentioned about how the initiatorType should be set in Fetch spec so it may indeed be the case. Tagging @annevk here just in case https://fetch.spec.whatwg.org/#concept-request-initiator

[kinu]

Also /cc @ricea here (mostly FYI here but probably have implications in Fetch integration)

[yoavweiss]

initiatorType has nothing to do with Fetch's initiator concept (unfortunately). As I wrote above, when you integrate Ealy Hints processing with Fetch, you'd need to call finalize and report timing once the resource is sone loading. On that call, you can set the initiator type.

[kinu]

@yoavweiss I see, thanks for the confirmation! I was so confused by these two but it's clearer now.