HTTP/2 Demo: Under the Hood

At first glance, the potential performance improvements of HTTP/1.1 versus HTTP/2 on our demo page may seem a bit hard to believe. So, we put together a technical explanation of how this demo actually works. We’d also like to credit the Gophertiles demo, which served as a basis for our own HTTP/2 demo.

A web page can only be served over either HTTP/1.1 or HTTP/2—mixing protocols is not allowed. Our demo page is HTTP/2-enabled, so there’s no way to load HTTP/1.1 content directly on the same page. Inline frames (iframes) can be used to solve this issue. We embedded two iframes on our demo page, both containing the same source code. The key difference is that one iframe loads over an HTTP/1.1 CDN while the other loads over an HTTP/2 CDN.

We chose Amazon CloudFront for the HTTP/1.1 CDN because it can only serve content over HTTP/1.1. For the HTTP/2 CDN, we’re using our own HTTP/2-enabled network. You can take a look at the individual HTTP/1.1 and HTTP/2 iframe content, which should have similar load times to the side-by-side example on our demo page.

So, what is contained in each of these iframes? Each one is a full HTML page with JavaScript that builds <img> tags in sequential order. To clearly illustrate the performance gains of HTTP/2, 200 image tiles are requested in a short amount of time. A single large image was split up into 200 40x40 tiles with an image processing library called ImageMagick using the following command:

convert -crop 40x40 +repage http2.png tile-%d.png

As the JavaScript loads these images, it keeps track of when the last image loads as well as the total load time of all images. Once this happens, the iframe needs to report the metrics to the parent window (the demo page itself).

Due to iframe cross-domain security rules, JavaScript cannot query the DOM of the iframe when the iframe is hosted on another domain. However, the iframe can send a message to the parent window using the Window.postMessage method. The parent window listens for this message using either an addEventListener or attachEvent method. When both iframes have loaded their content, the performance difference is displayed on the demo page.

By default, CloudFlare’s CDN tries to cache as much as possible to get the best possible performance. This caused a problem for our HTTP/2 demo because various browsers were caching the image tiles locally, rendering our demo page rather useless. To fix this, we forced both the HTTP/1.1 and HTTP/2 CDNs to cache everything edgeside, but store nothing in the local browser cache.

A Nifty Firefox Caching Bug/Feature

If you’re a Firefox user, you’ll notice that when you hit the Reload button on the demo page, the full image will display immediately even though the timers keep counting. This is because Firefox doesn’t respect our instructions to not cache the image tiles in the browser, even though we explicitly tell it not to.

Firefox made a decision some years ago to cache everything, including assets with no-cache headers. The rationale behind it is actually quite sound—it allows immediate forward/back navigation and better offline browsing functionality. With the exception of these kinds of demos, there’s no real downside.

Anyways, if you want to reload the demo in Firefox with the correct image-loading behavior, you can do a hard refresh with Cmd+Shift+R or Ctrl+Shift+R.

Part of CloudFlare’s unique value proposition for HTTP/2 is an automatic SPDY fallback. When a visitor’s browser supports HTTP/2, our edge network will use HTTP/2. If it supports SPDY but not HTTP/2, we’ll respond in SPDY. Otherwise, we’ll fall back to HTTP/1.1. As discussed in our HTTP/2 announcement blog post, this lets us continue supporting about 57% of Internet users that are SPDY-enabled, but not HTTP/2-enabled.

So, if you’re using Safari 8 or an Android browser, don’t worry! You may not be able to see the HTTP/2 demo, but our edge servers will fall back to SPDY, which should provide similar results.

The goal of our HTTP/2 demo is to clearly visualize the main benefits of HTTP/2 in a real-world environment. While it’s served up by real CDNs and transmitted over the same Internet cables that everybody else uses, it’s still an idealized scenario. The large number of image tiles highlights the efficiency of HTTP/2 multiplexing, but it’s not necessarily representative of your average web page.

It’s hard to provide general predictions about the performance improvements that any individual website can expect to see with HTTP/2 because it depends heavily on the structure of your web pages. If your website loads 200 tiny images simultaneously, then you’ll likely see speedups similar to our demo. Most web pages rely on fewer external assets, which means they may have less dramatic performance gains.

However, the HTTP/2 protocol was designed specifically to reduce web page load times as perceived by end users. The typical website should see some kind of significant performance gain just by switching to HTTP/2.