5 ms·

Is fetching 200 image tiles really a realistic benchmark? I'd like to see benchmarks for more realistic pages.

eyelidlessness 10y ago
So add 30 JavaScript files, a few dozen template files to be rendered by one or more of those JS files, a whole bunch of CSS files and at least 6 fonts. HTTP/2 is almost certainly going to perform even better under those circumstances. Edit: oh and throw in a few videos, everything has a video or two nowadays.
- tracker1 10y ago
  I consider JS and even CSS part of the app... to me a lot of the text, images and videos are external content better on a second/dedicated resource (or CDN). Not to mention that properly supporting video can take a bit of work on its' own if you want to dynamically up/down-grade the stream.
ltybcrf 10y ago
quite a bit of mobile games and apps rely on tens and often hundreds of small resources, each of them needing in periodic caching and update, which makes loading hundreds of resources simultaneously both very realistic scenario and eliminating the need for home-brew caching and resource packs update mechanisms
strommen 10y ago
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.
kiallmacinnes 10y ago
I know others have replied already, but I don't think anyone has outright said it - Yes. This is a realistic benchmark, but only if you remove the many years of "optimizations" we've been baking into web apps. e.g. Remind me why I should be concatenating all my JS/CSS files into one again? and why exactly do I have 6 hostnames for that 1 static server? 200 resource fetches really isn't that many once you, and your framework authors, remove these and other HTTP/1 workarounds.
colejohnson66 10y ago
Maybe for maps?

So add 30 JavaScript files, a few dozen template files to be rendered by one or more of those JS files, a whole bunch of CSS files and at least 6 fonts. HTTP/2 is almost certainly going to perform even better under those circumstances. Edit: oh and throw in a few videos, everything has a video or two nowadays.

tracker1 10y ago
I consider JS and even CSS part of the app... to me a lot of the text, images and videos are external content better on a second/dedicated resource (or CDN). Not to mention that properly supporting video can take a bit of work on its' own if you want to dynamically up/down-grade the stream.

ltybcrf 10y ago

quite a bit of mobile games and apps rely on tens and often hundreds of small resources, each of them needing in periodic caching and update, which makes loading hundreds of resources simultaneously both very realistic scenario and eliminating the need for home-brew caching and resource packs update mechanisms

strommen 10y ago

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.

kiallmacinnes 10y ago

I know others have replied already, but I don't think anyone has outright said it - Yes. This is a realistic benchmark, but only if you remove the many years of "optimizations" we've been baking into web apps. e.g. Remind me why I should be concatenating all my JS/CSS files into one again? and why exactly do I have 6 hostnames for that 1 static server? 200 resource fetches really isn't that many once you, and your framework authors, remove these and other HTTP/1 workarounds.

colejohnson66 10y ago

Maybe for maps?