Am scris acest raspuns pe subiect pe Stack Overflow și este încă destul de relevant.
Beneficiile HTTP/2 (și HTTP/3) sunt în primul rând pentru front-end. Este puțin probabil să vedeți beneficii reale și vizibile față de back-end. Și, dat fiind că suportul este adesea lipsit pentru aceste protocoale mai noi, nu m-aș liniști să-l activez cu atât de puține câștiguri.
Singurul punct interesant (așa cum este menționat ca o modificare în partea de jos a răspunsului meu legat) este probleme de securitate care pot intra în joc atunci când faceți downgrade HTTP/2 (sau 3) din front-end la HTTP/1.1 din backend. Acestea se datorează în mare parte problemelor în HTTP/1.1 (pe care 2 și 3 au fost proiectate să le rezolve) și implementărilor proaste pentru aceste cazuri marginale, dar totuși, oferă un motiv bun pentru a evita HTTP/1.1, dacă este posibil.
Spunând că există cu siguranță un cost pentru HTTP/3 în prezent și nu l-aș recomanda la back-end (sau chiar la front-end, reușiți să fiți sincer - utilizarea prin intermediul CDN-urilor este calea de a merge IMHO). Este încă prea nou (RFC-urile finale nici măcar nu au fost publicate încă!) și am petrecut ani de zile optimizând TCP în sistemele de operare și în întreaga stivă de rețea.Faptul că QUIC este mai degrabă în spațiul utilizatorului decât în kernel are multe avantaje pentru viitor, dar viteza și eficiența nu sunt una dintre ele. Decalajul se reduce (ca acest raport de la Fastly arată) dar este încă acolo.
Așa că, odată ce HTTP/2 devine omniprezent (ceea ce se întâmplă mai repede decât s-ar fi crezut cei mai mulți!), aș opta pentru el, dar nu m-aș stresa pentru el pentru back-end (este ceva care merită suplimentar efort pe partea din față). HTTP/3 este cu 5 ani în urmă și abia în curs de finalizare, așa că și mai puțin să-l recomand deocamdată. Dar sincer cred că QUIC și HTTP/3 vor fi interesante pentru viitor, așa că cu siguranță unul pe care să-l urmăriți.
