Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The best practices of HTTP1 are harmful in a HTTP2 world

mattwilcox.net

Post reply on HN
Print view View original

21–30 of 62 posts

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#21

Post by 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?

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#22

Post by rakoo »

Illniyar wrote: post #19
jomohke wrote: post #15

Earlier quoted context omitted.

It does support compression of the message body, but not of the headers. They designed a new compression algorithm called HPACK specifically to compress headers in HTTP2: https://http2.github.io/http2-spec/compression.html In small HTTP/1.1 requests the headers can be much larger than the content, which is part of the motivation for combining files into one request.

Considering the best practice for HTTP/1.1 is to create few very large files - why would compressing headers really make a difference?

HTTP/2.0 does not only compress headers, it also keeps a context of headers that were already sent. So if you want to include a specific header with the same value in multiple requests (like, say, a cookie), it won't actually be re-sent on the wire. The other side will know that the value hasn't changed.

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#23

Post by sp332 »

Illniyar wrote: post #19
jomohke wrote: post #15

Earlier quoted context omitted.

It does support compression of the message body, but not of the headers. They designed a new compression algorithm called HPACK specifically to compress headers in HTTP2: https://http2.github.io/http2-spec/compression.html In small HTTP/1.1 requests the headers can be much larger than the content, which is part of the motivation for combining files into one request.

Considering the best practice for HTTP/1.1 is to create few very large files - why would compressing headers really make a difference?

"Best practice" can take a lot of work and often doesn't happen in real life. HTTP/2 gets you this advantage for free.

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#24

Post by jrochkind1 »

> The long and short of it is; when you build a front-end to a website, and you know it's going to be served over HTTP2...

Well, that's the rub, isn't it?

When are we going to possibly be in a state where we know our website is going to be served over HTTP2?

Not for a while, probably? Not just wait until all the browsers support HTTP2, it's wait until the browsers that _don't_ support HTTP2 are a small minority.

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#25

Post by [deleted] »

jrochkind1 wrote: post #24

> The long and short of it is; when you build a front-end to a website, and you know it's going to be served over HTTP2... Well, that's the rub, isn't it? When are we going to possibly be in a state where we know our website is going to be served over HTTP2 ? Not for a while, probably? Not just wait until all the browsers support HTTP2, it's wait until the browsers that _don't_ support HTTP2 are a small minority.

[deleted]

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#26

Post by jomohke »

geofft wrote: post #21

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 referen…

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.

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#27

Post by CognitiveLens »

This info is in some replies further down the page, but just to highlight: your optimized HTTP1 markup will not be slower when you move it to HTTP2, but when you're on HTTP2, you might get even more speed benefit by structuring things differently.

A reluctance to change your markup should not be a reason to resist a change to HTTP2, if and when it is actually available.

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#28

Post by geofft »

jomohke wrote: post #26
geofft wrote: post #21

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 referen…

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…

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.

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#29

Post by MichaelGG »

Illniyar wrote: post #19
jomohke wrote: post #15

Earlier quoted context omitted.

It does support compression of the message body, but not of the headers. They designed a new compression algorithm called HPACK specifically to compress headers in HTTP2: https://http2.github.io/http2-spec/compression.html In small HTTP/1.1 requests the headers can be much larger than the content, which is part of the motivation for combining files into one request.

Considering the best practice for HTTP/1.1 is to create few very large files - why would compressing headers really make a difference?

If the headers are big enough, then you may need multiple packets to transmit the request.

Also, some TCP stacks (or an extension option?) will allow data in the first packet, so you don't have to wait for the handshake. Perhaps this doesn't work if the data doesn't fit in a single packet?

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#30

Post by tootie »

nailer wrote: post #2

Nearly all HTTP 1.1 servers use gzip. Does that mean that minification for the purposes of reducing payload size is also unnecessary there? (serious question) Edit: answering my own question: http://stackoverflow.com/a/807161

Every popular HTTP server supports gzip compression, but you still have to turn it on and surprising number of sites don't bother.
Post reply on HN