Add workerStart attribute to measure (Service)Worker startup time

[igrigorik]

If the app is ServiceWorker-enabled then all fetches are routed to the SW, where they may be fulfilled from local cache, rewritten, forwarded to remote server, etc. However, the SW script may be terminated at any point and may need to be (re)started prior to servicing the request - e.g. navigation request spools up a worker, which is then killed, and a new worker is started up to service a subresource fetch.

The application needs to be able to distinguish and measure the worker startup time.

---

Attribute definition:

workerStart: The workerStart attribute must return a DOMHighResTimeStamp [HR-TIME] with the time immediately before the user agent starts the Worker required to service the request. If the worker process is already available, then this attribute must return the same value as fetchStart.

For processing section update (add new step before 3.5):

If the current browsing context has a registered Service Worker, immediately before a user agent starts the worker process or forwards the request to an existing worker process, record the current time as workerStart.

Does that look reasonable? Anything I'm forgetting? </handwaving>

P.S. Once we iron out the language here, we'll need to make a similar update to Navigation Timing..

/cc @jakearchibald @slightlyoff @KenjiBaheux

[slightlyoff]

Love it.

[toddreifsteck]

This seems reasonable. Adding @aliams to thread.

[vigneshshanmugam]

This is awesome 👍

[yoavweiss]

Sounds great!

What would that value be set to when SW is not installed? identical to fetchStart? Zero? Or should it simply not be there?

[furoshiki]

+1

[igrigorik]

What would that value be set to when SW is not installed? identical to fetchStart? Zero? Or should it simply not be there?

To be consistent with how other attributes are initialized (e.g. secureConnectionStart), initializing to zero when SW is not present seems like the best way to go. This way you also have a clear indicator of whether SW is used or not.

[KenjiBaheux]

This will be quite useful, thanks for working it out.

[KenjiBaheux]

Filed https://code.google.com/p/chromium/issues/detail?id=465640 to track in blink