Request Size Column in tables & send request timing

My suggestion is to have a Bytes Out column in the summary table, a Bytes Uploaded column in the detail table and a Send Request (time) column (to be put between initial connection and Time to First Byte) on the detailed results page.

The send request time could also be displayed in the waterfall and connection charts.

The data for the bytes out is already in the detailed header information section but not in the tables.

New instrumentation for the send request timing might be required.

I may be able to do a bunch of it but generally there isn’t much visibility into how long it takes to “send” the request. The browser (WinInet really) writes out the data to the IP stack and it gets buffered up and sent out as it can and I don’t have visibility down to the packet level to see the TCP Ack’s.

Usually bytes out isn’t really a limiting factor and tends to be a function of the number of requests and size of cookies (Ajax has the potential to change that though). It would be easy enough to add to the detail table but I’d be hesitant to add it to the summary table unless we see cases where it really makes a difference.

Does not the ratio of downstream:upstream bandwidth exaggerate the impact of the bytes out vs bytes in? This also becomes more significant as the size of the response becomes smaller. So for responses like small gifs/pngs the amount of time sending the request could make up half the response time. This is also particularly true when the request is greater in size than the response such as conditional Gets/304 responses with cookies, in this case the majority of the response time is the time taken for the request.

I guess I’m stumbling around for a metric or two that helps optimise request size, and also lends more fuel to the fire of reason for reducing the number of elements on a page, removing cookies from static content and using far future expires headers. It would also be good to get data from a range of connectivity types to really see the impact.

Maybe a scaling up of the bytes out figure using the ratio max Effective Bandwidth/actual bandwidth (whichever is lower) down : max Effective Bandwidth/actual bandwidth (whichever is lower) up.

For example using the results from:

The bytes out figure for the above test is 44.5KB

Assume ADSL link is 2Mbps down : 256 Kbps up
Assume latency of 50ms for ADSL
Assume MS windows XP and TCP Win of 16KB
eBW = (8000 x 16)/(1.5 x 50) = 1707 Kbps

so downstream is not limited by bandwidth of the pipe but upstream is.
Downstream is limited instead by max Effective Bandwidth
downstream:upstream ratio is 1707:256 or 6.7:1

scaling the bytes out figure up:
44.5 x 6.7 = 298.2 KB

so the cost of sending up 44.5 KB is the same as downloading 298.2 KB.
The bytes in for this page was 330.6 KB

As you can see the figures are very similar a 1.1:1 ratio. If correct does this not make it the time taken to upload the bytes out significant for this page? If summed, would the time taken to upload vs the time taken to download follow roughly the same ratio?

Have my calculations been overly simplistic? Have I plain got it wrong? . I would appreciate being put on the right track if I am.

Does WebPagetest warn if the cookie size is very large, say >1000 bytes? This could force the request to be split over 2 packets increasing the time taken in a request.

Pagetest warns about cookies period (errors if they are set on static content) but doesn’t flag the size of each cookie.

If you look at the DSL test run for the same site: http://www.webpagetest.org/result/090723_1YF9/ by far the limiting factor from having a lot of individual requests is the latency for the request itself. I believe YSlow grades you on the absolute number of requests which is something I could do as well but it always felt very site-specific (a good search site will only have 3-4 requests but a good content site is probably closer to 20).

It’s probably also worth mentioning that the csv links at the top of the results and details pages have the bytes out as part of the tabular results (and a bunch of other data that is useful but not for the summary results).

-Pat