Test result metrics question


I have a question regarding the bandwith/cpu and download metrics from this test:

In particular connection ID 25 from the first view below:

URL: http://www.lenovo.com/ISS_Static/WW/wci3/us/en/fonts/support-masthead/LenovoSupport.ttf
Loaded By: http://www.lenovo.com/us/en/:486
Host: www.lenovo.com
Error/Status Code: 200
Priority: Medium
Client Port: 53723
Request Start: 3.713 s
Time to First Byte: 472 ms
Content Download: 4616 ms <–Indication of bandwith bottleneck?
Bytes In (downloaded): 17.9 KB
Bytes Out (uploaded): 1.3 KB

Scrolling futher down to the cpu/bandwith section, the graph indicates multiple times, close to or flatline of the bandwith graph. What does that graph measure in terms of available cpu and bandwith of that test instance. Thanks you ahead of time.

If you haven’t already, you may want to run your test again and maybe from a different location. From looking at the tcpdump you provided, I am seeing some retransmitted data both to and from the WPT machine.

During connection ID 25 specifically, the HTTP GET for that URL from the WPT machine doesn’t seem to get to the server because no response ever comes. WPT resends the request after the retransmission timer and the server responds with the data.

After that, it looks like about 11KB of data was sent by the server that WPT never got initially because WPT starts requesting for them, and subsequently gets them. So the server must have sent them, but WPT never got them, which suggests that they got lost along the way. This explains the extra time for the content download.

The bandwidth may be a bottleneck, but you shouldn’t be having retransmissions. A bandwidth bottleneck should just slow things down by data taking longer to get to and from WPT. This should not lead to dropped packets on the network. Also, the retransmissions aren’t a whole lot; only around 1 or 2%. However, in your case, specific URL requests are being retransmitted that’s affecting your WPT results.

Since I see the retransmissions both to and from WPT, you may want to test from other locations just in case.

Also, whenever there are retransmissions, you always want to capture some data on the server side, if possible, to verify that you can see the same retransmissions from the server directly.


Thanks, I’ll run some more tests.

So my understanding is, the cpu/bandwith is the measurement of available cpu/bandwith to retrieve the data an not necessarily the cpu/bandwith availability for the request to the page.

My understanding is that CPU & bandwidth metrics tell us how much is being used at a given time. This helps to determine whether a particular HTTP request is CPU or bandwidth intensive or both.

Thanks for the help so foar.

I’ve re-ran tests and come to the conclusion the From: Los Angeles, CA - Chrome - DSL is slow to download the content. Does the official admins or Dev from Webpagetest respond in this forum and can they confirm?

  1. Re-ran tests selecting the fios 20/5 mbs line instead of the dsl for Los Angeles and results were positive. No assets having long download time.

  2. Where running the same tests at the same time using the dsl line it does have content download bottleneck leading me to believe, the node is slow to download this content.

The slow download time for DSL compared to FIOS is expected. The DSL line that WPT is using is only about 1.5Mbps download speed, but FIOS is 20Mbps download speed. So FIOS is about 13 times faster than the DSL.

If you want the site to be faster on DSL, you have to do a number of things - two of the biggest are # of Requests and Bytes In. These should be reduced.

You are not going to get DSL to be anywhere near what you can get with FIOS, given those speeds, but you can get the site faster on DSL by making some changes.

For example, the site gets a “C” for compressed images. You should ensure that as many of your images are being compressed by the server, so that you can reduce the byte size of the data going over the slower DSL connections. This will use up less bandwidth.

If you look at the DSL bandwidth graph, you’re getting very close to using up the whole 1.5Mbps with many of the requests. If you compare that to the FIOS bandwidth graph, you barely get halfway to 20Mbps on the graph. So compressing your images, or better yet, making your images smaller without losing your desired quality should be considered.

The site gets an “F” for caching static content. You need to ensure that the client can cache as much content as possible to reduce the number of connections that are being requested for returning users.

I also see numerous 302 redirects. You need to reduce these as well, to minimize those requests.

In addition, another difference between the DSL and FIOS connections is the latency. DSL = 50ms and FIOS = 4ms. This difference is even worst than the speed difference.This means that with each request, you are adding a minimum of 50ms to your response time (without anything being processed yet) with DSL compared to FIOS, which only adds 4ms. So reducing the number of requests will help a lot by avoiding going across the network and incurring this 50ms penalty.

I can’t speak to any issues with the WPT machine and location itself. Maybe Patrick Meenan or someone like that may speak on that. However, your need to have the site be as fast or near as fast on DSL as it is on FIOS, if that is indeed the case, is not possible due to the bandwidth and latency differences that have little to do with WPT.


Thanks for the reply. My primary concern was the download bottlneck for random assets and it appears related to the Los Angeles node using DSL rather than the endpoint of where the asset was retrieved.


I would try a different agent. While the Los Angeles agent might be closer to your target market, there may be some issues with the machine. I believe the Dulles, VA machines are typically more stable.

The best option is to create your own WebPageTest Installation that you maintain yourself. It is not overly challenging, and has great benefits as no wait times, unlimited runs, and actually more consistent results (in my experience, specifically) than the public versions.

For now, try multiple agents. The file is only 19KB so it should not be taking that long, especially since it is sent from a CDN:

CDN’s Used:
www.lenovo.com : Edgecast

If it consistently is taking that long from multiple agents, then you might want to chat with Edgecast, or check settings on the configuration within Edgecast.

Frankly, I would worry less about a font taking a while to load more about the possible multiple (Single Points of Failure) SPOF on the page and the blocking JavaScript that is in the Critical Render Path.


Just my two cents.

Good luck!


Hey everyone,

Thanks everyone for the replies. I was hoping to get an official response from the sites webmasters.