2

I am able to get Selenium driving Starting ChromeDriver 2.23.409699 via browsermob-proxy-2.1.2 and can access the HAR data however the timings seem strange particularly with SSL sites.

For example the first fetch is made to the website itself, which as per the timings takes:

@ 512ms from start the first request goes out to page:

  • Connect: 1,306ms
  • SSL: 1,293ms
  • Send: 1ms
  • Wait: 16ms
  • Receive: 6ms

url1

Then @ 576ms (64ms after page) a second request to referenced style sheet goes out:

url2

However as far as i can tell, the timings overlap in that request #2 goes out whilst the page is still waiting to connect (SSL and connection). Graphing it below shows them overlapping.

graph

Any ideas what i am doing wrong or misunderstanding?

morleyc
  • 2,228
  • 9
  • 35
  • 85

1 Answers1

0

To summarize your data:

  • you start the capture
  • there is one request at 512ms to the main HTML page
  • there is another request at 576 ms to the stylesheet. This happens before the first request has finished

It is unlikely that a SSL handshake takes a whole 1293 ms. http://www.semicomplete.com/blog/geekery/ssl-latency.html lists times from 68ms to 408 ms for the complete transaction, including handshake. The same for retrieving https://www.mozilla.org/en-US/about/:

timing web requests mozilla/about

As a guess, Google did something clever with Chrome again.

  1. It starts the TCP+SSL handshake,
  2. then starts downloading the main HTML.
  3. At the same time the HTML arrives, it is parsed, and
  4. as soon as a stylesheet reference is encountered, this is downloaded as well (before the end of the HTML transfer).

These need to happen in separate threads for this optimization to work, but it could well reduce web download time (which seems to be one of Chrome's main aims).

serv-inc
  • 29,557
  • 9
  • 128
  • 146