[diocles]

I believe the parent comment was thinking of 1 round trip time.

Typically the TCP initial congestion window size is set to 10 packets (RFC 6928), hence ten packets can be sent by the server before waiting for an ACK from the client.

So under 15kB or so (minus TLS certs and the like) website loading has the minimum latency possible given any other network factors.

[toast0]

TLS certs won't count against your initial congestion window, although there's still a bit of overhead.

If there's a session/ticket resumption, the server won't send a certificate, but it does still need to send a negotiation finished message, and it may likely want to send new tickets (I'm not sure if you can delay that though). In TLS 1.3, the client may send the request as early data, if not the request will come as the beginning of the second round trip, so the congestion window will have opened more for the response.

If it's a full handshake, the certificate is part of the first round trip, and the content is in the second round trip; the cert won't count against the congestion window, because it must have been received before the client sent the http request.

[Karrot_Kream]

Even if the initial congestion window is set to 10 segments, all that does is send out the packets if they're available to send. It still takes less time for the receiver to receive 3 segments than 10 segments, having the congestion window be that wide just means that the sender doesn't need to wait to receive ACKs for those 10 segments (which, to be fair, is faster than sending each packet and waiting for an ACK.)