I wrote this answer on the topic on Stack Overflow and it’s still pretty relevant.
The benefits of HTTP/2 (and HTTP/3) are primarily for the front end. You’re unlikely to see any real, noticeable benefits over the back end. And, given support is often lacking for these newer protocols I wouldn’t lull myself to enable it with so few gains.
The one interesting point (as noted as an edit at the bottom of my linked answer) is the security issues that can come into play when downgrading HTTP/2 (or 3) at front end to HTTP/1.1 at the backend. These are mostly due to problems in HTTP/1.1 (that 2 and 3 were designed to address) and bad implementations for these edge cases but still, it does give one good reason to avoid HTTP/1.1 at all if possible.
Saying that there definitely is a cost to HTTP/3 at present and I wouldn’t recommend it at the back end (or even the front end you manage to be honest - using via CDNs is the way to go IMHO). It’s still too new (the final RFCs have not even been published yet!) and we’ve spent years optimising TCP in operating systems and throughout the networking stack. The fact that QUIC is in user space rather than in the kernel has many advantages for the future but speed and efficiency are not one and of them. The gap is closing (as this report from Fastly shows) but it’s still there.
So once HTTP/2 becomes ubiquitous (which is happening fast than most would thought!) I’d go for it, but I wouldn’t stress over it for the back end (it is something that’s worth the extra effort on the front end). HTTP/3 is 5 years behind and only just being finalised so even less to recommend it at the back end for now. But I honestly believe QUIC and HTTP/3 is going to be exciting for the future, so definitely one to keep an eye on.
