Comparing HTTP/3 vs. HTTP/2 Performance
blog.cloudflare.com
Comparing HTTP/3 vs. HTTP/2 Performance
1–10 of 84 posts
Re: Comparing HTTP/3 vs. HTTP/2 Performance
#2> With HTTP/2, any interruption (packet loss) in the TCP connection blocks all streams (Head of line blocking).
This issue is really noticeable on my crappy home mobile internet when loading web pages, in combination with the timeout being absurdly long for reasons I don't understand.
Re: Comparing HTTP/3 vs. HTTP/2 Performance
#3> With HTTP/2, any interruption (packet loss) in the TCP connection blocks all streams (Head of line blocking). This issue is really noticeable on my crappy home mobile internet when loading web pages, in combination with the timeout being absurdly long for reasons I don't understand.
Same here. My Internet was so bad the other day that loading a web article that was already in my cache would hang indefinitely. I enabled "Offline mode" in my browser, and it loaded the article instantly. On macOS, launching Firefox or Chrome would just hang indefinitely (without displaying a window) when in lie-fi, presumably checking for updates or something.
I know there's a push to get software to support an offline mode, but I wish there was a similar push to improve software when in lie-fi.
Re: Comparing HTTP/3 vs. HTTP/2 Performance
#4TLDR: still slightly slower, but "very excited"
Re: Comparing HTTP/3 vs. HTTP/2 Performance
#5So, as far as the results: In their synthetic benchmarks, they find negligible to no improvement:
> For a small test page of 15KB, HTTP/3 takes an average of 443ms to load compared to 458ms for HTTP/2. However, once we increase the page size to 1MB that advantage disappears: HTTP/3 is just slightly slower than HTTP/2 on our network today, taking 2.33s to load versus 2.30s
And in their closer to real world benchmarks, they find no improvement, instead some negligible degradation.
> As you can see, HTTP/3 performance still trails HTTP/2 performance, by about 1-4% on average in North America and similar results are seen in Europe, Asia and South America. We suspect this could be due to the difference in congestion algorithms: HTTP/2 on BBR v1 vs. HTTP/3 on CUBIC. In the future, we’ll work to support the same congestion algorithm on both to get a more accurate apples-to-apples comparison.
As a developer of web apps, I will personally continue to not think that much about HTTP/3. Perhaps in the future network/systems engineers will have figured out how to make it bear fruit? I don't know, but it seems to me of unclear wisdom to count on it.
Re: Comparing HTTP/3 vs. HTTP/2 Performance
#6So, as far as the results: In their synthetic benchmarks, they find negligible to no improvement: > For a small test page of 15KB, HTTP/3 takes an average of 443ms to load compared to 458ms for HTTP/2. However, once we increase the page size to 1MB that advantage disappears: HTTP/3 is just slightly slower than HTTP/2 on our network today, taking 2.33s to load versus 2.30s And in their closer to real world benchmarks,…
Their own conclusion seems odd to me:
> Overall, we’re very excited to be allowed to help push this standard forward. Our implementation is holding up well, offering better performance in some cases and at worst similar to HTTP/2. As the standard finalizes, we’re looking forward to seeing browsers add support for HTTP/3 in mainstream versions.
I feel like the conclusion should be "Hypothetical advantages of HTTP/3 still not realized," but they are "We're excited to be working on this", with no mention of... why. Like, why isn't HTTP/3 resulting in expected advantages; what might be changed to change this; what are you going to do to try to realize actual advantages to 'push the standard forward'? It seems like a standard for the sake of saying you have done something and have a standard, if there aren't any realized advantages, no?
Re: Comparing HTTP/3 vs. HTTP/2 Performance
#7This does not mention if the tests also simulated and measured packet loss.
With a good network connection with little packet loss, I wouldn't expect much benefit to /3. Especially since all the server and client implementations are immature and in user space without kernel support.
The benefits should show up with (poor) mobile connections.
Re: Comparing HTTP/3 vs. HTTP/2 Performance
#8So, as far as the results: In their synthetic benchmarks, they find negligible to no improvement: > For a small test page of 15KB, HTTP/3 takes an average of 443ms to load compared to 458ms for HTTP/2. However, once we increase the page size to 1MB that advantage disappears: HTTP/3 is just slightly slower than HTTP/2 on our network today, taking 2.33s to load versus 2.30s And in their closer to real world benchmarks,…
I'm certainly no network engineer, but my understanding is that HTTP/3 really shines in poor networking conditions. HTTP/2 was a massive improvement on HTTP/1.2 that had some really impressive stats to back it up. HTTP/3 isn't going to have that. Being on-par with HTTP/2 in excellent conditions is expected. The little game animation backs that up - if all the data arrives in both HTTP/2 & HTTP/3 then its a wash. I'm certainly not aware of any HTTP/3 browser implementations on mobile. I believe that is when you'll see the improvements. Although, I've also read that without kernel and NIC-level support for HTTP/3, its supposed to be a large CPU and battery drain. So it might be awhile before the real benefits of HTTP/3 are fully realized. Regardless, its fascinating to watch.
Re: Comparing HTTP/3 vs. HTTP/2 Performance
#9So, as far as the results: In their synthetic benchmarks, they find negligible to no improvement: > For a small test page of 15KB, HTTP/3 takes an average of 443ms to load compared to 458ms for HTTP/2. However, once we increase the page size to 1MB that advantage disappears: HTTP/3 is just slightly slower than HTTP/2 on our network today, taking 2.33s to load versus 2.30s And in their closer to real world benchmarks,…
Based on Google's earlier testing HTTP/3 excels in poor-performing networks where dropped packets are more likely or more costly. Cloudflare's blog didn't mention this point at all.
> On a well-optimized site like Google Search, connections are often pre-established, so QUIC’s faster connections can only speed up some requests—but QUIC still improves mean page load time by 8% globally, and up to 13% in regions where latency is higher.
https://cloudplatform.googleblog.com/2018/06/Introducing-QUI...
Another summary: https://kinsta.com/blog/http3/
Older Cloudflare blog: https://blog.cloudflare.com/http3-the-past-present-and-futur...
Re: Comparing HTTP/3 vs. HTTP/2 Performance
#10This does not mention if the tests also simulated and measured packet loss. With a good network connection with little packet loss, I wouldn't expect much benefit to /3. Especially since all the server and client implementations are immature and in user space without kernel support. The benefits should show up with (poor) mobile connections.
Thanks for pointing this out! I really wish the blog would explain that better. /3 will really shine where connection has degradation.
For me the most exciting part is the seamless network switching potential of /3 on mobile devices