11 ms·

I'd agree with Billy's comments that this isn't really a real world test. HTTP Archive shows the average number of requests per page is around the 100 mark (I

I'd agree with Billy's comments that this isn't really a real world test. HTTP Archive shows the average number of requests per page is around the 100 mark (I suspect the median is higher) http://httparchive.org/trends.php#bytesTotal&reqTotal http://httparchive.org/trends.php#bytesTotal&reqTotal By using many, very small downloads that probably never fill the congestion window the HTTP case is imposing a huge latency overheard on the test. Looking at the connection view for the HTTP case in WebPageTest there's a HTTPS connection that delays the opening of the other parallel TCP connections - http://www.webpagetest.org/result/141202_VM_dc5d5bd74e3989602ec68126c19c4608/8/details/ http://www.webpagetest.org/result/141202_VM_dc5d5bd74e398960... (for comparison SPDY test is http://www.webpagetest.org/result/141202_6B_a853f2009006b2eca7555549e3517220/ http://www.webpagetest.org/result/141202_6B_a853f2009006b2ec...) In my testing I've seen SPDY / HTTP/2 be anywhere from 35% faster to 5% slower, in my experience key factors to getting it to perform are quality of TLS config, whether the server supports prioritisation and TCP config.

anthumchris 12y ago
Yes, not technically real-world, but hopefully enough to push decision makers to start encrypting. I also added a param to reduce images loaded: http://www.httpvshttps.com/?images=100 http://www.httpvshttps.com/?images=100 From my testing, SPDY was generally 60% faster, but as of now it's been slow. Could be my computer or the server
- youngtaff 12y ago
  Due to the way slow-start works the throughput of a TCP connection increases with use (assuming no packet loss) as the congestion window grows. The HTTP test has images that are ~5KB so after the first round trip for an image the congestion window grows but none of the subsequent requests grow it further, where as in a real world example many of the files would be larger than 5KB the window would grow further an the number of round trips would be reduced. The SPDY example can make use of the ever growing congestion window because the multiplexing will fill it i.e. we'll get the data from more than one image in a single round trip. It's not that the test isn't 'technically real-world' it's that it has (I don't think intentionally) a design that highlights an area where HTTP performs really poorly due to the latency penalty i.e. many very small requests. A more real world test case would mirror a typical page construction with varying file sizes - HTTP Archive can give you some clues here. Have a watch of John Rauser's "TCP and the lower bound of web performance" for more detail on slow start - https://www.youtube.com/watch?v=G6ah2cq4LFY https://www.youtube.com/watch?v=G6ah2cq4LFY

anthumchris 12y ago

Yes, not technically real-world, but hopefully enough to push decision makers to start encrypting. I also added a param to reduce images loaded: http://www.httpvshttps.com/?images=100 http://www.httpvshttps.com/?images=100 From my testing, SPDY was generally 60% faster, but as of now it's been slow. Could be my computer or the server

youngtaff 12y ago
Due to the way slow-start works the throughput of a TCP connection increases with use (assuming no packet loss) as the congestion window grows. The HTTP test has images that are ~5KB so after the first round trip for an image the congestion window grows but none of the subsequent requests grow it further, where as in a real world example many of the files would be larger than 5KB the window would grow further an the number of round trips would be reduced. The SPDY example can make use of the ever growing congestion window because the multiplexing will fill it i.e. we'll get the data from more than one image in a single round trip. It's not that the test isn't 'technically real-world' it's that it has (I don't think intentionally) a design that highlights an area where HTTP performs really poorly due to the latency penalty i.e. many very small requests. A more real world test case would mirror a typical page construction with varying file sizes - HTTP Archive can give you some clues here. Have a watch of John Rauser's "TCP and the lower bound of web performance" for more detail on slow start - https://www.youtube.com/watch?v=G6ah2cq4LFY https://www.youtube.com/watch?v=G6ah2cq4LFY