You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The request may be blocked on SW startup and NavTiming should provide visibility into this.
fetchStart is when we send request to worker, SW startup time should be captured before that.
How about [swStartupStart, swStartupEnd], between "Negotiate Link" and "redirect"? See processing model.
P.S. Once we agree on the language, same logic should be replicated in Resource Timing - the worker can be killed between requests; we can't rely on SW being there. Also, UT and RT will be exposed in SW (see w3c/ServiceWorker#553), so I assume we will simply report 0's for startup time when inside a SW.
The text was updated successfully, but these errors were encountered:
(based on discussion at TPAC..) /cc @slightlyoff
fetchStart
is when we send request to worker, SW startup time should be captured before that.How about
[swStartupStart, swStartupEnd]
, between "Negotiate Link" and "redirect"? See processing model.P.S. Once we agree on the language, same logic should be replicated in Resource Timing - the worker can be killed between requests; we can't rely on SW being there. Also, UT and RT will be exposed in SW (see w3c/ServiceWorker#553), so I assume we will simply report 0's for startup time when inside a SW.
The text was updated successfully, but these errors were encountered: