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

41–50 of 62 posts

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

#41

Post by cperciva »

molf wrote: post #8

This article makes too many assumptions for my taste. Some other considerations that spring to mind: - A sprite tends to have fewer bytes than separate images, because of image format overhead and better compression when combining similar things. - The same may be true for zipped CSS/JS. - What about CSS/JS/image parsing overhead? - Even though HTTP2's request overhead is substantially less than HTTP1, fewer HTTP req…

better compression when combining similar things.

Or, as I like to put it: "Birds of a feather compress better together."

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

#42

Post by matt_kantor »

CognitiveLens wrote: post #27

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.

I think I'm missing something here. By "markup" do you mean the content of text/html response bodies? By "optimized HTTP1 markup" do you mean minified HTML?

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

#43

Post by reissbaker »

tootie wrote: post #31
molf wrote: post #8

This article makes too many assumptions for my taste. Some other considerations that spring to mind: - A sprite tends to have fewer bytes than separate images, because of image format overhead and better compression when combining similar things. - The same may be true for zipped CSS/JS. - What about CSS/JS/image parsing overhead? - Even though HTTP2's request overhead is substantially less than HTTP1, fewer HTTP req…

The other thing missing is how this interacts with CDNs. Concatenating my whole site's CSS into one file isn't just to decrease round trips, it's because there's only 1 URL to cache (both CDN and client browser) for every page.

That's actually harmful for cache performance. Ideally you want many small, granular caches that only expire when the specific content changes to get the highest cache hit rates: if you concatenate everything together, making changes to a single file requires redownloading the entire bundle.

(It's still faster under HTTP/1.1 to concatenate because of the overhead of making multiple HTTP requests and the parallelization limit, but one of the perf gains of HTTP2 is that since extra requests are cheap caches can be targeted and granular. Changes to a single script won't necessitate redownloading a giant concatenated bundle — you only need to download the single script that got updated.)

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

#44

Post by reissbaker »

lispm wrote: post #10

> It can leave the connection open for re-use for very extended periods of time, so there's no need for that costly handshake that HTTP1 requires for every request. HTTP1 supports pipelining requests. > HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster. 'significantly'? How much is that? > HTTP2 multiplexes; it can send and receive multiple things at…

> HTTP1 supports pipelining requests.

Head-of-line blocking makes the HTTP/1.1 pipelining perform poorly. Multiplexing is a more performant solution than pipelining.

Here's some worthwhile reading on the subject: http://http2.github.io/faq/#why-is-http2-multiplexed

> 'significantly'? How much is that?

Depends. In HTTP/1.1 request headers weren't compressed, and you generally have a ~1500 byte limit for a request to fit in a single packet. If you crossed that threshold, and if compression brings you back under (it certainly might), you could see 2x or better perf gains on time-to-first-byte depending on how many packets your initial request was being broken into.

> If that one connection stalls, multiple things won't be transferred.

While true, it's still often easier to optimize a single saturated connection than multiple ones for a variety of reasons (slow start, congestion, etc). More reading on the subject: http://http2.github.io/faq/#why-just-one-tcp-connection

Personally I'm really excited about HTTP2 being deployed. It makes the web fast by default — no need to concatenate or domain shard once it's widely deployed — and adds extra opportunities for performance (e.g. server push) that we haven't seen yet.

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

#45

Post by michaelmior »

joshstrange wrote: post #12
molf wrote: post #8

This article makes too many assumptions for my taste. Some other considerations that spring to mind: - A sprite tends to have fewer bytes than separate images, because of image format overhead and better compression when combining similar things. - The same may be true for zipped CSS/JS. - What about CSS/JS/image parsing overhead? - Even though HTTP2's request overhead is substantially less than HTTP1, fewer HTTP req…

Agreed, as someone who has done a significant amount of work to sprite our images and concat our js/css files this title, and most the content, scared me. The only thing I haven't pushed through is different domains for static assets (though I have them cached for a year with a query string as a cache-buster for when we deploy new js/css). None of this, in a HTTP2 context, seems like it would be extremely, or at all…

A few reasons why concatenating CSS and JS might be harmful under HTTP2. Firstly, it means that the code must be downloaded serially. Given that the per-request overhead is minimal for HTTP2, it's more efficient to download the files separately in parallel. Second, in most cases you don't actually depend on all the CSS/JS for the user to start interacting with the page so keeping things separate can mean that the perceived response time is shorter. Finally, separate resources can result in less cache invalidation when assets are changed which could make a big difference for repeat visitors.

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

#46

Post by michaelmior »

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?

Aside from the other responses to this comments, this goes towards making HTTP2 requests cheap which enables a lot of other optimizations that were antipatterns under HTTP/1.1

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

#47

Post by michaelmior »

MichaelGG wrote: post #35
PythonicAlpha wrote: post #32

Serving from a cookie-less domain, still good? I understand the points made about sharding and concatenating (and also the limits of the arguments), but the short article just mentions cookie-less domains and then just seem to forget about them. So this practice is still valid? Or is there some feature in HTTP2 that also obsoletes this?

Another comment says that repeated headers aren't sent in the same connection. Thus that'd eliminate sending cookies except the first time, eh? So using multiple domains might hurt, since you need extra DNS lookups and TCP connections.

This is true although if you're not doing domain sharding and just have your static assets on a single domain, I don't think this is a concern. Certainly the performance benefit of having your assets served by a CDN on a different domain will outweigh the cost of the extra connection. (Assuming your CDN supports HTTP2.)

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

#48

Post by thomasfoster96 »

matt_kantor wrote: post #42
CognitiveLens wrote: post #27

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.

I think I'm missing something here. By "markup" do you mean the content of text/html response bodies? By "optimized HTTP1 markup" do you mean minified HTML?

I think what is meant is that a lot of HTML. Is written assuming concatenated assets, image sprites, CDNs, etc., but a lot of this redundant now. Http/2 might mean a rewrite of you html is required, not just changing some things on your server.

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

#50

Post by matt_kantor »

thomasfoster96 wrote: post #48
matt_kantor wrote: post #42

Earlier quoted context omitted.

I think I'm missing something here. By "markup" do you mean the content of text/html response bodies? By "optimized HTTP1 markup" do you mean minified HTML?

I think what is meant is that a lot of HTML. Is written assuming concatenated assets, image sprites, CDNs, etc., but a lot of this redundant now. Http/2 might mean a rewrite of you html is required, not just changing some things on your server.

Even if you decide to de-concatenate some CSS and JavaScript files and serve them from the site's main domain, the changes to your HTML will be minuscule (some extra / elements and changes to some src attributes). The bulk of the changes would occur in the linked assets themselves.

I guess if you're embedding data URIs in your HTML to cut down on requests and you want to switch them to normal HTTP URLs then there could be nontrivial markup changes, but I hope it's not common for web developers to do such things by hand.

I think the word "markup" just threw me off. If you replace it with something more general that also covers CSS, JavaScript, images, etc then I wholeheartedly agree with CognitiveLens's comment. The point is that you shouldn't be afraid to throw away obsolete performance hacks if it increases developer productivity and/or leads to a better experience for your userbase.

Post reply on HN