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.