What does "Blocked" really mean in the Firefox developer tools Network monitoring?

Question

The timing section of the Firefox Network Monitor documentation, "Blocked" is explained as:

Time spent in a queue waiting for a network connection.

The browser imposes a limit on the number of simultaneous connections that can be made to a single server. In Firefox this defaults to 6

Is the limit on the number connections the only limitation? Or is the browser blocked waiting to get a connection from the OS count as blocked too?

In a fresh browser, on a first connection, before any other connection is made (so the limit should not apply here), I get blocked for 195 ms.

Is this the browser waiting for the OS? Was does "Blocked" mean here?

Solution 1

We changed the Firefox setting (about:config) 'network.http.max-persistent-connections-per-server' to 64 and the blocks went away. We changed it back to 6. We changed our design/development method to a more 'asynchronous' loading method so as not to have a large number simultaneous connections. The blocks were mostly loading a lot of png flags for locale settings.

Solution 2

I have a server that takes several seconds to respond, which allowed me to cross-reference the firefox measurement with a wireshark trace. I see that the first SYN is sent out immediately. The end of the "Blocked" time corresponds to when the Server Hello comes back.

I couldn't relate the end of "TLS setup" to any wireshark packet. It extends a few seconds belong the last data that is exchanged on the initial TLS connection.

Bottom line: it doesn't look like the time spent in "Blocked" and "TLS setup" is very reliable, at least in some cases.

My setup has a TLS reverse proxy that forwards the connection with SNI. I'm not sure if that might be related.

Solution 3

Time spent in a queue waiting for a network connection.

The browser imposes a limit on the number of simultaneous connections that can be made to a single server. In Firefox this defaults to 6, but can be changed using the network.http.max-persistent-connections-per-server preference. If all connections are in use, the browser can't download more resources until a connection is released.

Source : https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor

It's very clear that the browser fixes the limit to 6 concurrent connections per server (domains/IP), the OS question is not very relevent.

Solution 4

In my case both waiting for network connection and DNS lookup times were pretty high, up to 2 seconds each, caused significant page load times if the page was loaded for the first time. Firefox was freshly installed without addons and just started with no other opened tabs. I tried on both Ubuntu 18.04 LTS and Ubuntu 19.04 with the same results. Although my ISP doesn't provide support, my router assignes IPv6 addresses. As it turned out the problem was the IPv6 broken network, which forced Firefox to fall back to IPv4 (of course after some time(time-out)). After I turned off the IPv6 support in Linux the requests speeded up significantly. Here is a relavant discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=1452028

View more solutions

Comments

[Beothorn]

But this does not explain why "In a fresh browser, on a first connection, before any other connection is made (so the limit should not apply here), I get blocked for 195 ms." Or does that mean that the highlighted request is not the first on the queue

[Karl.S]

I think that you maybe had another tab opened with background requests sent to google.ca server. It's not very clear in the doc if the limitation is applied to each tab or to the whole browser, you should try with only one tab opened in your browser and see the result.

[Yves Dorfsman]

@Karl.S no, by fresh browser I mean a browser that has just been started and that does not have any other tab or window. I just tried with FF v57 (Quantum), and am still getting "blocked" for 148 ms on the very first request, which eventuall get a 301. The next two are blocked for 109ms and 400ms respectively. Those are the very first 3 requests, I still don't understand why they are blocked.

[binki]

I bet that even when a connection is not in use, the overhead of queueing itself is counted as blocking.

[daniil]

Firefox DevTools member here: This answer is correct (requests being queued based on limits & heuristics; don't get hooked on specific numbers) with the only caveat that a busy main thread (which handles all networking) can also delay request handling.

[scunliffe]

@digitarald if somehow what is consuming the main thread/blocking can be exposed it would be awesome. I have scenarios when no other tabs are open, no addons should be running, no visible requests are active, but I still get ~500ms of blocking before an AJAX request is sent to the HTTPS domain I'm already logged into. e.g. I don't think anything should be blocking, but something is. I need to be able to determine what it is.

[Arnout]

@digitarald I've attempted to give an answer based on actual wireshark traces. Could you comment on that?

[Yves Dorfsman]

@digitarald There's got to be something more to this. "requests being queued based on limits & heuristics" Why would the very first request be blocked? Why would an https request always be block for > 300ms but an http request be blocked for ~50ms? Fresh browser: "google.com" 1st request blocked for 86ms (301) Fresh browser: "https : // google.com" 1st request blocked for 249ms (200) DNS request comes AFTER being blocked. What is FF doing for 249ms? Or even 86ms before even querying DNS?