Create resource timing entries for HTML resources

[noamr]

Now that FETCH has the building blocks for measuring resource timings (see whatwg/fetch#1185 and w3c/resource-timing#252), the different resources have to integrate with it, so that the can decide exactly if and when to queue a resource timing entry.
The resources are:

Done:

• navigation: Integration with the HTML spec w3c/navigation-timing#141
• Beacon: Integrate with Resource Timing w3c/beacon#70
• Preload
• images & srcset/image-set: Report image loading to Resource Timing #7510
• scripts, workers & worklets: Report A and script loading to resource timing #7180
• Hyperlink audit (<a ping>): Report A and script loading to resource timing #7180
• SVG image: same as img, as decribed here.
• image button: Report ResourceTiming for video posters and image inputs #7539
• video poster: Report ResourceTiming for video posters and image inputs #7539
• link tag: Report link fetch resource timing #7559
• track: Report EventSource & track ResourceTiming entries #7553
• EventSource: Report EventSource & track ResourceTiming entries #7553
• embed & object: Report ResourceTiming for object and embed #7554
• iframes & frames: Report iframe & frame resource timing #7531
• media resource: Specify range fetching for media #7655

In Progress:

• prefetch: Specify processing model in terms of Fetch w3c/resource-hints#86

Resources that should avoid creating a resource timing entry:

• internal iframe navigation
• downloaded link
• WebSocket: not http(s), so doesn't get RT entries.

[annevk]

Also needs to consider the frame element. Probably works similarly to iframe, but maybe not?

[noamr]

Also needs to consider the frame element. Probably works similarly to iframe, but maybe not?

Updated.

[noamr]

Thinking about this and also about whatwg/fetch#590, I think that we need something like a "fetch a resource" algorithm/layer/mechanism in the HTML spec, equivalent to the different resource loaders found in the browser engine implementation.

This mechanism would deal with setting the initiator type for the resource when reporting, reporting network errors as opaque entries, setting FETCH priority by type, and keeping the preload responses.

@annevk WDYT? I can start jotting down something.

[annevk]

What is reporting network errors as opaque entries?

And what exactly is keeping the preload responses? Isn't that something we want for all fetches?

[noamr]

What is reporting network errors as opaque entries?

The different callers, when they report the response. If the response is a network error, it will report it correctly.
Here, the fetch() API reports the timing info for the response even if it's a network error, and because the network error has an associated URL and opaque timing info, the "right thing" will happen.

And what exactly is keeping the preload responses? Isn't that something we want for all fetches?

Preload is an entirely different subject. See separate effort here. I would prefer to not create a dependency here and tackle the existing network error thing before we tackle preloads.

[annevk]

I see, generally I would like network error reporting to fall out of the same path we use for normal reporting and not require its own dedicated path.

[noamr]

I see, generally I would like network error reporting to fall out of the same path we use for normal reporting and not require its own dedicated path.

It generally wouldn't, except when the caller already has a dedicated path for network errors (like in the case of fetch() and xhr. We'll get to that when we start implementing these calls. I assume most of them will share a single call that fully loads an URL and reports at the end.

[noamr]

See w3c/csswg-drafts#562 for CSS.

[triple-underscore]

Along with the comit 8c0f013,
the following prose above the removed part (for image inputs):

Fetching the image must delay the load event of the element's node document until the task that is queued by the networking task source once the resource has been fetched (defined below) has been run.

the phrase "(defined below)" should also be updated to "(defined above)".

[annevk]

I'm a bit curious how <a download> works as the current setup in the specification is known to be broken. We want it to essentially be a navigation with a flag set. However, this would end up reporting it under resource timing, not navigation timing? It can probably be made to work, but it does create a weird inconsistency. Are navigation downloads also reported under resource timing?

[noamr]

I'm a bit curious how <a download> works as the current setup in the specification is known to be broken. We want it to essentially be a navigation with a flag set. However, this would end up reporting it under resource timing, not navigation timing? It can probably be made to work, but it does create a weird inconsistency. Are navigation downloads also reported under resource timing?

Those are not currently reported under resource/navigation timing at all.

[noamr]

All HTML reporters of resource timing are now specified (prefetch is not specified yet).
Suggesting to close!

[domenic]

Yay!! Congrats!