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

11–20 of 52 posts

Re: Better HTTP/2 Prioritization for a Faster Web

#11

Post by 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 " rel="nofollow">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: " rel="nofollow">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)

Re: Better HTTP/2 Prioritization for a Faster Web

#12

Post by derefr »

skybrian wrote: post #2

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.

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

Re: Better HTTP/2 Prioritization for a Faster Web

#15

Post by skybrian »

WhiteOwlLion wrote: post #10
AndrewStephens wrote: post #5

Earlier quoted context omitted.

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

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.

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.

Re: Better HTTP/2 Prioritization for a Faster Web

#16

Post by vbezhenar »

WhiteOwlLion wrote: post #10
AndrewStephens wrote: post #5

Earlier quoted context omitted.

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

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.

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?

Re: Better HTTP/2 Prioritization for a Faster Web

#17

Post by 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.

Re: Better HTTP/2 Prioritization for a Faster Web

#18

Post by tempguy9999 »

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?

Re: Better HTTP/2 Prioritization for a Faster Web

#19

Post by zzzcpan »

skybrian wrote: post #15
WhiteOwlLion wrote: post #10

Earlier quoted context omitted.

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.

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.

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

Re: Better HTTP/2 Prioritization for a Faster Web

#20

Post by ben_jones »

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…

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.

Post reply on HN