9 ms·

Better HTTP/2 Prioritization for a Faster Web

183 points by zspitzer 7y ago

skybrian 7y ago
It seems like this is another example of every aspect of web development getting more complicated, favoring the larger players. On the other hand, it's good that in this case, any website could just buy the results of that expertise.
- AndrewStephens 7y ago
  You are not wrong - in reality we have had a tiered internet for years now, where big sites pay for faster transfers over better routes. However nothing says you actually have to use these fancy services. Everyone wants a quick loading site but the drawback of an extra 100ms are minimal. Almost everyone should be more concerned with good site design and minimizing client-side dependencies if they want good performance.
  - save_ferris 7y ago
    It's important to remember that with the death of net neutrality in the US, this may not be the case forever.
  - WhiteOwlLion 7y ago
    Why would you say extra 100ms is a minimal drawback? Google obsesses over load time because faster load time means more ad dollars generated. 700ms vs 800ms is the difference between acceptable and a slow loading web site.
    - skybrian 7y ago
      It matters for websites, but only after fixing many other problems with performance and usability. For an individual user, it doesn't matter to me if I use a website a bit less because it's a little slower. That might even be an improvement, since I was probably using the Internet too much anyway.
      - zzzcpan 7y ago
        > It matters for websites, but only after fixing many other problems with performance and usability. Or does it? Once you fix major performance, usability problems and it starts to feel fast - other efforts become kind of pointless and may even become sources of performance, usability problems themselves.
    - vbezhenar 7y ago
      https://www.google.com/ https://www.google.com/ has 2.76s load time for me. Gmail 6.33s. Amazon 1.41s. Aliexpress 2.69s. Seems like entire Internet is slow?
- derefr 7y ago
  I would compare it more to RSS vs. more complicated protocols like WebSub. HTTP/1.0, like RSS, isn't going away; and when you're a smaller player, it's really all you need. It's only the larger players that actually have requirements that make optimizations like HTTP/2 necessary for their operating expenses to stay sane, rather than just "nice-to-have but an unnoticeable blip on their margins."
deleted 7y ago
[deleted]
voiper1 7y ago
So their main improvement over Chrome is that chrome doesn't benefit from progressive images -- they load images in sequence instead of parallel. Sounds like a simple fix. (If you actually know the images are progressive.)
- pornel 7y ago
  We've got a solution to this as well! It's interesting enough to get its own blog post: https://news.ycombinator.com/item?id=19910926 https://news.ycombinator.com/item?id=19910926
- patrickmeenan 7y ago
  Yep, hopefully a lot of the default improvements will make their way into all of the browsers. Until then, this also evens the field across all of the browsers but for me the really exciting part is exposing it to Workers so sites can customize the logic specific to their needs. Boosting the priority of hero images or async scripts that are important for the site but the browser's default logic has no way to know. Priority hints (also Chrome-only currently) will eventually bring that to browsers natively. Full disclosure, I'm the article author and I also spent several years on the Chrome team working on the resource loading/scheduler so it's probably not too surprising that there are similarities.
  - dullgiulio 7y ago
    I am not sure it is a good idea to trust the server to decide what is more important. I can easily imagine ads taking higher priority than actual content, just look at the pop-ups that interrupt reading. Browsers and protocol should start concentrating on how to secure users from the very sites they visit.
    - pornel 7y ago
      Prioritization works within a single HTTP/2 connection. Ads are generally served by a 3rd party, and while there are some limited ways of sharing HTTP/2 connections across origins, I don't think any ad servers offer such a close integration. Besides, sites already have blunt tools they can use if they really wanted to force ads to load first. This feature is more for site developers who care about performance. Instead of tweaking the markup and adding hints to help browsers request resources in the right order, they can now set the priorities directly and precisely.
pornel 7y ago
The big take-away from this is that "HTTP/2" is not the same thing everywhere. Quality of implementation matters. We didn't see so much variation in HTTP/1, because servers had almost no control, and clients were opening multiple connections, so even bad prioritization was hidden by TCP-level parallelism. In HTTP/2 we've reached a good level of interoperability, but bolting on HTTP/2 on top of a server architected for HTTP/1 is not enough. We have room for optimizations and maturity.
- merb 7y ago
  well h2 for development is really hard since basically you need to create a certificate, because no major browser implements h2 over plaintext. i mean a lot of people can live with that and just insert a development certificate into their trust chain, but some people do not understand that and others work in more restricted environments. so basically fully controlling and developing with h2 is basically not as easy as it was with http/1.
  - pornel 7y ago
    For server development the hard part is simulating realistic network conditions. For example, on localhost, you'll never witness any prioritization happening, because you'll never grow a queue of responses still waiting to be sent down.
    - zamadatix 7y ago
      Browser Dev tools pretty much cover that in one click these days.
  - tlrobinson 7y ago
    Has anyone just published a valid certificate for a domain name that resolves to 127.0.0.1?
    - Ayesh 7y ago
      For your own use, you can obtain a certificate via DNS validation, or by pointing your DNS A records to a server with a public IP. When you publish the private key online, anyone can revoke the certificate, or the CA themselves will.
