Incorrect display of "Time to First Byte" in waterfall ?!

Support
1

Hello!

We would like to measure the responsetimes of a webpage which has been optimized for mobile devices (e.g. iPad).

Currently we use Chrome 23 and a 2.8 Agent which is configured to a certain User-Agent like this (wptdriver.ini):

options=‘–load-extension=“%WPTDIR%\extension” --user-data-dir=“%PROFILE%” --user-agent=“Mozilla/5.0(iPad; U; CPU
iPhone OS 3_2like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314
Safari/531.21.10” --no-proxy-server’

Everything works ok and we get proper results.
The only problem we noticed shows up in the corresponding waterfalls:

The size of the bars for the first request does not match the calculated total time of the request. In detail: “The Time to First Byte” bar looks like its size has been shortened by the sum of “Start Offset”, “Initial Connection” and “SSL Negotiation” as you can see in the attached picture.

It is quite confusing, because the bars do not represent the measured times anymore.

The problem does not occur when we measure a different (normal) webpage (Chrome)
The problem does not occur when we measure the webpage on weppagetest.org (Chrome)
The problem also occurs when the User-Agent is not set (wptdriver.ini, Chrome)
The problem does not occur, when we measure the webpage using Firefox.

Any ideas what might be the problem?

Thanks in advance for your answer.

Regards,

Kai

2

Try grabbing the latest agent just in case it is something that was fixed after the 2.8 release (will at least make sure you are running the same agent as the public instance) : https://sites.google.com/a/webpagetest.org/docs/private-instances#TOC-Updating-Test-Agents

3

I updated the agent, but the problem still occurs (see attached image).

Do you have any further ideas what might cause the problem?

Thanks in advance.

Regards,

Kai

4

I had a second look at the problem and noticed, that the “Start Offset” seems to affect the confusing display of the waterfall.

Have a look at the attached picture…

I tried to compare the HAR Files from the webpagetest.org measurement vs. the HAR File from our server.
Afterwards I tried to understand how the “Start Offset” is calculated.
I think it works like this:

{“log”:{“version”:“1.1”,
“creator”:{“name”:“WebPagetest”,
“version”:“1.8”},
“pages”:[{“startedDateTime”:“2012-12-04T09:50:40.000+00:00”,(A)
“title”:"Run 1, First View for ",
“id”:“page_1_0”,
“pageTimings”:{“onLoad”:6098,
“onContentLoad”:-1,
“_startRender”:2118}},

{“startedDateTime”:“2012-12-04T09:50:56.000+00:00”,
“title”:"Run 1, Repeat View for ",
“id”:“page_1_1”,
“pageTimings”:{“onLoad”:1570,
“onContentLoad”:-1,
“_startRender”:1563}}],
“browser”:{“name”:“Google Chrome”,
“version”:“23.0.1271.95”},

“entries”:[

{“pageref”:“page_1_0”,
“startedDateTime”:“2012-12-04T09:50:41.308+00:00”,(B)
…
(B) –(A) =1.308 sec

If you look at the picture, the TTFB bar at wpt.org startes exactly at the “Start Offset”, which is 1,308 sec.
In our case the “Start Offset” is 0,220 sec and I think the TTFB also is painted from 0,220 sec to 2,371 sec. It looks like the problem is, that because the “Start Offset” is smaller then the value of “connect”, the TTFB bar is partly covered by the bars for “Initial Connection” and “SSL Negotiation”.
If that is the case, the total time calculated (3394 ms) would be wrong and should be Start-Offset + TTFB = 2371 sec.

What do you think about this?

Thanks in advance.

Regards,

Kai

5

Sorry, are you sure you are running the latest agent version? You can verify by checking /getTesters.php

You need to be running >= 339 to have the fixes to Chrome’s SSL reporting.

If you have an older version of the agent on the server in work/update it’s possible that it auto-reverted after you manually updated.

6

You were right.
The agents got manually updated to 2.8 and there were still some old files (<339) in the “work/update” folder on the server.
Thanks a lot for your help.
Regards,

Kai