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

31–40 of 57 posts

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

#31

Post by Lifescape »

Kudos wrote: post #18
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.

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…

CloudFlare supports SPDY!

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

#32

Post by Kudos »

Lifescape wrote: post #31
Kudos wrote: post #18

Earlier quoted context omitted.

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…

CloudFlare supports SPDY!

As do Akamai and MaxCDN.

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

#33

Post by swang »

andrewstuart2 wrote: post #24
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.

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.

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

#34

Post by floatboth »

andrewstuart2 wrote: post #25
_lce0 wrote: post #22

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

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

#36

Post by bsdetector »

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

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

#37

Post by mankyd »

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

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

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

#38

Post by zserge »

mohamedattahri wrote: post #11
invisible wrote: post #9

Earlier quoted context omitted.

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?

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

#39

Post by iotku »

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

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

#40

Post by iotku »

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

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.
Post reply on HN