Clarify when entry is added to performance entry buffer

[igrigorik]

Discussion: https://www.w3.org/2016/11/30-webperf-minutes.html

Background: #55. In #79 we added a note to flag the implementation differences across browsers. Ideally, we should aim to converge on a consistent implementation:

1. It would be great to get some interop tests to identify where/how existing implementations differ on whether the entry is made available before or after the load event.
2. Real-world telemetry on how often developers rely on querying entry from within onload would, also, be very helpful.

[JosephPecoraro]

Has there been any update on this?

All of the current web-platform-tests seem to require the PerformanceEntry be added before the Resource's load event. However, I'm guessing they existed before PerformanceObserver; which seems to be the major reason to push for allowing entries to be added post-onload.

I was also unable to find a list of interop issues. #55 (comment) pointed to a test file that no longer exists.

[ghost]

@igrigorik I wrote a script to test when an entry is made available in resource timing buffer. I tested it on Chrome and Firefox Nightly using PerformanceObserver.
The PerformanceResourceEntry always gets added to Resource Timing Buffer just before the resource's load event.

I can also help in writing interop tests for this

[igrigorik]

The PerformanceResourceEntry always gets added to Resource Timing Buffer before the resource's load event.

We may change that soon in Chrome. Or, at least, there are discussions for pushing delivery of entries towards idle time, which may change what you're seeing.. and such change is compliant to what we specced for PO. /cc @tdresser @spanicker

• For PO, I don't think we want to make any promises with respect to onload.
• I'm still of the mind that we shouldn't make before-onload promise for perf timeline either, but this is where @toddreifsteck disagreed before (Is it well defined when the "add a PerformanceResourceTiming entry" algorithm should run? #55 (comment)).
  • We don't have real-world telemetry on if/whether querying perf timeline within onload is a thing.

Some tests for what the implementations do today, specifically with respect to when entries become available in perf timeline (independent of PO) is the right place to start, I think.. @skjindal93 if you're willing to wire up WPT tests for that, that would be super helpful. If we find that all implementations deliver before onload, we might as well lock that in.

[npm1]

I don't think that PerformanceObserver means we should stop adding entries before load. The only significant work from the PerformanceObserver is the callback, and when queueing an entry we only queue a task for that callback, not just run it immediately. What's important is that there is no guarantee that the task will be run before onload, since it is a low priority task.

[yoavweiss]

@npm - so if I understand you correctly, we could have a guaranty that entries are added to the buffer before onload, but not a guaranty that PO will fire before it. Is that correct?

@igrigorik & @toddreifsteck - Assuming that the above is correct, would you be OK with modifying the spec to say that entries MUST be added to the queue before the onload event, but PO tasks may actually fire afterwards?

[yoavweiss]

Note that @npm1 already wrote tests for this, and it seems like browsers are currently consistent about adding entries before onload.

[npm1]

If I understand the comment in [1] correctly, WebKit decided to change their behavior to add entries to the performance buffer asynchronously.

[1] #141 (comment)

[yoavweiss]

@npm1 - yeah, your resources_added_by_onload test no longer seem to pass there (but with a couple of timeouts, so it doesn't seem like onload is losing the race every single time).

In any case, I think we need to separate three cases:

• When resource entries are added to the timeline buffer - AFAIU, they can be synchronously added in all implementations.
• When PO callback fires - could be async in all implementations.
• When resourcetimingbufferfull fires - we need to create a secondary buffer if we want to make it async. (I added a long comment on the issue, and GH seems to have dropped it to the floor :/)

[yoavweiss]

I was looking at the spec for #163 and I'm failing to find:

• Where is add a PerformanceResourceTiming entry called
• Where is RT calling into Queue a performanceEntry or otherwise calls PO

Seems like we need some Fetch integration for the former, which will also define when the entry is added. Then we need "add a PRT entry" to call into PO in a way that bypasses the normal queueing (as RT has its own special buffering logic)

[npm1]

Within ResourceTiming, they seem to be called at the end of the processing model. What I understand out of it is that we should call those once we've fetched the resource and it's not a redirect. We could probably put it at the end of the fetch algorithm. I think the main fetch is supposed to return something but its last step doesn't return anything? It's probably missing a step like this:

24. Return response.

[rniwa]

TPAC F2F consensus: We're going to defer this issue until the fetch integration is done. Defining when a resource load finishes is problematic because, for example, a given resource may have trailers which may delay the completion of the total resource load time but not the completion time of the resource body.

[noamr]

Fetch integration is now prepared for handling this.
It should be spec'ed together with whatwg/html#6542

In essence, every initiator should decide when it reports to resource timing and when it sends to load event, but we should probably have a policy so that resources do this in a consistent fashion, and perhaps have a reusable algorithm in the HTML spec for resources that behave similarly.

[noamr]

As a general rule in whatwg/html#6542, the entry is added on process response done of the FETCH algorithm (called from here).

This clarifies that the entry should be added before the load/error event. The tests in resource-timing WPT rely on that.

[yoavweiss]

Sounds great! Can we close this then?

[noamr]

Sounds great! Can we close this then?

I believe so.