Are fetchStart, connectStart, redirectStart relative to navigationStart?

[Nithanaroy]

Times like fetchStart, connectStart, redirectStart are not timestamps to compare with page level metrics like loadEventEnd. Are they relative to navigationStart?

[npm1]

What's loadEventEnd? But yes, the values returned in the API are relative to the timeOrigin (so yea, navigationStart).

[Nithanaroy]

Okay. Thank you.
I'm referring to https://developer.mozilla.org/en-US/docs/Web/API/PerformanceTiming/loadEventEnd

The numbers I'm seeing in our RUM datasets are weird based on the definition you confirmed. I am seeing

loadEventEnd - navigationStart > postOnLoadResourceTimingEntry.startTime

for a lot of RUM samples. And as per the definition startTime should equal fetchStart
Here postOnLoadResourceTimingEntry is a resource that is initiated on the page's onLoad event.

Both loadEventEnd and fetchStart not being relative to navigationStart is the only explanation I can think of for this which doesn't agree with the spec.

Any thoughts on why this could be happening?

[npm1]

How much bigger is it? I would suggest looking at performance.timeOrigin, how different is it from navigationStart? The former is the one used for startTime, and also we jitter the values so that could affect this kind of comparison. Also worth double checking that the fetch begins directly on onLoad and not in a promise inside it, or something like that which introduces some delay.

[nicjansma]

Do you have a page that reproduces this problem? Have you seen this across browsers, or only in specific ones?

Here postOnLoadResourceTimingEntry is a resource that is initiated on the page's onLoad event.

In that case, the loadEventEnd hasn't happened yet (since the handler is still running), so it's likely the postOnLoadResourceTimingEntry.startTime should happen prior to loadEventEnd-navigationStart. If you compare to loadEventStart, postOnLoadResourceTimingEntry.startTime should be after that.

If that's not the issue, there are a few known browser bugs with navigationStart (via NavigationTiming) and timeOrigin (which ResourceTiming use) differing slightly https://bugs.chromium.org/p/chromium/issues/detail?id=955532#c26

[Nithanaroy]

Hi @npm1,
On my dev machine it happens around 100ms earlier, but on users' devices I have seen bigger numbers. Both timeOrigin and navigationStart match for the page I'm interested in.

And I verified the code to make the resource we are fetching happens on the onLoad event of the window, something like,

window.addEventListener('load', () => { getMyApiDataUsingFetch(); });

[npm1]

One additional idea: locally you could log performance.now() at the beginning and at the end of the load event to know the time frame where we were expecting the fetch to begin. That said, fetching is inherently asynchronous in modern browsers, so I'm not surprised that this happens in some cases. That is, the process that runs the JavaScript is not the same as the process which performs the network requests, so this could explain why you may see this kind of result, unless you use an async function and await the fetch.

[Nithanaroy]

Hi @nicjansma,
I think with loadEventStart the numbers look reasonable, i.e.

loadEventStart - navigationStart < postOnLoadResourceTimingEntry.startTime

Is loadEventEnd - loadEventStart the time taken to execute the onLoad event handler? Are these separated to easily see how much work is being immediately after page load?

Thanks for all the ideas @npm1 :)

[nicjansma]

Correct loadEventStart is the timestamp before the onload handlers run and loadEventEnd is the timestamp after all onload handlers have finished, so the difference between the two is the duration.

If you're executing code at onload, any network requests that start then will probably have a startTime after loadEventStart and before loadEventEnd

[nicjansma]

@Nithanaroy I believe we've addressed your issue, but please leave a comment if there is still a question here!

[Krinkle]

loadEventEnd is the timestamp before the onload handlers run and loadEventStart is the timestamp after all onload handlers have finished, […]

I think you meant the other way around, right? 🙂