The relevant QUIC draft recommends a similar window[0], so HTTP/3 looks like it will behave the same. [0] https://datatracker.ietf.org/doc/id/draft-ietf-quic-recovery...
Oh really? Here I thought QUIC would put an end to all this.
Basically QUIC avoids a case where your image #2 waits for image #1 (head of line blocking). It loads both images in parallel streams. In classic HTTP, TCP was asked to load image #1, then it was asked to load image #2 and TCP have to provide responses in order. So even if a single TCP segment of image #1 is lost, image #2 will have to wait. Browsers try to open multiple TCP connection to avoid head of line blocking, but there is a limit to that.
QUIC also combines TCP and TLS handshakes, so initial latency should be improved somewhat
[1] https://datatracker.ietf.org/doc/html/draft-ietf-quic-recove...