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

Loading 180 tiled images with HTTP/2 vs. HTTP/1

http2.golang.org

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1

#51

Post by pfranz »

motoboi wrote: post #45

Could someone please explain what is going on in this demo?

I'm guessing the submitter saw this talk at PyCon that used the page as illustration: Cory Benfield - Hyperactive: HTTP/2 and Python https://youtu.be/ACXVyvm5eTc

It's a new major version of HTTP. At the high level it's backwards compatible (status codes, urls, etc are the same), but the communication of those things changed. It's binary instead of plain text (a major point of contention), it's stateful instead of stateless (it can refer back to previous requests, which makes debugging harder when you jump in the middle of a communication), it can multiplex data (send multiple files concurrently--this is where the demo shines), adds a prioritization layer, and header compression. I may have some of those details wrong--all of that I learned from the talk.

Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1

#52

Post by ZeroGravitas »

jewel wrote: post #13

Note that this means that there's no longer a pressing need to consolidate multiple javascript files into one file, likewise with CSS files. Icon sprites aren't necessary either. There are still some gains from combining the files, as it will mean less headers will go over the wire, and you'd still want to minify them so that there were less total bits, but the gains aren't going to be as big as they used to be.

There's not many benefits remaining to combining files. I'm sure the new best practice will get worked out in detail but e.g. you can update one js/css/image file but regular users will still have all the rest in their cache, people who only ever use one part of your site may never need to load some js/CSS/image files at all (reducing both load and parse time as well as memory), files you know you'll need can be prioritized or pre-cached rather than combined like we used to do for image rollover effects.

Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1

#53

Post by ZeroGravitas »

The Google Page speed service has a test page where you provide a URL and it runs it through the webpagetest.org service twice, to show before and after times (and other details) for all the various optimisation techniques it applies automatically.

https://developers.google.com/speed/pagespeed/service/tryit

One of these optimisations is the use of SPDY/HTTP2 I believe? (Actually seems like WebPageTest has some issues with HTTP2 currently, though it's at the top of their TODO list to fix them: https://github.com/WPO-Foundation/webpagetest/issues/20) It would be great if they (or someone else) provided this service but only changed the use of HTTP2 so that people could run this benchmark on their own sites, and people could get a comprehensive view on what kinds of sites would benefit from switching today (without even bothering to remove old optimisations like image spriting etc.)

Those sites that benefit without any change may be the first to move, as so many workflows are built around concatenation of files etc. and that workflow will still be needed for some percentage of users, probably for years to come, so an initial, easy win would be good to demonsrate. I'm hopeful that if you use SSL then HTTP/2 will always be faster, but it would be good to see some data on that.

Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1

#54

Post by ZeroGravitas »

bsdetector wrote: post #48
ZeroGravitas wrote: post #46

Earlier quoted context omitted.

If aggressive pipelining worked well enough then Mozilla would turn it on by default. The fact they don't is more than enough reason for Google to not test against it.

Mozilla and Google claim there are bad servers out there that pipelining doesn't work with, but yet neither were able to identify those bad servers or reproduce the problems -- probably because the bad software is Superfish and other malware. You don't see problems with iOS Safari using pipelining. Maybe they should have asked Kaspersky. If you have a clean system pipelining works great.

For anyone interested, a summary from the decision maker at Mozilla who made this call:

https://bugzilla.mozilla.org/show_bug.cgi?id=264354#c65

"It pains me as I believe firefox has the most sophisticated pipelining algorithm ever built, but the fundamental approach is simply flawed in ways that multiplexing is not. Let's put energy into making multiplexing a success."

Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1

#55

Post by r1ch »

jewel wrote: post #13

Note that this means that there's no longer a pressing need to consolidate multiple javascript files into one file, likewise with CSS files. Icon sprites aren't necessary either. There are still some gains from combining the files, as it will mean less headers will go over the wire, and you'd still want to minify them so that there were less total bits, but the gains aren't going to be as big as they used to be.

Unfortunately most spdy / HTTP2 implementations mandate TLS. This means websites that rely on ad revenue cannot benefit from these improvements without losing revenue. I'd really love to use spdy / HTTP2 but ad revenue is more important, so I'll be continuing to sprite for the near future.

Given how awful ad serving architecture is these days for smaller publishers (chains of javascripts and iframes), I don't anticipate this being fixed for quite a while.

Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1

#56

Post by bsdetector »

ZeroGravitas wrote: post #54
bsdetector wrote: post #48

Earlier quoted context omitted.

Mozilla and Google claim there are bad servers out there that pipelining doesn't work with, but yet neither were able to identify those bad servers or reproduce the problems -- probably because the bad software is Superfish and other malware. You don't see problems with iOS Safari using pipelining. Maybe they should have asked Kaspersky. If you have a clean system pipelining works great.

For anyone interested, a summary from the decision maker at Mozilla who made this call: https://bugzilla.mozilla.org/show_bug.cgi?id=264354#c65 "It pains me as I believe firefox has the most sophisticated pipelining algorithm ever built, but the fundamental approach is simply flawed in ways that multiplexing is not. Let's put energy into making multiplexing a success."

> "Let's put energy into making multiplexing a success."

In other words, the guy just doesn't want to work on pipelining anymore, not that it doesn't work well. He also said "it's good" and kept it enabled for mobile because "the higher rtts tip the balance in its favor" -- and you're telling somebody with satellite internet not to use it to reduce page load time for the vast majority pages out there that are not SSL (and so not HTTP2) or are on old servers. Really?

Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1

#57

Post by iotku »

bsdetector wrote: post #48
ZeroGravitas wrote: post #46

Earlier quoted context omitted.

If aggressive pipelining worked well enough then Mozilla would turn it on by default. The fact they don't is more than enough reason for Google to not test against it.

Mozilla and Google claim there are bad servers out there that pipelining doesn't work with, but yet neither were able to identify those bad servers or reproduce the problems -- probably because the bad software is Superfish and other malware. You don't see problems with iOS Safari using pipelining. Maybe they should have asked Kaspersky. If you have a clean system pipelining works great.

Seems to work pretty well for me, now only if I used non SSL sites more often.

Go figure I find a solution to most of my issues I have with Sat around the time I'm moving somewhere with hopefully better internet soon.

Post reply on HN