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

31–40 of 62 posts

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

#31

Post by tootie »

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.

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

#32

Post by PythonicAlpha »

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?

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

#33

Post by MichaelGG »

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…

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.

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

#34

Post by jomohke »

geofft wrote: post #28
jomohke wrote: post #26

Earlier quoted context omitted.

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

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.

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

#35

Post by MichaelGG »

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.

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

#36

Post by mattmanser »

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…

I've said this before and I'm still not certain, but given that all browsers on desktops now auto update, and that browsers on phones and tablets have a short shelf life because those devices are far more disposable, I can't see how we're going to end up in an IE6 scenario.

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

#37

Post by MichaelGG »

tootie wrote: post #30
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.

IIS, for instance, makes you install "Dynamic" compression separately from Static compression, and it's not on by default. They also have some stupid frequency measurement, so you can end up with slow first loads until IIS decides its time to compress files. And changing it requires modifying some global config deep under system32.

Supposedly they separate all these little features out (no telnet client or tftp client!) for security. But it's really a cover-your-ass style that results in worse security for many users which just install everything trying to make stuff work. Dynamic compression being separate is a great example of that.

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

#38

Post by PythonicAlpha »

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.

Thanks, yes, when this is the case, that would eliminate the cookie-less domain reason.

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

#39

Post by moron4hire »

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…

Shouldn't a single request be multiplex-able, too? Isn't BitTorrent just one example of such a single-logical-request, multiple-connection protocol?

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

#40

Post by geofft »

jomohke wrote: post #34
geofft wrote: post #28

Earlier quoted context omitted.

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

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…

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?

Post reply on HN