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

51–60 of 62 posts

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

#51

Post by josteink »

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.

Given how gzip is the single most effective way of reducing BW consumption and site-loading speeds, I think we can conclude that those who don't bother don't really care about performance either way.

And in those cases HTTP 1.x vs HTTP 2.x is a moot discussion anyway.

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

#53

Post by swift »

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…

It's true that images may compress more efficiently in some cases when combined into a sprite sheet, but in my experience the scenario described by the article is very likely: your sprite sheets will end up containing images that the current page doesn't need. That has significant costs in terms of bandwidth usage, memory usage on the client side, and CPU / energy usage on the client side (for decoding unneeded image data).

Further, if any image on the sprite sheet is currently visible, the entire sprite sheet must remain in memory, when otherwise the browser could free the memory of all the non- visible images. And it may sometimes be necessary to use a much more expensive drawing path when drawing sprites to ensure that pixels from one image don't bleed into another image.

These negative effects will be felt most severely on resource-constrained mobile devices, where it matters most.

One should always measure when making decisions about performance, but in an HTTP2 world my recommendation would be to avoid sprites in most cases.

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

#54

Post by swift »

reissbaker wrote: post #43
tootie wrote: post #31

Earlier quoted context omitted.

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

This is 100% right. One additional point about the importance of granularity to effective cache management: if you bundle rarely accessed resources together with frequently accessed resources in the same cache entry, those rarely accessed resources are taking up space that could be used for other data. You may actually be causing cache misses and additional network traffic!

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

#56

Post by callum85 »

Several comments are misinterpreting the article, I think, as saying that your site will be slower than before when you switch to HTTP2 if you're still using the old techniques. In fact, nearly all sites will just magically speed up thanks to basic improvements like header compression.

But, by continuing to use the old hacks, your site won't be as fast as it could be. It's an opportunity cost. Some of those opportunities being:

- increased cache granularity (avoids invalidating a whole sprite or concatenated bundle when just a single part changes)

- parallel downloading of files that were previously bundled into one file

- fewer DNS lookups, now that you're not sharding

- less energy/memory usage in the client because you're not decoding/remembering whole sprites

And the subtlest, biggest win:

- simplifying your build process.

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

#58

Post by cabirum »

swift wrote: post #53
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…

It's true that images may compress more efficiently in some cases when combined into a sprite sheet, but in my experience the scenario described by the article is very likely: your sprite sheets will end up containing images that the current page doesn't need. That has significant costs in terms of bandwidth usage, memory usage on the client side, and CPU / energy usage on the client side (for decoding unneeded image…

Sprite sheets contain images browser might need. Essentially it's a preloading technique, so you won't be slowed by waiting for something to load, even if it takes half a sec.

Also, most if not all browsers use GPU to render web pages. And spriting actually comes from gamedev/GPU world [1], where many textures are baked/combined into a big one because it's efficient from performance/memory layout POV.

A final thought, what about server IO becoming a bottleneck when it needs to read hundreds of small files from disk for each request?

[1] http://www.blackpawn.com/texts/lightmaps/

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

#59

Post by tootie »

reissbaker wrote: post #43
tootie wrote: post #31

Earlier quoted context omitted.

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

That's only true if you're updating your assets faster than your cache TTL. I suppose if you're a continuous deployment shop that deploys to prod 25 times a day, that's a concern, but not if you deploy once a month.

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

#60

Post by tootie »

josteink wrote: post #51
tootie wrote: post #30

Earlier quoted context omitted.

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

Given how gzip is the single most effective way of reducing BW consumption and site-loading speeds, I think we can conclude that those who don't bother don't really care about performance either way. And in those cases HTTP 1.x vs HTTP 2.x is a moot discussion anyway.

Even if site administrator's don't care, users do.
Post reply on HN