Better HTTP/2 Prioritization for a Faster Web
blog.cloudflare.com
Better HTTP/2 Prioritization for a Faster Web
1–10 of 52 posts
Re: Better HTTP/2 Prioritization for a Faster Web
#2It 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.
Re: Better HTTP/2 Prioritization for a Faster Web
#3[deleted]
Re: Better HTTP/2 Prioritization for a Faster Web
#4So 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.)
Re: Better HTTP/2 Prioritization for a Faster Web
#5It 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.
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.
Re: Better HTTP/2 Prioritization for a Faster Web
#6So 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.)
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
Re: Better HTTP/2 Prioritization for a Faster Web
#7So 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.)
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.
Re: Better HTTP/2 Prioritization for a Faster Web
#8The 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.
Re: Better HTTP/2 Prioritization for a Faster Web
#9It 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.
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…
It's important to remember that with the death of net neutrality in the US, this may not be the case forever.
Re: Better HTTP/2 Prioritization for a Faster Web
#10It 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.
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.