Carify Resource Timing semantics for Early Hints preloads

[krzksz]

103 Early Hints can initiate a preload before the final navigation response is available. Resource Timing defines initiatorType = "early-hints", but the expected timing semantics are not fully clear when the Early-Hinted resource is later consumed by the document from the preload cache / HTTP cache.

In particular, for a PerformanceResourceTiming entry with entry.initiatorType === "early-hints" the spec should clarify whether fields like:

• requestStart,
• responseStart,
• responseEnd,
• etc.

must describe:

• the original network fetch started while processing the 103 Early Hints, or
• the later cache/preload-cache read when the document actually consumes the resource.

Existing behaviour

Right now, both Firefox and Chrome report preloads' timings as the cache read rather than the actual Early Hints download (see test page). That makes it difficult or impossible for authors/RUM tools to measure when the Early Hints preload actually happened and how much headstart it had over the main response.

[noamr]

AFAIK this is fully clarified in the processing model of resource timing/fetch/HTML.

• The time when the 103 response arrived is firstInterimResponseStart
• The time whhen the 2xx/4xx/5xx response arrived is finalResponseHeadersStart
• The original early-hints fetch is the fetch initiated by the Link header in the early hints response
• Every preload cache read is its own fetch with own initiator and timing

The key section in the spec is https://html.spec.whatwg.org/multipage/links.html#preload sections 12 and 13.

Having said that, I see that this is indeed not well implemented and I suggest opening implementation bugs.

[tunetheweb]

I think it still leaves some questions outside of the processing model in regards to Resource Timing:

• Should Resource Timing show both the early hint and the later cache read or only the latter? Currently only the latter is shown in both Chrome and Firefox (Safari does not support preload for early hints).
• What should the initiator-type be for each? Currently both Chrome and Firefox show early-hints for the later request (which is helpful since the initial request is not returned through Resource Timing, and even if it was, it's still helpful to see that on the later request IMHO to know it was fetched from the early-hint cache).

Having said that, I see that this is indeed not well implemented and I suggest opening implementation bugs.

Can you clarify what you think is not well implemented if not answered by previous questions?

[noamr]

I think it still leaves some questions outside of the processing model in regards to Resource Timing:

• Should Resource Timing show both the early hint and the later cache read or only the latter? Currently only the latter is shown in both Chrome and Firefox (Safari does not support preload for early hints).

As far as the spec goes, both should be shown

• What should the initiator-type be for each? Currently both Chrome and Firefox show early-hints for the later request (which is helpful since the initial request is not returned through Resource Timing, and even if it was, it's still helpful to see that on the later request IMHO to know it was fetched from the early-hint cache).

As far as the spec goes, the first initiator is early-hint and the second is whoever requested the resource from the preload cache.

I don't think either of these are "open questions in the spec" and I would be reluctant to open them.

Having said that, I see that this is indeed not well implemented and I suggest opening implementation bugs.

Can you clarify what you think is not well implemented if not answered by previous questions?

[tunetheweb]

I find the HTML spec difficult to read, but I'm not sure I agree it's that clear cut (and neither does AI FWIW).

In particular:

8. If options's document is null, then set request's initiator type to "early hint".

...

10. Let reportTiming given a Document document be to report timing for controller given document's relevant global object.

Since the document is null for early hints (necessary in step 8!), then the resource timing peace in step 10 shouldn't be followed (and even more so because the "relevant global object" won't exist either)? Which is what both browser's currently do (except they also set the initiator type to "early hint" for that later request).

They are added to the map of preload resources, meaning they can be retrieved later but I don't see it saying how to handle resource timing (are they dropped? held back until the document is created? something else?).

I also found this old issue from @yoavweiss which seemed to suggest the early hints should be exposed to resource timing, but that doesn't appear to be what was subsequently specced and then implemented.

So I think if we add implementation issues, they'll ask for where this is specced and that's not clear to me. That's not to say we shouldn't change the spec and/or the implementations but I'm just saying it's not clear to me that there is no more spec work here...

[noamr]

I find the HTML spec difficult to read, but I'm not sure I agree it's that clear cut (and neither does AI FWIW).

In particular:

8. If options's document is null, then set request's initiator type to "early hint".

...

10. Let reportTiming given a Document document be to report timing for controller given document's relevant global object.

Since the document is null for early hints (necessary in step 8!), then the resource timing peace in step 10 shouldn't be followed (and even more so because the "relevant global object" won't exist either)? Which is what both browser's currently do (except they also set the initiator type to "early hint" for that later request).

It's indeed somewhat difficult to read!
reportTiming is like a lambda that takes a document as an argument. It is like a "deferred" addition to resource timing. When the document is created, those deferred entries need to be created.

They are added to the map of preload resources, meaning they can be retrieved later but I don't see it saying how to handle resource timing (are they dropped? held back until the document is created? something else?).

Consuming a preload is an additional fetch, see https://fetch.spec.whatwg.org/#ref-for-consume-a-preloaded-resource

In broad strokes, the fetch goes as normal, but before of going to the cache/network/service-workers etc, the preload map is consulted and the response is taken from there and some the other steps are skipped. The rest of the fetch, like where we mark resource timing, is still called.

So to summarise:

• Each fetch should have a resource timing entry
• Preloading an early hint is a fetch, so it should have a resource timing entry
• Consuming a preloaded resource is a fetch, so it should have a resource timing entry

I also found this old issue from @yoavweiss which seemed to suggest the early hints should be exposed to resource timing, but that doesn't appear to be what was subsequently specced and then implemented.

So I think if we add implementation issues, they'll ask for where this is specced and that's not clear to me. That's not to say we shouldn't change the spec and/or the implementations but I'm just saying it's not clear to me that there is no more spec work here...

I agree about implementations. I'm not convinced that there's a spec issue.

[tunetheweb]

reportTiming is like a lambda that takes a document as an argument. It is like a "deferred" addition to resource timing. When the document is created, those deferred entries need to be created.

OK that's the bit that wasn't clear to me. The rest I agree with. I guess this piece is where that's defined?

12. Let commit be the following steps given a Document document:

    If entry's response is not null, then call reportTiming given document.

    Set document's map of preloaded resources[key] to entry.

13. If options's document is null, then set options's on document ready to commit. Otherwise, call commit with options's document.

[noamr]

reportTiming is like a lambda that takes a document as an argument. It is like a "deferred" addition to resource timing. When the document is created, those deferred entries need to be created.

OK that's the bit that wasn't clear to me. The rest I agree with. I guess this piece is where that's defined?

12. Let commit be the following steps given a Document document:
    If entry's response is not null, then call reportTiming given document.
    Set document's map of preloaded resources[key] to entry.
13. If options's document is null, then set options's on document ready to commit. Otherwise, call commit with options's document.

Yea exactly. it's a "defer until document ready" little callback flow