Determine whether to wait until after responseEnd to queue entry for ResourceTiming

[spanicker]

This came up in the context of consistency with NT2. See: w3c/navigation-timing#50
In Nav Timing 2 we don't want to wait until the load event to create the entry for NavTiming as this causes data bias issues. The current plan is to:

1. create the entry right away and make it accessible from: getEntries..()
2. BUT wait until load event to notify registered PerformanceObservers.

Should we do the same thing with RT (primarily for consistency)?

[nicjansma]

I like the proposal.

Only concern would be compat issues around anyone making the assumption that if getEntryByName(url) != null, that the resource is finished loading.

In that case, they should also be checking responseEnd != 0. Here's one example that will need to be fixed.

[yoavweiss]

That is a serious concern, which we need to evaluate carefully. If current boomerang contains such code, how many sites out there use current (and older) versions of the boomerang library and will continue to do so without upgrading? What would be the implications of such a change on those sites?

[nicjansma]

In the above case, there probably won't be a real issue because that code (theoretically) shouldn't run until we get a load callback from the XHR we're querying the timeline for. In other cases in boomerang, we're properly validating responseEnd is non-zero before we use it for timing calculations.

But I'm guessing there are other cases in the wild making similar assumptions. Or even polling getEntriesByName(url) to trigger some "the resource has loaded" action.

[JosephPecoraro]

Based on Issue #55 the spec gained a note:

This specification does not specify whether steps 20 and 21 should run before or after the load event of the resource

This issue is assuming ResourceTiming entries are added before load. That seems like a conflict.

[spanicker]

(Not seeing the note in the spec)
The larger point of the issue is that either of those steps is potentially too late and can cause data bias issues as described in w3c/navigation-timing#50

[yoavweiss]

As discussed with @nicjansma and at the F2F, we have 2 issues hiding here:

1. We want to add entries early and be able to track ongoing fetches. That is a question for L3.
2. We need to clarify the relationship between the onload event, adding of entries and their completeness. That's a question for L2. I opened Clarify relationship between onload, adding entries and their completeness #127

[yoavweiss]

As 2. has #82 open for it, should this be merged with #137?

/cc @npm1

[igrigorik]

Yep, we have separate issues tracking both of the above. Closing, please feel free to reopen if there are other concerns that are not yet captured elsewhere.