Loading 180 tiled images with HTTP/2 vs. HTTP/1 • Hacker News Board

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

#41

Post by liviu » Thu, Apr 16, 2015, 6:58 PM UTC

bsdetector wrote: post #36

codewithcheese wrote: post #27

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

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

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

#42

Post by hayksaakian » Thu, Apr 16, 2015, 7:00 PM UTC

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?

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

#43

Post by bsdetector » Thu, Apr 16, 2015, 7:13 PM UTC

iotku wrote: post #40

bsdetector wrote: post #36

Earlier quoted context omitted.

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

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.

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

#44

Post by Twirrim » Thu, Apr 16, 2015, 7:15 PM UTC

Kudos wrote: post #30

andrewstuart2 wrote: post #24

Earlier quoted context omitted.

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.

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.

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

#45

Post by motoboi » Thu, Apr 16, 2015, 8:04 PM UTC

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

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

#46

Post by ZeroGravitas » Thu, Apr 16, 2015, 8:05 PM UTC

bsdetector wrote: post #43

iotku wrote: post #40

Earlier quoted context omitted.

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.

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

#47

Post by [deleted] » Thu, Apr 16, 2015, 8:33 PM UTC

codewithcheese wrote: post #27

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

[deleted]

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

#48

Post by bsdetector » Thu, Apr 16, 2015, 8:36 PM UTC

ZeroGravitas wrote: post #46

bsdetector wrote: post #43

Earlier quoted context omitted.

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.

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

#49

Post by [deleted] » Thu, Apr 16, 2015, 8:39 PM UTC

liviu wrote: post #41

bsdetector wrote: post #36

Earlier quoted context omitted.

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

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

[deleted]

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

#50

Post by patrickmcmanus » Thu, Apr 16, 2015, 9:50 PM UTC

mohamedattahri wrote: post #4

dsiegel2275 wrote: post #3

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

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.

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.