Skip to content
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

Lack of Feature Parity with Performace.measure() in Level 2 #154

Open
c3-ThomasHuo opened this issue Aug 25, 2021 · 5 comments
Open

Lack of Feature Parity with Performace.measure() in Level 2 #154

c3-ThomasHuo opened this issue Aug 25, 2021 · 5 comments
Projects

Comments

@c3-ThomasHuo
Copy link

From the documentation of Performance.measure(), it seems like the startMark and endMark still depend on PerformanceTiming, which is clearly being depreciated. Is there a way to have it now default to PerformaceNavigationTiming properties instead?

@npm1
Copy link
Contributor

npm1 commented Aug 25, 2021

Interesting observation! I think that we could change user timing to use PerformanceNavigationTiming instead of PerformanceTiming. It looks like the names used in one or the other are almost the same, or exactly the same? The exception would be startTime and duration, which are not names we'd want to special case and hence we'd need to exclude those (and perhaps any other attributes that are not applicable for Nav Timing).

@yoavweiss
Copy link
Contributor

Looking at the list of names, it seems to be comprised of:

  • navigationStart
  • unloadEventStart
  • unloadEventEnd
  • redirectStart
  • redirectEnd
  • fetchStart
  • domainLookupStart
  • domainLookupEnd
  • connectStart
  • connectEnd
  • secureConnectionStart
  • requestStart
  • responseStart
  • responseEnd
  • domLoading
  • domInteractive
  • domContentLoadedEventStart
  • domContentLoadedEventEnd
  • domComplete
  • loadEventStart
  • loadEventEnd

It seems like the only one that we cannot define by relying on the non-obsoleted parts of the spec is domLoading.

@c3-ThomasHuo - is your issue that this attribute would be missing? Or that we currently rely on parts of the spec we say are obsoleted? Or something else?

@nicjansma
Copy link

One of the discussions we've been having in the WebPerf WG lately has been around possibly having more than a singular NavigationTiming entry. For example, from BFCache or SPA Soft navigations.

If we do update UserTiming to be based on PerformaceNavigationTiming, we will want to consider how it would behave if there were more than one entry. (i.e. based on the attributes from the most recent entry?)

@yoavweiss yoavweiss added this to New in Triage Mar 24, 2022
@yoavweiss yoavweiss moved this from New to Work in Triage Apr 21, 2022
@yoavweiss
Copy link
Contributor

Options to resolve this:

  • Adapting the spec to point at the new definitions for most of these, other than domLoading
  • Gather telemetry and see if this user-timing naming conventions is something we can remove without anyone noticing.

@yoavweiss
Copy link
Contributor

On the second point, I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1318445

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

4 participants