At the rate that HTTP/2 adoption is growing (almost 30% of the top 10 million websites as of July 2018), I wouldn't put much effort into it. HTTP/2 frees you from having to deal with that sort of implementation detail. You need to make sure your host is capable of serving content through HTTP/2 to get the benefits.
From Wikipedia:
Websites that are efficient minimize the number of requests required
to render an entire page by minifying (reducing the amount of code and
packing smaller pieces of code into bundles, without reducing its
ability to function) resources such as images and scripts. However,
minification is not necessarily convenient nor efficient and may still
require separate HTTP connections to get the page and the minified
resources. HTTP/2 allows the server to "push" content, that is, to
respond with data for more queries than the client requested. This
allows the server to supply data it knows a web browser will need to
render a web page, without waiting for the browser to examine the
first response, and without the overhead of an additional request
cycle.
Additional performance improvements in the first draft of HTTP/2
(which was a copy of SPDY) come from multiplexing of requests and
responses to avoid the head-of-line blocking problem in HTTP 1 (even
when HTTP pipelining is used), header compression, and prioritization
of requests. HTTP/2 no longer supports HTTP 1.1's chunked transfer
encoding mechanism, as it provides its own, more efficient, mechanisms
for data streaming.