tempguy9999 7y ago
I block all JS and have a comprehensive blocklist for just about every ad service there is. Stuff usually loads damn fast (ok, when not broken by JS missing, an acceptable price to me, I get speed and safety for free). I always recommend people try it. It's fast enough except when webbish types do stupid things. Just yesterday I was looking at a Scientific American article which was held up by an entirely pointless 2.6MB gif, this one <https://static.scientificamerican.com/blogs/cache/file/80C4493E-6185-4B03-8BB3D50C6EFE5DB1_source.gif?w=590&h=800&F16593DB-37EB-46A1-ADBFDD2EC7B05A93> https://static.scientificamerican.com/blogs/cache/file/80C44.... Quanta articles are bloody nuts too, check this shit, a 4MB animation that tells you nothing. Fucking nothing. Absolfuckinglutely sweet FA. (Edit, forgot link; here: <https://www.quantamagazine.org/mathematicians-discover-the-perfect-way-to-multiply-20190411/> https://www.quantamagazine.org/mathematicians-discover-the-p...) We have a fast web, what we also have are idiots - technical solutions to idiocy aren't solutions. (NB 'scuse swearing)
- tempguy9999 7y ago
  Downvoted for the bad language perhaps? I'd accept that. Or downvoted for recommending a blocklist to cap off ad networks? Or to disable JS to speed things up and increase my safety without new protocols? Or asking not to have my browsing turned into an Awesome Experience by web designers that don't understand the web is a means to an end for its users, not a way of life? Or something else?
  - jandrese 7y ago
    I don't know about the downvotes on your original comment, but comments complaining about being downvoted will always attract more downvotes.
    - tempguy9999 7y ago
      I didn't complain, I asked why. It may well be down to my rather abrasive style, in which case I'd apologise and try to be less so next time. Or it may be down to me being factually wrong, which I also need to know cos how else does one learn. Or maybe someone doesn't like what I said which is very much another thing. But I wasn't complaining.
forgotmypw14 7y ago
The web is quite fast already, if you don't weigh down your web pages with tens of megabytes of crap...
MrStonedOne 7y ago
I don't know that their assumption about bandwidth getting maximized period is correct.
3xblah 7y ago
"Web pages are made up of dozens (sometimes hundreds) of separate resources that are loaded and assembled by the browser into the final displayed content." Could that be the reason that that the web needs to be "faster" (despite tremendous advances in CPU, storage, bandwidth and network speeds)? The dozens (sometimes hundreds) of separate resources are loaded by default. What is their purpose? Where do they come from? Are all of them necessary? What if an advanced user could tell the browser to only load certain resources from certain sources? For example, maybe skip certain ads and tracking, as specified by the user. Perhaps do not load the Facebook "Like" buttons (images), but load all other images. Control exactly which Javascripts to load. In addition to the options that browsers now provide, provide more fine-grained controls. Could that make the web faster? A bonus would be if these user-defined, fine-grained browser settings could be saved in a portable, interoperable format, e.g. to external media, in addition to being able to save them to "the cloud" (which may be servers run by advertising-supported browser authors). Browser authors do not need to know which resources users may wish to block.
- ben_jones 7y ago
  Humans don't naturally optimize down to the byte level, be it a whole foods cashier who takes an extra 30 seconds to bag your groceries, an airline who's pilot needs to use the restroom and delays takeoff, or whatever other situation where convenience takes precedent. When and how often should human hours be spent to optimize machine hours? Sometimes clearly, but should they always? Where is the line? I think these questions define the whole javascript bloat problem, there is no clear answer so it varies company-by-company and developer-by-developer to the detriment of all involved.
  - tempguy9999 7y ago
    > Humans don't naturally optimize down to the byte level, Who said bytes? You did. Other commenters including myself have mentioned megabytes (ie. six orders of magnitude larger). Nobody said bytes AFAICS. > When and how often should human hours be spent to optimize machine hours Oooh, perhaps I can help! Being as I'm currently trying to shave 200 to 300 milliseconds at a time off one stage of a simulation, taking 2 to 6 hours for each optimisation. So 4 to 5 orders of magnitude more programmer time than machine time. That way larger models can be used, and all of multiple multiple sites will benefit, and less of their time will be spent waiting (see disclosure below). It's not actually that difficult an inequality to solve, except when haystacks of JS and advert crud are pushed on us by advertisers etc. whose money is made by wrecking the commons for their profit so don't want to know. “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” - Upton Sinclair disclosure, I'm actually doing this unpaid as I'm getting back into work after illness, however if I wasn't there they'd get someone else in, paid, as it needs doing.
ken 7y ago
Don't some of these browsers display a best-approximation font, while the actual font file is downloading, while others display no text until the font file is available? That seems like an awfully big distinction which is omitted here.
- patrickmeenan 7y ago
  It is more site-dependent than browser dependent but by default (unless the dev overrides) most browsers will leave the text blank for 3 seconds after the font is discovered before falling back. In most (all?) of the cases in the blog post, the actual font loading is within that 3-second window, the issue is that the layout-blocking content (preventing the browser from discovering the font) is what is slow.
TomGullen 7y ago
Would love to enable HTTP2 on Cloudflare on our site, but there seems to be a bug with it in Cloudflare where it randomly stops requests, and we're stuck in an endless support loop so we have to disable it on our PWA which would have huge benefits for it.
- matsur 7y ago
  Can you get in touch? rustam@cloudflare.com. I’d love to get to the bottom of this.
Matthias247 7y ago
As someone who has implemented HTTP/2 too (for the apparently unpopular .NET ecosystem) I am guilty of totally missing out on the prioritization feature too. There's definitely some good ideas and use-cases in the article that make it more worthwhile! Some things I'm wondering about: The proposed strategy seems to prefer sometimes sending single resources in a sequential fashion instead of lots of resources in parallel. Doesn't that essentially bring the communication back into a HTTP/1.1 style with less parallelism - and only with the benefit of no extra connections? And how well does the approach fit together with browsers flow control windows? If a browser set a small flow control window per stream then sending only a single object at a time wound still require lots of round-trips for flow control window updates - which might make it worse than HTTP/1.1. However I heard at some time that browsers have configured huge flow control windows. If that's true it seems more likely to work out (and the default strategy where HTTP/2 prefers parallelism over throughput seems worse).

183 points by zspitzer 7y ago

It seems like this is another example of every aspect of web development getting more complicated, favoring the larger players. On the other hand, it's good that in this case, any website could just buy the results of that expertise.

AndrewStephens 7y ago
You are not wrong - in reality we have had a tiered internet for years now, where big sites pay for faster transfers over better routes. However nothing says you actually have to use these fancy services. Everyone wants a quick loading site but the drawback of an extra 100ms are minimal. Almost everyone should be more concerned with good site design and minimizing client-side dependencies if they want good performance.
- save_ferris 7y ago
  It's important to remember that with the death of net neutrality in the US, this may not be the case forever.
- WhiteOwlLion 7y ago
  Why would you say extra 100ms is a minimal drawback? Google obsesses over load time because faster load time means more ad dollars generated. 700ms vs 800ms is the difference between acceptable and a slow loading web site.
  - skybrian 7y ago
    It matters for websites, but only after fixing many other problems with performance and usability. For an individual user, it doesn't matter to me if I use a website a bit less because it's a little slower. That might even be an improvement, since I was probably using the Internet too much anyway.
    - zzzcpan 7y ago
      > It matters for websites, but only after fixing many other problems with performance and usability. Or does it? Once you fix major performance, usability problems and it starts to feel fast - other efforts become kind of pointless and may even become sources of performance, usability problems themselves.
  - vbezhenar 7y ago
    https://www.google.com/ https://www.google.com/ has 2.76s load time for me. Gmail 6.33s. Amazon 1.41s. Aliexpress 2.69s. Seems like entire Internet is slow?
derefr 7y ago
I would compare it more to RSS vs. more complicated protocols like WebSub. HTTP/1.0, like RSS, isn't going away; and when you're a smaller player, it's really all you need. It's only the larger players that actually have requirements that make optimizations like HTTP/2 necessary for their operating expenses to stay sane, rather than just "nice-to-have but an unnoticeable blip on their margins."

deleted 7y ago

[deleted]

voiper1 7y ago

So their main improvement over Chrome is that chrome doesn't benefit from progressive images -- they load images in sequence instead of parallel. Sounds like a simple fix. (If you actually know the images are progressive.)

pornel 7y ago
We've got a solution to this as well! It's interesting enough to get its own blog post: https://news.ycombinator.com/item?id=19910926 https://news.ycombinator.com/item?id=19910926
patrickmeenan 7y ago
Yep, hopefully a lot of the default improvements will make their way into all of the browsers. Until then, this also evens the field across all of the browsers but for me the really exciting part is exposing it to Workers so sites can customize the logic specific to their needs. Boosting the priority of hero images or async scripts that are important for the site but the browser's default logic has no way to know. Priority hints (also Chrome-only currently) will eventually bring that to browsers natively. Full disclosure, I'm the article author and I also spent several years on the Chrome team working on the resource loading/scheduler so it's probably not too surprising that there are similarities.
- dullgiulio 7y ago
  I am not sure it is a good idea to trust the server to decide what is more important. I can easily imagine ads taking higher priority than actual content, just look at the pop-ups that interrupt reading. Browsers and protocol should start concentrating on how to secure users from the very sites they visit.
  - pornel 7y ago
    Prioritization works within a single HTTP/2 connection. Ads are generally served by a 3rd party, and while there are some limited ways of sharing HTTP/2 connections across origins, I don't think any ad servers offer such a close integration. Besides, sites already have blunt tools they can use if they really wanted to force ads to load first. This feature is more for site developers who care about performance. Instead of tweaking the markup and adding hints to help browsers request resources in the right order, they can now set the priorities directly and precisely.

pornel 7y ago

The big take-away from this is that "HTTP/2" is not the same thing everywhere. Quality of implementation matters. We didn't see so much variation in HTTP/1, because servers had almost no control, and clients were opening multiple connections, so even bad prioritization was hidden by TCP-level parallelism. In HTTP/2 we've reached a good level of interoperability, but bolting on HTTP/2 on top of a server architected for HTTP/1 is not enough. We have room for optimizations and maturity.

merb 7y ago
well h2 for development is really hard since basically you need to create a certificate, because no major browser implements h2 over plaintext. i mean a lot of people can live with that and just insert a development certificate into their trust chain, but some people do not understand that and others work in more restricted environments. so basically fully controlling and developing with h2 is basically not as easy as it was with http/1.
- pornel 7y ago
  For server development the hard part is simulating realistic network conditions. For example, on localhost, you'll never witness any prioritization happening, because you'll never grow a queue of responses still waiting to be sent down.
  - zamadatix 7y ago
    Browser Dev tools pretty much cover that in one click these days.
- tlrobinson 7y ago
  Has anyone just published a valid certificate for a domain name that resolves to 127.0.0.1?
  - Ayesh 7y ago
    For your own use, you can obtain a certificate via DNS validation, or by pointing your DNS A records to a server with a public IP. When you publish the private key online, anyone can revoke the certificate, or the CA themselves will.

tempguy9999 7y ago

I block all JS and have a comprehensive blocklist for just about every ad service there is. Stuff usually loads damn fast (ok, when not broken by JS missing, an acceptable price to me, I get speed and safety for free). I always recommend people try it. It's fast enough except when webbish types do stupid things. Just yesterday I was looking at a Scientific American article which was held up by an entirely pointless 2.6MB gif, this one <https://static.scientificamerican.com/blogs/cache/file/80C4493E-6185-4B03-8BB3D50C6EFE5DB1_source.gif?w=590&h=800&F16593DB-37EB-46A1-ADBFDD2EC7B05A93> https://static.scientificamerican.com/blogs/cache/file/80C44.... Quanta articles are bloody nuts too, check this shit, a 4MB animation that tells you nothing. Fucking nothing. Absolfuckinglutely sweet FA. (Edit, forgot link; here: <https://www.quantamagazine.org/mathematicians-discover-the-perfect-way-to-multiply-20190411/> https://www.quantamagazine.org/mathematicians-discover-the-p...) We have a fast web, what we also have are idiots - technical solutions to idiocy aren't solutions. (NB 'scuse swearing)

tempguy9999 7y ago
Downvoted for the bad language perhaps? I'd accept that. Or downvoted for recommending a blocklist to cap off ad networks? Or to disable JS to speed things up and increase my safety without new protocols? Or asking not to have my browsing turned into an Awesome Experience by web designers that don't understand the web is a means to an end for its users, not a way of life? Or something else?
- jandrese 7y ago
  I don't know about the downvotes on your original comment, but comments complaining about being downvoted will always attract more downvotes.
  - tempguy9999 7y ago
    I didn't complain, I asked why. It may well be down to my rather abrasive style, in which case I'd apologise and try to be less so next time. Or it may be down to me being factually wrong, which I also need to know cos how else does one learn. Or maybe someone doesn't like what I said which is very much another thing. But I wasn't complaining.

forgotmypw14 7y ago

The web is quite fast already, if you don't weigh down your web pages with tens of megabytes of crap...

MrStonedOne 7y ago

I don't know that their assumption about bandwidth getting maximized period is correct.

3xblah 7y ago

"Web pages are made up of dozens (sometimes hundreds) of separate resources that are loaded and assembled by the browser into the final displayed content." Could that be the reason that that the web needs to be "faster" (despite tremendous advances in CPU, storage, bandwidth and network speeds)? The dozens (sometimes hundreds) of separate resources are loaded by default. What is their purpose? Where do they come from? Are all of them necessary? What if an advanced user could tell the browser to only load certain resources from certain sources? For example, maybe skip certain ads and tracking, as specified by the user. Perhaps do not load the Facebook "Like" buttons (images), but load all other images. Control exactly which Javascripts to load. In addition to the options that browsers now provide, provide more fine-grained controls. Could that make the web faster? A bonus would be if these user-defined, fine-grained browser settings could be saved in a portable, interoperable format, e.g. to external media, in addition to being able to save them to "the cloud" (which may be servers run by advertising-supported browser authors). Browser authors do not need to know which resources users may wish to block.

ben_jones 7y ago
Humans don't naturally optimize down to the byte level, be it a whole foods cashier who takes an extra 30 seconds to bag your groceries, an airline who's pilot needs to use the restroom and delays takeoff, or whatever other situation where convenience takes precedent. When and how often should human hours be spent to optimize machine hours? Sometimes clearly, but should they always? Where is the line? I think these questions define the whole javascript bloat problem, there is no clear answer so it varies company-by-company and developer-by-developer to the detriment of all involved.
- tempguy9999 7y ago
  > Humans don't naturally optimize down to the byte level, Who said bytes? You did. Other commenters including myself have mentioned megabytes (ie. six orders of magnitude larger). Nobody said bytes AFAICS. > When and how often should human hours be spent to optimize machine hours Oooh, perhaps I can help! Being as I'm currently trying to shave 200 to 300 milliseconds at a time off one stage of a simulation, taking 2 to 6 hours for each optimisation. So 4 to 5 orders of magnitude more programmer time than machine time. That way larger models can be used, and all of multiple multiple sites will benefit, and less of their time will be spent waiting (see disclosure below). It's not actually that difficult an inequality to solve, except when haystacks of JS and advert crud are pushed on us by advertisers etc. whose money is made by wrecking the commons for their profit so don't want to know. “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” - Upton Sinclair disclosure, I'm actually doing this unpaid as I'm getting back into work after illness, however if I wasn't there they'd get someone else in, paid, as it needs doing.

ken 7y ago

Don't some of these browsers display a best-approximation font, while the actual font file is downloading, while others display no text until the font file is available? That seems like an awfully big distinction which is omitted here.

patrickmeenan 7y ago
It is more site-dependent than browser dependent but by default (unless the dev overrides) most browsers will leave the text blank for 3 seconds after the font is discovered before falling back. In most (all?) of the cases in the blog post, the actual font loading is within that 3-second window, the issue is that the layout-blocking content (preventing the browser from discovering the font) is what is slow.

TomGullen 7y ago

Would love to enable HTTP2 on Cloudflare on our site, but there seems to be a bug with it in Cloudflare where it randomly stops requests, and we're stuck in an endless support loop so we have to disable it on our PWA which would have huge benefits for it.

matsur 7y ago
Can you get in touch? rustam@cloudflare.com. I’d love to get to the bottom of this.

Matthias247 7y ago

As someone who has implemented HTTP/2 too (for the apparently unpopular .NET ecosystem) I am guilty of totally missing out on the prioritization feature too. There's definitely some good ideas and use-cases in the article that make it more worthwhile! Some things I'm wondering about: The proposed strategy seems to prefer sometimes sending single resources in a sequential fashion instead of lots of resources in parallel. Doesn't that essentially bring the communication back into a HTTP/1.1 style with less parallelism - and only with the benefit of no extra connections? And how well does the approach fit together with browsers flow control windows? If a browser set a small flow control window per stream then sending only a single object at a time wound still require lots of round-trips for flow control window updates - which might make it worse than HTTP/1.1. However I heard at some time that browsers have configured huge flow control windows. If that's true it seems more likely to work out (and the default strategy where HTTP/2 prefers parallelism over throughput seems worse).