HTTP/3, standardized as RFC 9114 in 2022, runs HTTP over QUIC. Major browsers and CDNs support it, and a certain share of actual requests is exchanged over HTTP/3. Short URL redirect performance varies with HTTP version, so HTTP/3 support is also something short URL services consider.
Where HTTP/3 helps short URLs is the handshake time of the initial connection. Up to HTTP/2, TCP connection setup and the TLS handshake run separately and take multiple round trips before data can flow, whereas HTTP/3 over QUIC combines them so the initial connection takes one round trip, and a reconnection to a known server can send data with 0-RTT. A short URL click triggers DNS resolution, TLS handshake, redirect response, and a second connection to the destination, so multiple round trips compound. Adopting HTTP/3 trims those handshake round trips and lowers initial connection latency, and on mobile networks with high latency or packet loss the difference can be noticeable.
3xx semantics do not change in HTTP/3. The behaviors of 301, 302, 307, and 308 are identical to HTTP/2. Through the HTTP Alt-Svc header and the DNS HTTPS record, a server can advertise HTTP/3, so later connections can switch to HTTP/3. Pairing this with a CDN is another setup: CloudFront (since August 2022), Cloudflare, and Fastly support HTTP/3, and redirects completed at the edge need no origin round trip.
0-RTT carries a replay risk, so it is limited to requests with safe methods such as GET. Short URL redirects are GET requests, so 0-RTT can apply in some cases, but even safe methods can have side effects, so the design assumes that click logging is not duplicated on replay. Some corporate LANs block UDP 443; those clients fall back to HTTP/2 over TCP, and the fallback decision can make the first connection slower rather than faster. Advertising "Alt-Svc: persist=1" or using HTTPS DNS records can preempt that.