5 ms·

This demo is not realistic at all, and is pretty contrived to play to the strengths of HTTP/2. If your page loads stuff from 25 different domains, HTTP/2 barel

This demo is not realistic at all, and is pretty contrived to play to the strengths of HTTP/2. If your page loads stuff from 25 different domains, HTTP/2 barely helps at all. Likewise if your page is loading MB-size image or script files. Likewise if your server takes 2+ seconds to render the darn HTML in the first place. But HTTP/2 is awesome when all the resources come from the same domain, because it eliminates the bottleneck of separate TCP/TLS connections. This means you don't have to do stuff like bundling resources and sharding domains. And indeed you shouldn't do this stuff if you're using HTTP/2. HTTP/2's biggest problem is that nobody is changing their site to take advantage of its benefits.

dexwiz 10y ago
How websites are built is directly influenced by limitations of HTTP. Browsers limit the number of simultaneous connections per hostname. HTTP 1.1 specifies 2 per hostname, but most browsers allow for 6, some more, some less[1]. So if you are server a bunch of assets at once, you want to spread it across multiple host names (usually edge servers of some sort), so you can get more total, simultaneous connections. HTTP/2 specifically allows for all assets to come from one host. HTTP/2 also has better negotiation on the number of connections allowed and their direction. These changes will see widespread use once CDNs start to take advantage of it. If you are serving a big enough website to take advantage of HTTP/2, you are using edge servers. [1] http://www.browserscope.org/?category=network&v=top http://www.browserscope.org/?category=network&v=top
ldng 10y ago
Well HTTP/2 is awesome ... for web applications where you might not have to interact with third parties (ie Google's usecase and they build it in the first place IMHO). When you have a web site this is a totally different story : beside your content and statics, you'll have maps from a CDN, widgets from third parties, ads ... and so on. "changing their site to take advantage of its benefits" is just not realistic for normal website.
ytch 10y ago
If you are going to serve MB-size resources, why not split it to many small files so HTTP/2 can multiplex the download requests of them. See the "Stop Concatenating Files" part of this article : https://blog.cloudflare.com/http-2-for-web-developers/ https://blog.cloudflare.com/http-2-for-web-developers/
tracker1 10y ago
Given the bundling of JS and often CSS in modern web-apps via build tools, I've been a proponent of serving html/js/css from the same serve as a front-facing API host... this way almost everything comes from the same place. This works better still with HTTP/2. It's getting more and more like having a CDN in between your primary app and the user is of less benefit... having one for an image-store if you have a lot of images may be an okay idea. Images tend to be the bulk of a web page's weight for a lot of apps. Even SPAs. I think where this will really start to shine is when browsers get js module support internally... combined with http/2 and some smarter server-side rendering, that could be a really nice place to be.

dexwiz 10y ago

How websites are built is directly influenced by limitations of HTTP. Browsers limit the number of simultaneous connections per hostname. HTTP 1.1 specifies 2 per hostname, but most browsers allow for 6, some more, some less[1]. So if you are server a bunch of assets at once, you want to spread it across multiple host names (usually edge servers of some sort), so you can get more total, simultaneous connections. HTTP/2 specifically allows for all assets to come from one host. HTTP/2 also has better negotiation on the number of connections allowed and their direction. These changes will see widespread use once CDNs start to take advantage of it. If you are serving a big enough website to take advantage of HTTP/2, you are using edge servers. [1] http://www.browserscope.org/?category=network&v=top http://www.browserscope.org/?category=network&v=top

ldng 10y ago

Well HTTP/2 is awesome ... for web applications where you might not have to interact with third parties (ie Google's usecase and they build it in the first place IMHO). When you have a web site this is a totally different story : beside your content and statics, you'll have maps from a CDN, widgets from third parties, ads ... and so on. "changing their site to take advantage of its benefits" is just not realistic for normal website.

ytch 10y ago

If you are going to serve MB-size resources, why not split it to many small files so HTTP/2 can multiplex the download requests of them. See the "Stop Concatenating Files" part of this article : https://blog.cloudflare.com/http-2-for-web-developers/ https://blog.cloudflare.com/http-2-for-web-developers/

tracker1 10y ago

Given the bundling of JS and often CSS in modern web-apps via build tools, I've been a proponent of serving html/js/css from the same serve as a front-facing API host... this way almost everything comes from the same place. This works better still with HTTP/2. It's getting more and more like having a CDN in between your primary app and the user is of less benefit... having one for an image-store if you have a lot of images may be an okay idea. Images tend to be the bulk of a web page's weight for a lot of apps. Even SPAs. I think where this will really start to shine is when browsers get js module support internally... combined with http/2 and some smarter server-side rendering, that could be a really nice place to be.