
Better HTTP/2 Prioritization for a Faster Web - zspitzer
https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/
======
pornel
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
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
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
Browser Dev tools pretty much cover that in one click these days.

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

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

------
3xblah
"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.

~~~
ignoramous
80%, if not more, of what you describe is do-able with Raymond Hill's uMatrix
[0]. And yes, it does make the web faster and safer, though it breaks certain
websites.

\--

[0]
[https://github.com/gorhill/uMatrix/blob/master/README.md](https://github.com/gorhill/uMatrix/blob/master/README.md)

~~~
3xblah
True, there are ad-ons to address such browser deficiencies. The question is
why browsers do not have these capabilities natively. Clearly, a large number
of users want them.

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.

~~~
FridgeSeal
Firefox seems to be in the process of gradually implementing a lot of user
privacy and control measures.

------
tempguy9999
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/80C44...](https://static.scientificamerican.com/blogs/cache/file/80C4493E-6185-4B03-8BB3D50C6EFE5DB1_source.gif?w=590&h=800&F16593DB-37EB-46A1-ADBFDD2EC7B05A93>).

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...](https://www.quantamagazine.org/mathematicians-discover-the-perfect-
way-to-multiply-20190411/>))

We have a fast web, what we also have are idiots - technical solutions to
idiocy aren't solutions.

(NB 'scuse swearing)

~~~
tempguy9999
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
I don't know about the downvotes on your original comment, but comments
complaining about being downvoted will always attract more downvotes.

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

~~~
CJefferson
I didn't downvote you, but your post did annoy me. This is an interesting
article about HTTP/2.

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.

~~~
tempguy9999
> I didn't downvote you, but your post did annoy me. This is an interesting
> article about HTTP/2.

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?

~~~
CJefferson
The protocol is solving a real world problem. They are trying to apply a
technological solution to a real world problem.

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.

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

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

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

~~~
jacques_chester
From my understanding the better policy will be to prioritise the smallest
assets first. To me it seems counter-intuitive but apparently it proves out in
theory and testing:
[https://www.cs.cmu.edu/~harchol/Papers/usits1.pdf](https://www.cs.cmu.edu/~harchol/Papers/usits1.pdf)

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](https://www.cs.cmu.edu/~harchol/Papers/MIT-LCS-TR-767.pdf)

Apologies if you're already familiar with these.

~~~
lucaspardue
These papers are interesting, thanks for sharing.

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.

~~~
jacques_chester
I'm not sure I follow. Proxies don't have much time to reorder from an
upstream on the first time writing through to their downstream. But once it's
in their local cache it would become possible to apply the smallest-first
logic, wouldn't it?

~~~
lucaspardue
This depends on how the proxy is configured to behave. One common pattern is
to have a protocol terminating proxy talk to the client. Other component(s)
sit behind this and they could be other parts of the system, tiers of caches
or tiers of CDNs.

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.

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

------
TomGullen
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
Can you get in touch? rustam@cloudflare.com. I’d love to get to the bottom of
this.

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

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

