spec what requestStart, responseStart, and responseEnd should represent when service worker is involved

[wanderview]

I'm trying to improve the PerformanceRequestTiming support in firefox when a request is intercepted by a service worker. I've implemented workerStart, but its a bit unclear what requestStart, responseStart, and responseEnd mean in this context.

Looking at the output from chrome it seems like these are being set:

fetchStart:1.9050000000000002
requestStart:2.325
responseEnd:6.73
responseStart:5.495000000000001
startTime:0
workerStart:2.32

Here requestStart is slightly after workerStart. Is this when respondWith() was called?

The responseStart is a few milliseconds later. Does this measure when the respondWith() promise resolves?

I assume responseEnd is when the synthesized body is complete.

Also, the WPT test here:

https://github.com/w3c/web-platform-tests/blob/master/service-workers/service-worker/resource-timing.https.html#L15

Wants workerStart to occur before fetchStart, but that is not what chrome is doing for this request. Also, this requirement was a bit awkward to implement in firefox. We trigger workerStart after we create our network channel, so its more natural for fetchStart to occur first. I plan to relax this requirement in the WPT test.

[wanderview]

@mattto Do you have any input here? I'd like to be compatible if we can, but these other values seem under specified.

[wanderview]

For subresource requests chrome seems to generate workerStart before fetchStart, but the reverse for navigation requests.

Is there any guaranteed ordering between these two?

[wanderview]

Actually, I decided to bring the fetchStart up to workerStart in gecko. So I don't need to change the WPT test, but it seems chrome's behavior does not always conform to the expected test behavior here. It would be nice to clarify what these events mean.

[mfalken]

Yes I've seen some strange behavior from Chrome. I think our workerStart is created when the renderer process (i.e., web content process) has begun starting up the worker thread, but service worker startup actually starts before that in the browser process. I wouldn't be surprised if there are things to improve here both spec and implementation wise.

I wrote a bit about this before at https://groups.google.com/a/chromium.org/d/msg/blink-dev/ck9M6Ev21lo/oj8kK098CAAJ

[wanderview]

Maybe we can quickly sketch "what does each timing value mean in each browser" at TPAC. Even if its not spec'd it would be nice to put it in this issue.

Should I leave the "workerStart >= fetchStart" in the test for now?

Note, I am expanding the test with:

    assert_greater_than_equal(entry.responseStart, entry.fetchStart, description);
    assert_greater_than_equal(entry.responseEnd, entry.responseStart, description);
    assert_greater_than(entry.duration, 0, description);

[mfalken]

Sounds good to discuss at TPAC (but I'd have to prepare to be able to share accurate information). Maybe better to focus on what the timing values should mean.

Makes sense to me to assert fetchStart < workerStart. cc/ @igrigorik @spanicker

[mfalken]

I mean yea workerStart >= fetchStart makes sense to me.

[wanderview]

I mean yea workerStart >= fetchStart makes sense to me.

Honestly I don't really know what "fetchStart" means for a synthesized response. I'm making our values conform to this, but I don't know if they make sense.

[wanderview]

I guess it would be useful to know what sites interpret these values to mean today. @n8schloss do you have any insight here?

[wanderview]

Just thinking about it a bit I would recommend the following:

• workerStart means when we decide to intercept and may or may not need to spin up worker. (As currently defined AFAICT.)
• requestStart means when we first the FetchEvent in the worker thread
• responseStart means when the respondWith() promise resolves
• responseEnd means when the respondWith() Response body completes

And I guess fetchStart == workerStart.

Any thoughts?

[igrigorik]

• workerStart means when we decide to intercept and may or may not need to spin up worker. (As currently defined AFAICT.)
• requestStart means when we first the FetchEvent in the worker thread
• responseStart means when the respondWith() promise resolves
• responseEnd means when the respondWith() Response body completes

nod.. I think those make sense.

And I guess fetchStart == workerStart.

The delta between workerStart and fetchStart is meant to capture the worker startup time. They are not the same, unless worker is already ready or there is no worker to start...

/cc @toddreifsteck

[wanderview]

The delta between workerStart and fetchStart is meant to capture the worker startup time. They are not the same, unless worker is already ready or there is no worker to start...

That is not what the spec says for step 1.2 here:

https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-workerstart

"Immediately before the user agent runs the worker" should be before the browser starts its thread. Assuming "run the worker" refers to the current "run service worker" algorithm here:

https://w3c.github.io/ServiceWorker/#run-service-worker-algorithm

The thread isn't created until step 4 there.

[wanderview]

I just implemented workerStart based on the interpretation in #119 (comment). If this is wrong, it would be great to get clarification. @mattto, what does chrome do here?

[wanderview]

I think I misunderstood #119 (comment).

I think my problem is I don't understand what fetchStart is intended to be in a service worker interception case. Is it the time when we fire the FetchEvent?