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.
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.
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.
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?
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.