Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better HTTP/2 Prioritization for a Faster Web

blog.cloudflare.com

Post reply on HN
Print view View original

31–40 of 52 posts

Re: Better HTTP/2 Prioritization for a Faster Web

#31

Post by patrickmeenan »

ken wrote: post #29

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.

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.

Re: Better HTTP/2 Prioritization for a Faster Web

#32

Post by merb »

pornel wrote: post #8

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

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.

Re: Better HTTP/2 Prioritization for a Faster Web

#33

Post by jazzyjackson »

tempguy9999 wrote: post #18
tempguy9999 wrote: post #11

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…

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?

I always upvote comments that encourage turning off javascript, but there's quite an HN population that thinks you're living in the 60s and deserve to be left behind if you don't run every program a website downloads :)

Re: Better HTTP/2 Prioritization for a Faster Web

#34

Post by paulddraper »

3xblah wrote: post #17

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

> What is their purpose?

Icons.

> Where do they come from?

They are designed.

> Are all of them necessary?

No, but also yes.

Re: Better HTTP/2 Prioritization for a Faster Web

#35

Post by CJefferson »

tempguy9999 wrote: post #25
jandrese wrote: post #24

Earlier quoted context omitted.

I don't know about the downvotes on your original comment, but comments complaining about being downvoted will always attract more downvotes.

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.

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.

Re: Better HTTP/2 Prioritization for a Faster Web

#36

Post by tempguy9999 »

CJefferson wrote: post #35
tempguy9999 wrote: post #25

Earlier quoted context omitted.

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.

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

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

Re: Better HTTP/2 Prioritization for a Faster Web

#37

Post by forgotmypw14 »

3xblah wrote: post #28
ignoramous wrote: post #22

Earlier quoted context omitted.

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

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

>The question is why browsers do not have these capabilities natively.

Money.

Re: Better HTTP/2 Prioritization for a Faster Web

#38

Post by pornel »

merb wrote: post #32
pornel wrote: post #8

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

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

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.

Re: Better HTTP/2 Prioritization for a Faster Web

#40

Post by FridgeSeal »

3xblah wrote: post #28
ignoramous wrote: post #22

Earlier quoted context omitted.

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

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

Firefox seems to be in the process of gradually implementing a lot of user privacy and control measures.
Post reply on HN