HTTP/2 & HTTP/3
Run curl --http3 https://example.com and the whole page rides one UDP flow; drop a single segment on the older connection and every asset behind it stalls at once. Same request, two transports, two different failure shapes.
- ▸One lost segment freezes an entire HTTP/2 connection at once, because every reply on it rides one ordered line.
- ▸Move the same page to HTTP/3 and the identical loss stalls only the one reply that lost data.
- ▸A download survives a phone jumping from wifi to cellular, because HTTP/3 names the connection, not the address.
Your page needs four files: the HTML, a stylesheet, a hero image, one script. Send all four requests down a single connection and the replies come back in the order they were asked for, one finishing before the next may start. Make the hero image slow and the stylesheet sitting behind it waits too, even though its bytes were ready the whole time. The front of the line holds up everything behind it.
This is why a browser never uses just one connection to a server. It quietly opens several, commonly around six, and spreads the requests across them so a slow reply only blocks its own line. Six lines instead of one is a workaround, not a fix: the server still answers each line strictly in order, and every extra connection costs its own setup before a single byte of your page can move.