Add a network request phase for "response waiting to be processed"

[mstange]

cc zoepage digitarald

Compare the two network tracks in this profile: https://perfht.ml/2EejwGq

The network track in the content process looks a lot busier, even though it's listing the same requests. What happens is that we draw the boxes until the event for the completion of the request has been processed on the main thread. The main thread in the content process is a lot busier than the main thread in the parent process, so network request completion waits longer until it's being acknowledged in the main thread, and that results in longer boxes.

For a specific load that shows the difference between the two processes, compare load 53 (timeline.2.1.0.js) in each process's network chart tab.

I think it would be good to make this waiting time explicit in the network chart and in the timing details pane for a request. It's similar to the "Waiting" and "Blocked" phases, but it happens later - it happens after the full response has been received. So I don't know what to call it.

┆Issue is synchronized with this Jira Task

[zoepage]

Related to #1339 as we want to display the idle time in the queued topic.
(correct @digitarald ?)

[mstange]

Is this time what's called "queued"? Or is "queued" something else? I thought queued happened before the request is sent out over the network, not after the response has been received.

[past]

There has been a related discussion in the web-perf WG. Perhaps we could use "stalled" for this latter delay to distinguish it from "queued" which would occur earlier in the load.

[zoepage]

As far as I understand "queued" is the duration of everything until the request starts, so e.g. domainLookup, but I don't know if this is correct?

// edit
So, having display of HAR timing would be also helpful here?

[mstange]

It seems like the word "stalled" is already used with a different meaning (waiting to start the request due to TCP connection limit), as per the text in w3c/resource-timing#169. The discussion in w3c/resource-timing#164 doesn't mention any phase after responseEnd, as far as I can see. But the phase that I'm talking about occurs after responseEnd.

[mstange]

"Target busy", "Target blocked" might be ok names.

[digitarald]

Maybe a good mapping is to apply the same wording to request and response. This way we are not trying to give special meaning to various meanings of queued, stalled, etc.

Request Queue Time: Time from request being created to necko handling it (depends on connection limits, priorities, piping and busy main thready event queue).
Response Queue Time: Time from full response received in Necko to main thread starting to handle the response (depends on busy main thread event queue).

Not covered here is the JS aspect of load event handler delay for XHRs (or maybe even image decoding?):
Response Handler Delay: Time from main thread done handling a response to the JS event handler being called (depends on busy content process event queue)

How do these assumptions and conclusions sound?

[mstange]

When you say "main thread", are you referring to the main thread of the parent process or the main thread of the content process?