New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The exact timing of navigation should be defined #19

Open
rniwa opened this Issue Nov 6, 2017 · 5 comments

Comments

Projects
None yet
6 participants
@rniwa
Copy link

rniwa commented Nov 6, 2017

The definition of first paint mentions:

First Paint entry contains a DOMHighResTimeStamp reporting the time when the browser first rendered after navigation.

However, there are many steps needed to navigate a browsing context. We need to refer to a specific step in the navigation so that there is no ambiguity in terms of whether fragment navigation is included, etc...

@RiteshMaheshwari

This comment has been minimized.

Copy link

RiteshMaheshwari commented Apr 25, 2018

+1 on this. Are the first paint and first contentful paint defined as time since navigationStart? If so, can we please clarify it in the documentation.

I am new to this, but from the spec, it looks like the startTime values are supposed to be unix timestamps (which is why duration is set to 0). But, it looks like most implementations are treating startTime as duration since some event (likely/hopefully navigationStart). See MDN. My own test on Chrome 65 shows startTime to be in 100s of milliseconds.

If it is supposed to be a unix timestamp of sorts, we need to reach out to chrome devs and get that fixed. If it is supposed to be a duration, then the spec needs to clarify whether this is starting from navigationStart or some other timestamp.

@Zizzamia

This comment has been minimized.

Copy link

Zizzamia commented Apr 25, 2018

Ciao @RiteshMaheshwari
Paint timing involves PerformancePaintTiming interface that extends PerformanceEntry interface, where startTime and duration are better defined.

The startTime attribute must return the time value of the first recorded timestamp of this performance metric.

The duration attribute must return the time value of the duration of the entire event being recorded by this PerformanceEntry. Typically, this would be the time difference between the last recorded timestamp and the first recorded timestamp of this PerformanceEntry. If the duration concept doesn't apply, a performance metric may choose to return a duration of 0.

For FP and FCP duration must be 0, because duration concept doesn't apply to them.
I hope this helps 😄

@RiteshMaheshwari

This comment has been minimized.

Copy link

RiteshMaheshwari commented Apr 26, 2018

Thanks for the clarification @Zizzamia . Going back to this earlier comment from me:

But, it looks like most implementations are treating startTime as duration since some event (likely/hopefully navigationStart). See MDN. My own test on Chrome 65 shows startTime to be in 100s of milliseconds.

Does this mean chrome is implementing this wrong?

@igrigorik igrigorik added this to the Level 1 milestone May 25, 2018

@tdresser

This comment has been minimized.

Copy link
Contributor

tdresser commented Oct 25, 2018

Todd: we can just eliminate "after navigation".
We need to specify some scope though, equivalent to the scope of a time origin.

Something like "First paint after the time origin is set".
You also need to state that you care about the newly navigated to document's first paint.

@yoavweiss

This comment has been minimized.

Copy link
Contributor

yoavweiss commented Nov 27, 2018

To clarify @tdresser's comment , the group's decision at TPAC was to better define the time we're after as "First paint after the time origin is set" for the newly navigated document.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment