A resource timing entry is not created if the end of a non-null response body is not reached and there is no consume body steps

[Lubrsi]

What is the issue with the Fetch Standard?

For example, the given code will not produce a resource timing entry:

fetch("/alwayserror").then(resp => {
    if (!resp.ok) {
        return "status_" + resp.status;
    }
    return resp.text();
}).then(() => {
    console.log(JSON.stringify(performance.getEntriesByType("resource")));
});

Where /alwayserror is an endpoint which returns an error status code and a response body containing one byte.

In Blink, WebKit and Gecko, they produce a resource timing entry, but they all have a race condition of when it becomes available. In my testing on macOS 15.3.1:

• For WebKit, it's a coin flip if the resource timing entry is available in the promise job reaction for the second then
• For Gecko, I had to wait until at least the next task (e.g. a setTimeout(() => {}, 0) for the entry to be available.
• In Blink, I had to wait for at least a 51ms timeout for the resource entry to start appearing, but it's hit and miss if it's available at that timeout.
• Reading the body to the end (e.g. removing the if (!resp.ok) path in the above example) produces a resource timing entry straight away in all three, available in the second then callback.

On the live web, this is encountered by Cloudflare Turnstile.

This is caused by processResponseEndOfBody being called as the flush algorithm when reading the body through a TransformStream in fetch response handover. If the end of the stream is not reached, flushAlgorithm is not called, and thus a resource timing entry is not created.

[annevk]

I'm not really sure what we could do to improve this situation. If I remember correctly we need the full body in order to create a timing entry.

cc @noamr

[noamr]

One thing we can do here is create the resource timing entry at handover, and add it to the buffer (accessible via e.g. getEntriesByType), but set its final info (encoded/decoded size, end time) and queue it to observers only when its body is complete. This is what we do for navigation timing entries. Not sure if this helps with your use case @Lubrsi?

/cc @yoavweiss

[annevk]

I like the idea of it being more deterministic when it's allocated.