How many bytes in one round-trip for an HTTP/2 browser request over mobile networks?

I’m working on a site with the goal of being as fast as possible. This goal requires letting mobile clients make the initial HTTP request in one round-trip. (HTTP/2’s HPACK should take care of subsequent requests for the same page.)

The conventional wisdom is that 14 kilobytes of compressed response is as much as you can expect out of the first round-trip for a web page (because of TCP Slow Start), but similar calculations as that theory’s don’t produce similar results when testing.

My target connection has the following characteristics:

3rd-generation cellular data protocol (3G)
200ms latency (400ms RTT)
400Kb/s maximum download bandwidth
300Kb/s maximum upload bandwidth
0% packet loss, at least for the purposes of this question
HTTP/2 over TLS
Assume Android Chrome for the client

Ultimately, I want to set performance goals for how big the app-controllable request headers can be; mainly Etag and Cookie. (I can’t really control Referer and such, but at least they have a known maximum size in practice.)

You can’t do one round trip HTTP/2 pages (nor HTTPS pages, and pretty much never could even with HTTP/1.1).

This is because the TLS handshake requires at least one round trip (though TLSv1.3 does have a 0-RTT repeat handshake that is not usually supported by browsers and servers).

HTTP/2 requires further messages on top which, while they do not require to be acknowledged (so no round trip technically) will result in TCP acknowledgements, so the congestion window (CWND) will have increased beyond 14Kb in this instance. Additionally as you start to stream the first response it’s TCP packets will also be acknowledged increasing the CWND further.

I recently wrote a blog post on this: https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/

So how much do you really have to play with for that first response if it’s not 14KB? Well that’s impossible to realistically say because it very much depends on the TCP stacks (and TLS and HTTP/2 stacks) on each side. My advice is not to obsess with this number and just deliver your website in as little data as possible. In particular don’t worry if you are delivering 15KB or 16KB as you don’t have to kill yourself to get under this 14KB magic number.

Saying that while Cookies can be large (though eTags typically are not), they are not typically more than a KB or two. So if you are trying to make your space savings there then you probably are looking in the wrong place - or have a really super optimised site where these headers are the last place to optimise!

Recommended topics

Hot tags