Loading 180 tiled images with HTTP/2 vs. HTTP/1 | Hacker News Reader

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

http2.golang.org

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.

This is one of the more exciting parts for me.

At Udemy ~90% of our visitors have SPDY3 or better (tech-savvy audience). Our JS needs an overhaul and the timing is great for a rethink on how we deliver it.

We're looking at optimising for those users and no longer bundling our JS and CSS. We need to test it further because we can't simply flick a switch and flick it back if it doesn't work out, we'll need to move away from Fastly to somewhere that has SPDY first.

CloudFlare supports SPDY!

As do Akamai and MaxCDN.

It's a good thing that all headers are now compressed and many are only sent once. So I'm not sure more headers is what could hurt.

I'm curious as to how javascript engines perform with one hundred files multiplexed VS one giant file.

I personally still think that JS should still always be pre-processed.

When you can spend longer up front optimizing the concatenation, minification, and compression, you can amortize that additional cost across every request and still make important incremental gains.

A bit saved is a bit earned.

Most sites right now concatenate their _entire_ javascript blob rather than the "necessary" javascript blob for the current page. There are arguably other uses for minification and compression, but not needing to concatenate is going to save a lot of bandwidth since developers no longer have to consider whether or not they need to build another concatenated blob for specific pages.

You can and should still compress and do some amount of minification. Concatenation is debatable on sites with varied page types and JS needs.

> A bit saved is a bit earned.

So don't send bits the user probably won't need? :P

> So don't send bits the user probably won't need? :P

Surely good for both your bandwidth bills, and the end user experience. The less work your users have to do, the better, especially when it comes to mobile devices.

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.

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.

Similarly to GZIP applied by the Web Server, you could build your minification in, although given that the approaches are more varied and less standard it might not be the greatest idea.

It sounds like you're describing PageSpeed: https://developers.google.com/speed/pagespeed/module

Akami http2 demo https://http2.akamai.com/demo

Firefox Nightly:

  HTTPS 1.1: 22 ms latency, 2.83s load time
  HTTPS 2:   17 ms latency, 2.91s load time

Network panel in web developer tools says the second was actually fetched over HTTP/2 so it looks like the demo worked... just not as intended.

So HTTP/2 provides no performance benefit in this case. Although I do have pipelining turned on, and unlike the gopher tiles demo this server actually returns "Connection: Keep-Alive" header necessary for pipelining to be used so that might explain it; Microsoft Research did determine that SPDY and pipelining have essentially the same page load performance.

Chromium:

    HTTPS 1.1: 140ms latency, 46.47s load time
    HTTPS 2:   25ms  latency, 4.76s load time

Definitely a difference on a high latency (Sat) connection, although I'm not aware what the latency amount is based on.

And now you know why Google never tested against pipelining... if they had they'd have to sell it as marginally faster and more sensible, rather than saying it is up to 10x faster.

Since you are on satellite I suggest trying Firefox and turning on aggressive pipelining in about:config. As far as I know I've never had a problem with it in years, and as you can see it brings HTTP/2 speeds to non-SSL and older sites.

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."

> "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?

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.

Yeah, HTTP/2 smoked HTTP/1.1 for me:

    HTTP/1.1: Latency: 57ms. Image load time: 7.69s
    HTTP/2:   Latency: 30ms. Image load time: 0.97s

My results are obvious in favor of HTTP/2

  HTTP/1.1: Latency: 561ms Image load time: 32.64s
  HTTP/2: Latency: 623ms Image load time: 8.77s

The server seems to be overloaded right now.

Anyway, disable HTTPS Everywhere if you have it, since if you don't do it there will be no difference. :-)

The reverse schadenfreude here is great. All the haters on HN complained about HTTP/2 endlessly, and here we've given them a faster Internet anyway.

I am shocked at the differences. A picture is worth a thousand words.

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.

Interesting. If the tiles are cached by the browser, HTTP/2 is slower than version 1. Only for the first request HTTP/2 was tremendously faster than its predecessor.

It seems to be offline now?

