CODEWITHSUNDEEP
google-chromegoogle-chrome-devtools
Drit
Drit

Reputation: 66

High "Receiving Time" for HTTP Responses below 500 bytes in Chrome Devtools

While using devtools Network tab on Chrome 15 (stable) on Windows 7 and Windows XP, I am seeing cases where "receiving" time for an HTTP response is >100ms but the response is a 302 redirects or small image (beacons) - with a payload below 500 bytes (header+content).

Capturing the TCP traffic on Wireshark clearly shows the server sent the entire HTTP response in a single TCP packet, so receiving time should have been 0. A good example is CNN homepage, or any major website that has a lot of ads and tracking beacons.

This brings up a couple of questions:

  1. What is defined as "receiving" in chrome devtools? is this the time from 1st packet to last packet?
  2. What factors in the client machine/operating systems impact "receiving" time, outside of the network/server communication?

In my tests I used a virtual machine for Windows XP, while Windows 7 was on a desktop (quad core, 8gb ram).

Upvotes: 4

Views: 2508

Answers (2)

Jarrod
Jarrod

Reputation: 1485

The Nagle Algorithm and the Delayed ACK Algorithm are two congestion control algorithms that are enabled by default on Windows machines. These will introduce delays in the traffic of small payloads in an attempt to reduce some of the chattiness of TCP/IP.

Delayed ACK will cause ~200ms of additional "Receiving" time in Chrome's network tab when receiving small payloads. Here is a webpage explaining the algorithms and how to disable them on Windows: http://smallvoid.com/article/winnt-nagle-algorithm.html

Upvotes: 1

Alexander Pavlov
Alexander Pavlov

Reputation: 32296

  1. The "receiving time" is the time between the didReceiveResponse ("Response headers received") and didReceiveData ("A chunk of response data received") WebURLLoaderClient events reported by the network layer, so some internal processing overhead may apply.
  2. In a general case, keep in mind that the HTTP protocol is stream-oriented, so the division of data between TCP packets is not predictable (half of your headers may get into one packet, the rest and the response body may get into the next one, though this does not seem to be your case.)
  3. Whenever possible, use the latest version of Chrome available. It is likely to contain less errors, including the network layer :-)

Upvotes: 1

Related Questions