Interpret result differences between WPT instances

I’m testing a private instance of WPT and wanted to be sure that the agent is behaving in a way I can trust.
I had results that I do not understand :
The queries 5 to 10 (with the long orange bars) are all images and seems to wait more than 1s for the server. The first query to the server (request #5) has a long TTFB, so I guess it’s normal that the 5 other queries are waiting for it. However, the 5 other queries have a “Content Download” time of 0, is it a bug of the agent ?

The waiting time for the server was consistent from test to test, but because it’s a CDN it should not be that long, so I wanted to know if it’s a bug of the installed agent or really a problem coming from the CDN.

So I tested the same page from Dulles and Paris public locations and had very different results
From Paris :
Here the “initial connection” time of the requests 6 to 9 looks reasonable, but the TTFB is very long, actually as long as the “initial connection time” of the test made from my server (coincidence ?).
And the “content download” time is still to 0.

Seeing two locations telling me the CDN takes time to answer, but that the waiting time appears differently, I wanted a last test to know if I could trust the agent or not.

At last, I tested from Dulles, because I guess it’s an agent you trust, and the results are definitely not the same, actually they look normal :
The total time to get the resource is reasonable (300ms to have a small resource from the other side of the planet), the initial connection time of resources 5 to 9 seems to last as long as the TTFB of the resource 4 (due to HTTP keep-alive ?), but the download time is still 0.

Why do I have so much inconsistencies between 3 different agents ?
Can I blame the CDN or not ?

Turn on tcpdump capture and take a look at the actual network data. WebPagetest measures from inside the browser and if the main browser thread is locked up doing something it can make the network requests look artificially long.

The CPU chart doesn’t look like it spiked but the bandwidth line looks like there were no data points between 1 and 2.2s (usually it is sampled at 100ms intervals).

My money is on it not being a problem with the CDN but rather the browser choking on laying out the page and it just happens to be at the same time as the CDN requests.

0ms content download is expected for small resources (under 4Kb or so) since they arrive without additional round trips.

I re-run the tests from the 3 locations (plus two others) with tcpdump on, but the problem disappeared :confused:
I did not knew the capture was made from inside the browser, and yes it could be the browser having problem with parsing the page, because I see there is CSS re-download, plus the stylesheet is not very small (130Ko) and I know the DOM is complex.
But As you say, there is no CPU spike. Anyway I have to monitor this page, so I will think about turning tcpdump on next time I see the problem.

Thanks for the explanation on the 0ms phenomeon