Seems to be having trouble with the all TLS handshakes from HN. Plaintext http connection works for me (but it's not http/2)

It's not offline. There's just a long latency...

Same for me

Wouldn't a more fair comparison involve domain sharding for the HTTP/1 impl?

Not sure, isn't the whole point of pipelining to avoid these domain-sharding workarounds?

This test case shows that the performance is better with the same code. The invert test case would show that the code is more complex (because of sharding) for the same performance (actually not quite, because of multiple handshakes).

The whole point of pipelining is to avoid expensive TCP operations. Domain-sharding is effectively a workaround for the workaround (limiting connections to hosts).

You can actually do both domain-sharding and still use only a single TCP connection. SPDY/HTTP2 will reuse existing connections if they receive the same cert/ip combo. It's the best of both worlds while http1 still has some marketshare.

Good point, but domain sharding is just a clever optimization (hack) to emulate some of the parallelism provided by HTTP/2 out of the box.

Agreed. For 'the regular web' (outside those organisations that have the nous and resources to optimise) this is a really clear demo. Roll on HTTP2!

Both your points are valid if the comparaison is strictly based on performance gains. The problem is they imply that optimizing is free and easy.

domain sharding gives you parallelism - but it totally bypasses congestion control. At certain levels this works in your favor - because congestion control tends to be overly conservative for HTTP - but at levels of sharding too high it is a disaster (packet loss, heavy buffering, reordering and huge delays to sort it all out.)

Unfortunately the appropriate level of sharding isn't something the person doing the markup can know - because its based on the runtime path characteristics of each page viewer.

Much better to multiplex in one congestion control context (like http/2 does) and then work on making congestion control work better (like the various blah over udp projects such as quic are trying to do). Plus if you do this you can add prioritization, which is a big deal.

Certainly, but comparing X-as-almost-never-practiced[1] to Y is pretty disingenuous unless you're going to very clearly state up front that that is what you're doing.

Of course, the hackiness of X-as-practiced is a valid point of qualitative comparison and should indeed be brought up.

[1] Ok, I'm exaggerating a little. It's not quite "never", but most large sites where image loading time is an issue are using some form of workaround, be it spriting, multiple domains, or something else.

I think the point is that these sites get an efficient solution for free rather than spending time and resources on designing and implementing sharding. Just because it's common for sites with loading time constraints doesn't mean they wouldn't have been a whole lot happier to not have to have dealt with it.

I wouldn't say so. Domain sharding is a hack, and not every website implements it, so I think this is a fair comparison.

Adding a third option with domain sharing might be reasonable, but I would expect that http2 still has the best performance.

Yes and no. It would speed up the client receiving the images but at the detriment of flooding servers with connections (even moreso bad if HTTPS). I assume since this is on golang's site, this is also trying to show off the difference with just using the HTTP2 vs HTTP package.

The page is also a reference server implementation for people working on clients are well.

Does anyone know when the HTTP/2 client for Go will be available? And, are they likely to include http/2 into a standard net/http package?

Ran this a while ago on my Satellite connection [1], it's really exciting for users with high latency.

Satellite internet services have come a long way from what it used to be and has a much higher raw speed than before, but of course you can only do so much with latency when the signal is traveling such a distance.

[1]: https://www.youtube.com/watch?v=Ut-8ieRg1yE

A Better idea for a demo:

Take the top 20 website on the web, and get their static assets from archive.org

Show me how much faster they load. I'm imagining sites like CNN or Yahoo which serve many images on their home page could load faster.

How much faster?

I wonder how well will a reverse http/2-proxy, in front of a http/1-server will behave

It could be rather complex, but almost certainly will still help. It could, for example, heuristically process the script tags as HTML passes back through it to the client, make optimistic requests to the HTTP/1 server (presumably at a much lower latency than the client), then push those documents down to the client.

And of course, it could also cache that knowledge and do it all instantly.

nghttpx, the proxy from the nghttp2 package, turns rel=preload links from the Link header into server push: https://nghttp2.org/documentation/nghttpx.1.html#server-push

from here, with 1sec delay, 3 attempts, avg values, empty cache each time.. 38.7s vs 58.3s

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.

Reply on news.ycombinator.com