> Also HTTPS requires two additional round trips before it can do the first one — which gets us up to 1836ms!
Doesn't this sort of undo the entire point of the article?
If the idea was to serve the entire web page in the first roundtrip, wouldn't you have lost the moment TLS is used? Not only does the TLS handshake send lots of stuff (including the certificate) that will likely get you over the 14kb boundary before you even get the chance to send a byte of your actual content - but the handshake also includes multiple request/response exchanges between client and server, so it would require additional roundtrips even if it stayed below the 14kb boundary.
So the article's advice only holds for unencrypted plain-TCP connections, which no one would want to use today anymore.
The advice might be useful again if you use QUIC/HTTP3, because that one ditches both TLS and TCP and provides the features from both in its own thing. But then, you'd have to look up first how congestion control and bandwidth estimation works in HTTP3 and if 14kb is still the right threshold.
Modern TLS adds one round trip, unless you have TCP fast open or 0-RTT resumption; neither of which are likely in a browser case, so call it 1 extra round trip. Modern TLS includes TLS 1.3 as well as TLS 1.2 with TLS False Start (RFC 7918, August 2016).
And TLS handshakes aren't that big, even with certificates... Although you do want to use ECC certs if you can, the keys are much smaller. The client handshake should fit in 1-2 packets, the server handshake should fit in 2-3 packets. But more importantly, the client request can only be sent after receiving the whole server handshake, so the congestion window will be refreshed. You could probably calculate how much larger the congestion window is likely to be, and give yourself a larger allowance, since TLS will have expanded your congestion window.
Otoh, the important concept, is that early throughput is limited by latency and congestion control, and it takes many round trips to hit connection limits.
One way to apply that is if you double your page weight at the same time you add many more service locations and traffic direction, you can see page load times stay about the same.
Doesn't this sort of undo the entire point of the article?
If the idea was to serve the entire web page in the first roundtrip, wouldn't you have lost the moment TLS is used? Not only does the TLS handshake send lots of stuff (including the certificate) that will likely get you over the 14kb boundary before you even get the chance to send a byte of your actual content - but the handshake also includes multiple request/response exchanges between client and server, so it would require additional roundtrips even if it stayed below the 14kb boundary.
So the article's advice only holds for unencrypted plain-TCP connections, which no one would want to use today anymore.
The advice might be useful again if you use QUIC/HTTP3, because that one ditches both TLS and TCP and provides the features from both in its own thing. But then, you'd have to look up first how congestion control and bandwidth estimation works in HTTP3 and if 14kb is still the right threshold.