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

worker start needs to be added to diagram #128

Closed
pauljroy opened this issue Aug 12, 2020 · 8 comments
Closed

worker start needs to be added to diagram #128

pauljroy opened this issue Aug 12, 2020 · 8 comments

Comments

@pauljroy
Copy link

Hello, I'm on the Bing performance team. Just was talking to Todd Reifsteck and we notice that Worker Start is not in the Navigation Timing diagram at the start of the processing model. Would be great if it could be added. Thanks!

@npm1
Copy link
Contributor

npm1 commented Aug 12, 2020

@yoavweiss are you a good person to add this? I believe it goes after unloadEventEnd and before redirectStart.

@yoavweiss
Copy link
Contributor

Sure

@yoavweiss yoavweiss self-assigned this Aug 13, 2020
@nicjansma
Copy link

nicjansma commented Aug 15, 2020

Is the value of workerStart lost or wrong in some redirect scenarios?

e.g.

Same Origin Redirects

When navigating to a.com which redirects to another page on a.com (all covered by a Service Worker):

  1. Step (8) records workerStart
  2. Step (9) starts the fetch for a.com/, which redirects to a.com/redir
  3. Step (20e) sets all attributes to 0, except a list which doesn't have workerStart
  4. Step (20f) goes back to Step (9)

In this case, a.com's workerStart time is cleared at step (20e), and not re-set at any point. Even though it's the same origin for the SW the whole time. I think I would expect it to be saved to its original value (from the first fetch of a.com/redir, assuming the SW doesn't "restart" during the redirection).

Cross-Origin Redirects

When navigating to a.com which redirects to b.com (both are covered by a Service Worker):

  1. Step (8) records workerStart for a.com
  2. Step (9) starts the fetch for a.com/, which redirects to b.com
  3. Step (20a) sets a few attributes to 0 (not including workerStart), then goes to Step (9)

In this case, a.com's workerStart time is saved though the rest of the DNS->Response attributes are for b.com. I think I would expect the SW time to be for b.com instead of a.com here (unless there are privacy/security implications?).

I may be missing some security implications -- if the current steps are correct, we may want to note in the workerStart definition what it represents in redirect scenarios.

@nicjansma
Copy link

And some of this may be related to #100

@nicjansma
Copy link

Addressed this (added to the diagram) and the comments above about the processing model in #131

@dashed
Copy link

dashed commented Oct 20, 2020

I'm looking to calculate Service Worker initial boot times.

Is the following no longer reliable if redirectStart > 0?

// measuring service worker startup time
let entry = performance.getEntriesByType('navigation')[0];
let swStartupTime = entry.fetchStart - entry.workerStart;

I've seen requestStart - workerStart referenced here https://webplatform.news/issues/2018-11-19 (and https://youtu.be/25aCD5XL1Jk?t=274 ). Unsure if this is better.

@nicjansma
Copy link

Correct, today if there are redirects, Service Worker Startup time (as fetchStart-workerStart) will include those redirect durations.

requestStart-workerStart would have the same issue.

@noamr
Copy link
Contributor

noamr commented Mar 20, 2022

It's now in the diagram.

@noamr noamr closed this as completed Mar 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants