elaborate on stalled or blocked stage in specs

[jasonslyvia]

Devtools of modern browsers all got this handy waterfall graph for each resource timing, although well explained in each vendors' documentation (google, firefox), I think it will help more people to get the gist of how resource is loaded if we add some non-normative section in the spec to elaborate on the stalled or queued duration.

If this seems to be feasible, I'd like to send a pull request regarding this issue.

screenshot of resource timing graph on Google Chrome

screenshot of resource timing graph on Mozilla Firefox

[igrigorik]

We don't expose "blocked" time in RT today, why/how would a non-normative section be helpful, if that data is not exposed?

For context, some previous discussions on this topic: https://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0000.html

[jasonslyvia]

I believe steve has covered pretty much of the reason why we should do this in his thread.

The above breakdown graph of a resource timing is so popular that I've been seeing many engineers (even senior ones without much knowledge of web performance) who actually thinks that loading a resource just consists of the stages illustrated in the graph, and often get confused why redirect + appcache + dns + tcp + connect + request + response not equals to duration.

If we don't expose blocked time (which I failed to see a consensus in the mailing list whether we will expose it or not), I believe a non-normative note in the spec will help more people understand why their resource is loading slowly.

btw, I'm new to the Web Performance group and I'm not sure whether the mailing list or Github issue is suitable for discussing this kind of issue.

[yoavweiss]

Discussing this on the issue is fine. I have no objections for a note (even if, in an H2 world, "stall" time is not necessarily relevant, at least with current implementations).

[jasonslyvia]

If I understand correctly, even with H2 implemented, loading a resource might still get stalled or blocked for reasons other than TCP connection limit, as stated in google chrome's documentation, some sort of vendor-specific resource loading priority mechanism?

[yoavweiss]

Implementations are free to continue queueing in H2, it's just not as common in current ones.

[nicjansma]

@jasonslyvia I agree that the nebulous blocked/queued/stalled period(s) can be confusing when looking at ResourceTiming data, and when seeing how existing timestamps fit into the handy RT diagram.

In practice, I think it's not just the TCP connection limit (called Queued/Stalled in Chrome and Blocked in FF), but can be other additional "missing" times between phases due to browser quirks or stalls in processing.

When we're gathering RUM data, we're actually making sure to collect all individual phase start/end timestamps (e.g. both connectStart and connectEnd) instead of just the difference (connectEnd-connectStart) because we've seen so many cases where the combined phases don't add up to duration.

Here's the simplistic calculation we're using to calculate some part of "blocking" time:

var blockingTime = 0;
if (res.connectEnd && res.connectEnd === res.fetchStart) {
    blockingTime = res.requestStart - res.connectEnd;
} else if (res.domainLookupStart) {
    blockingTime = res.domainLookupStart - res.fetchStart;
}

The above relies on same-origin or TAO-powered resources, and doesn't account for other "stalled" phases.

I don't think we can realistically add a blockedStart or blockedEnd because there may be several places where a resource is blocked. Similarly, I don't think a total blocked calculation would add much, since it can be calculated from the existing timestamps.

Would you be able to share the non-normative text you're thinking about? I agree that highlighting this issue can be useful to new developers that are first looking at bulk ResourceTiming data.

[yoavweiss]

Marking as L3 as this doesn't seem blocking.
@jasonslyvia - Do you an idea for a note that will clarify the current situation to developers?

[jasonslyvia]

I've opened #169 and really glad if you can take a look