@vaporeon_ they incur more overhead server-side, which is a consideration worth making, but page loads are (usually) faster with HTTP/2 (it’s pawsible to be worse than HTTP/1.1 when networkning conditions are very poor) and basically always faster with HTTP/3 because multiple simultaneous downloads are multiplexed over a single stream in the latter purrotocols

i don’t think it’s necessesarily a requirement fur a hobbyist, but if you’re serving a lot of outbound connections, HTTP/2 and more so HTTP/3 will save you a lot of bandwidth. if you really, really need fast page loads, you might as well take advantage of them in your infrastructure. the one consideration fur a hobbyist is that HTTP/3 handles poor networking conditions (say, a connection from California to India) much better than the purrevious two purrotocols, so if you want your shit to be reachable globally without giving into the CDNs, HTTP/3’s a nice-to-have

QUIC does indeed use UDP, but HTTP/3 adds TCP’s reliability back to the connection at the application layer..... somehow, so reliability is not a concern. the reason QUIC even got introduced was in fact TCP: because TCP requires packets to be sent in order, the entire connection gets blocked if a packet is lost, which completly undermines the point of muliplexing the connection. (HTTP/1.1 using sepurrate connections purr resource is why it can be faster than HTTP/2 when networking conditions are very poor; one connection dropping a packet does not affect the other connections)