Better HTTP/2 Prioritization for a Faster Web
blog.cloudflare.com
blog.cloudflare.com
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.
When you publish the private key online, anyone can revoke the certificate, or the CA themselves will.
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.
700ms vs 800ms is the difference between acceptable and a slow loading web site.
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.
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.
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.
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.
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.
--
[0] https://github.com/gorhill/uMatrix/blob/master/README.md
Note that the 20% in your estimate are quite significant.
As for "breaking websites", perhaps in the evolution of a web to be faster, those "certain websites" with too many third-party dependencies should be selected against, not for.
Another interesting question is whether something like HTTP/2 developed by an advertising company encourages the inclusion of more third-party resources, perhaps in the form of advertising and tracking, or does it encourage less, in the form of smaller, faster, safer websites? It appears to be overkill for the later.
Money.
Icons.
> Where do they come from?
They are designed.
> Are all of them necessary?
No, but also yes.
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/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-p...)
We have a fast web, what we also have are idiots - technical solutions to idiocy aren't solutions.
(NB 'scuse swearing)
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?
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.
Downvotes are inevitable when you start making comments regularly, don't worry about them too much. It's all fake Internet points in the end.
I guess I'm being that guy who just won't let things go, so thanks for the reminder to chill out, upvoted!
Yes, we know people should make smaller web pages with less javascript and ads, and we could all install a bunch of plugins to achieve that, but multiple replies like yours do seem to appear on every single post that has anything to do with network traffic, and don't really contribute (in my opinion) to the discussion at hand.
Thanks, that's a nice, constructive criticism and I appreciate it. My post was in retrospect not exactly a piece of precision, so let me try again if I may...
I recently worked on a "big data" project that wasn't. It was a car crash because the "big data" conponents were thrown together with a very expensive cluster (>£100,000) of machines. The end result crawled because the lead programmer didn't gave a clue. I am pretty sure I could have got minimum 100X the performance for ~5% of the price.
When I'm asked to optimise something (a common request) I first ask, is this doing the right thing - is this really a technical problem at all? Can we just not do it? Followed by, what are you doing that makes this so much less than the theoretical max performance?
(Edit: the point was the big data components (apache spark, mesos etc) weren't necessary because we didn't have big data at all, and performance was dire because he didn't know how to use those components)
What we have here is a social problem of web devs simply not understanding their job, combined with the problem of advertisers who I loathe but seem to be a product of many user's desire to not pay a single penny upfront. Both of these are non-tech problems. This article is pushing a tech solution, but should it, really?
I don't think being abrasive was a good move by me, but you say "...should make smaller web pages with less javascript and ads [and my post doesn't]really contribute (in my opinion) to the discussion at hand" but I think it does. I think it central, actually. Or what problem is this new protocol solving?
Many problems could be solved if we could just make every Web developer and company in the whole world take size / data security / accessibility more seriously, but human history suggests that ain't happening, without in practice introducing laws.
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.
Browsers and protocol should start concentrating on how to secure users from the very sites they visit.
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.
More dramatic improvement might be possible if streams can be interrupted and resumed (which is something protocols like RSocket support): https://www.cs.cmu.edu/~harchol/Papers/MIT-LCS-TR-767.pdf
Apologies if you're already familiar with these.
However, the primary axiom is of a web server that is serving static content that is located on the device. That, in a sense, gives almost infinite time and knowledge to deciding prioritisation of work.
For HTTP proxies that have to fetch resources from some other server, the time and knowledge window becomes much shorter. Decision making needs to be done quickly in order to minimise the latency of returning anything. And the upstream server may response in unexpected ways.
This is the challenge for today's CDN deployments. And developing a solution that works for the huge variety of how websites are developed is the really interesting bit.
Even if the proxy does cache locally to memory or disk. Without infinite space, there will be some chance of cache eviction and a need to fetch from the upstream again.
Our scenarios are different ends of a broad spectrum, and there's a lot in between. Which is why getting prioritisation right is a hard nut to crack.
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).