[geofft]

Is there a good way to make a website that's available over both HTTP/1.1 and HTTP/2 and does the right thing in both cases? I feel like it'll be many years before I can design a website that's available over HTTP/2 only.

For instance, is there an asset pipeline that will concatenate and minify all my JS for HTTP/1.1 clients, but minify my JS separately for HTTP/2 ones, and build versions of my HTML page that references the two different assets depending on which HTTP protocol is in use?

[jomohke]

I don't think the complexity would be worth it in most cases.

The article is misleading on this, but those HTTP/1.1 best practices aren't slower when served over HTTP2. HTTP2 will still be faster than HTTP/1.1.

- Spriting and concatenation will not be worse under HTTP/2, just (mostly) unnecessary.

- Splitting content across multiple domains will be 'harmful', in that you're enduring multiple TCP handshakes instead of one. But this is no worse than HTTP/1.1

- Minification is unchanged. It will still decrease the download size. Although I sometimes find that the difference after compression is trivial on many modern sites, so is often not worth the decrease in readability/debuggability.

[geofft]

Sure, but as long as I'm supporting a good chunk of HTTP/1.1 users, then I don't get the benefits of the HTTP/2 architecture, right?

I could buy that what I should do is wait a few years, until the majority of my users are HTTP/2 instead of HTTP/1.1, and then optimize everything for HTTP/2 and still work (slowly) on HTTP/1.1. But at the moment it's not clear why I should care: my options seem to be really fast on HTTP/2 and really slow on HTTP/1.1, or kinda fast on HTTP/2 and kinda fast on HTTP/1.1.

[jomohke]

You'll still see performance benefits of HTTP2 while supporting HTTP/1.1 content.

HTTP2 requests have (sometimes significantly[1]) less overhead, and most sites following good HTTP/1.1 practices still make many requests.

Open the network panel in your browser and view a few large sites. Despite minimizing requests with sprites, concatenation etc, most still make dozens of requests, with some large sites pushing over a hundred.

(for example, I just loaded a page for a single tweet on Twitter and it involved twenty requests, with a size over 2MB.)

I think your list of options are incorrect:

- You can optimize for HTTP/1.1 and it will be fast over both protocols.

- Or don't optimize, and it will be fast over HTTP2 and slow over HTTP/1.1. The main benefit is saving development time & complexity. This will not be a worthy tradeoff until HTTP2 is more widespread among your users.

[1] The reduction in latency can be massive, for instance, as the HTTP2 server can push resources immediately without waiting for the browser to request them.

[geofft]

Sure, there's still an advantage for the user to upgrade to HTTP/2. But it sounds like I shouldn't be particularly optimizing for HTTP/2 quite yet? That's what I'm interested in: I'm not usually a web developer so I don't pay close attention, but I'd like to know how to design websites that aren't bad in general.

It sounds like I'm currently best off designing for HTTP/1.1 (with all the usual hacks) and knowing that HTTP/2 will perhaps make things better, instead of designing in any way for HTTP/2, which will make things worse for HTTP/1.1. That seems to be not what this article is saying.

Should I be caring about designing for HTTP/2 yet, or should I just ignore it for a few years?

[MichaelGG]

With ASP.NET, this is easy enough for JS and CSS bundling since that can be done as part of the runtime handler. (You keep the files on disk all normal, then specify which ones belong to which bundle names. ASP.NET does the rest for you.) So a simple if/else should be enough (I'm actually doing this for debugging on a site, just not based off of HTTP/2.)

Caching could be an issue, but if you're frontending with a reverse proxy, you could append another querystring parameter for http2 then do caching in the proxy level.