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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
"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?
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.
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.
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.
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.
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.
56 comments
[ 3.0 ms ] story [ 107 ms ] threadOf 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.
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.
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).
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.
Adding a third option with domain sharing might be reasonable, but I would expect that http2 still has the best performance.
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.
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.
I'm curious as to how javascript engines perform with one hundred files multiplexed VS one giant file.
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.
> A bit saved is a bit earned.
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.
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.
Anyway, disable HTTPS Everywhere if you have it, since if you don't do it there will be no difference. :-)
And of course, it could also cache that knowledge and do it all instantly.
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.
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.
Maybe they should have asked Kaspersky. If you have a clean system pipelining works great.
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."
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?
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.
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
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?
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.
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.