Previously, we showcased browser market share data from our own website. Using these numbers, we predicted the ratio of HTTP/2 traffic that we expected to see once enabled. Now, we can compare this original data set with updated data from the last 48 hours.

Below is the market share of HTTP/2 capable browsers that we saw on our website during a 48-hour period. The first one was before our HTTP/2 launch, the other one was last week. Both data sets were pulled from Google Analytics, and user agents were analyzed for HTTP/2 support.

Since November, the number of browsers visiting CloudFlare.com that support HTTP/2 has more than doubled. In particular, notice how the market share of Chrome and Firefox versions that support HTTP/2 increased dramatically within the last 2 months.

The reason for this is, that even with Auto-Update functionality in modern browsers, new versions are not adopted instantaneous. We had documented the release of iOS 9, which is an example for a quite swift adoption. Looking at the challenges around the SHA-1 deprecation, we can see that some ancient OS and browser version are still around.

Keep in mind that we still see a larger number of non-browsers that don’t fall into any of the above buckets on our edge network. This is due to bots, crawlers, scrapers, and the like. The numbers above represent typical website traffic after it has been sanitized by CloudFlare.

With the promising browser market share data above, we can now compare the ratio of traffic served via the different HTTP versions on www.cloudflare.com.

Again, contrast the data from around our release in December to the current data.

The great news: the HTTP/2 traffic ratio has indeed more than doubled on www.cloudflare.com since we rolled out HTTP/2.

Nevertheless, we are still serving a large portion of traffic over SPDY, mostly due to older versions of Chrome. Therefore, it was a good choice to keep supporting this protocol version.

So far, we have looked at what an individual HTTP/2 enabled site on CloudFlare could expect to see with regard to traffic and different browser versions. Let’s shift gears a bit and have a look at how many websites we have actually enabled with HTTP/2 so far:

The website isthewebhttp2yet.com is a great tool for finding an answer to this question. It is created and maintained by researchers at Telefónica Research, Case Western Reserve University, and Carnegie Mellon University, and provides an overview of how many websites from the Alexa 1M list are enabled with HTTP/2.

The website differentiates between:

• Announced Support: Sites indicate which application-layer protocols they support using NPN/ALPN. If a site indicates HTTP/2, it is considered as "Announced Support."

• Partial Support: Some sites that announce HTTP/2 support, but immediately downgrade the connection to HTTP 1.1 if a client makes a request using HTTP/2. If a site responds using HTTP/2, even just to return an error page or redirect, this is classified as partial support.

• True Support: If a site actually serves page content using HTTP/2, even if some embedded objects are still served over HTTP 1.1, this is called true support.

In this post, we will only focus on websites with "True Support"—since that’s what you get with CloudFlare—and will ignore the other two metrics.

Looking at the HTTP/2 adoption curve for the Alexa 1 million shows quite an interesting picture:

Source

You can see a sharp increase of domains with "True Support" in December 2015, bringing the number of domains with “True Support” from 14,017 (December 1st, 2015) to 75,288 (December 31st, 2015).

According to isthewebhttp2yet.com, 58,591 of these domains run through CloudFlare. That means CloudFlare more than quadrupled the number of HTTP/2 sites with the December 2015 release.

We’d like to give a big shout-out to the team of isthewebhttp2yet.com. They worked with our engineers to update their measurement method to include the Server Name Indication (SNI) TLS extension when they probe sites for HTTP/2 support. By doing so, the site is able to identify all CloudFlare-powered sites. You can see this measurement change kicking in within the above graph at the sharp increase from 24,947 domains to 74,271 domains.

Another website measuring the adoption of HTTP/2 on the server side is W3 Techs. While the graph generated by W3 Techs for HTTP/2 adoption is much more coarse grained on the time axis, the increase of HTTP/2 enabled websites due to CloudFlare is nevertheless clearly visible.

Source

With our wide support of HTTP/2 for all CloudFlare customers, we have also helped to improve the market position—with regard to popularity and traffic—of HTTP/2 close to that of SPDY.

Source

Want to help us grow our software engineering team and increase our protocol support? Check out our available roles.

As a reminder, if you are a customer on the Free or Pro plan, there is no need to do anything at all. Both SPDY and HTTP/2 are already enabled for you. With this improvement, your website’s audience will always use the fastest protocol version when accessing your site over TLS/SSL.

Customers on Business and Enterprise plans can enable HTTP/2 within the "Network" application of the CloudFlare Dashboard. In the last two months, the web still hasn't exploded while running HTTP/2. With that in mind, it's probably safe for you to head over an enabled HTTP/2 now. You will be in great company with many other sites.

If you are not yet a customer of CloudFlare, sign up now, and you’ll be able to leverage HTTP/2 within a few minutes.

Stay tuned for more additions to our HTTP/2 capabilities!

If you are a customer on the Free or Pro plan, there is no need to do anything at all. Both SPDY and HTTP/2 are already enabled for you. With this improvement, your website’s audience will always use the fastest protocol version when accessing your site over TLS/SSL.

Customers on Business and Enterprise plans can enable HTTP/2 within the "Network" application of the CloudFlare Dashboard.

In February 2015, the IETF’s steering group for publication as standards-track RFCs approved the HTTP/2 and associated HPACK specifications.

After more than 15 years, the Hypertext Transfer Protocol (HTTP) received a long-overdue upgrade. HTTP/2 is largely based on Google's experimental SPDY protocol, which was first announced in November 2009 as an internal project to increase the speed of the web.

The main focus of both SPDY and HTTP/2 is performance, especially latency as perceived by the end-user while using a browser, with a secondary focus on network and server resource usage. One large benefit of HTTP/2 is the ability to use a single TCP connection from a browser to a website, or in the case of CloudFlare, a reverse proxy. As such, CloudFlare is in the perfect position to provide the benefits of HTTP/2 to all CloudFlare users by accelerating the web surfing experience between browsers and CloudFlare, without the need to change anything on the origin server.

Although HTTP/2 is based on Google's experimental SPDY protocol, it has evolved, incorporating several improvements in the process. Nevertheless, it maintains many of the benefits known from SPDY:

• Multiplexing and concurrency: Several requests can be sent over the same TCP connection, and responses can be received out of order, eliminating the need for multiple connections between the client and the server and reducing head-of-line blocking.

• Stream dependencies: The client can indicate to the server which resources are more important than others.

• Header compression: HTTP header size is reduced.

• Server push: The server can send resources the client has not yet requested (This is not yet implemented within NGINX or at CloudFlare, but will become available in the future. It is currently enabled on the experimental test bed server https://http2.cloudflare.com/).

While the HTTP/2 specification does not require TLS, all major browser vendors have indicated that they will only support HTTP/2 over a TLS connection. As a result, CloudFlare only supports HTTP/2 over TLS. Of course, TLS is free with CloudFlare’s Universal SSL.

Let’s have a look at some real life numbers from the CloudFlare website (https://www.cloudflare.com) for average page load time. These values (based on a 48h timeframe) should provide an estimate of what improvements you can expect using SPDY and HTTP/2:

CC BY 2.0 image by woodleywonderworks

It's no secret that CloudFlare uses a modified version of NGINX as the reverse proxy component in charge of terminating the end-user connection. After NGINX announced availability of the NGINX Open Source 1.9.5 Release with HTTP/2 support on September 22nd, the wait for HTTP/2 seemed to be over.

The introduction of the new HTTP/2 module for NGINX also meant that the existing NGINX SPDY module could not be used in parallel. You had to choose to either support the termination of HTTP/2 or SPDY connections on a single NGINX server, but not both. The justification for this approach was based on Google saying goodbye to SPDY and deprecating the protocol, starting in January 2016.

But what would have actually happened if CloudFlare turned off SPDY today while turning on HTTP/2? What would be the impact on our existing user base as well as our customers? As the best decisions are always ones backed by solid data, we looked at what replacing SPDY with HTTP/2 today would mean.

CloudFlare started support for SPDY in June 2012 and upgraded to the current version of SPDY (3.1) in February 2014. It’s pretty straightforward for us to determine how many SSL/TLS connections are established today via SPDY/3.1 versus HTTP/1.x.

During the week before our HTTP/2 launch, 80.38% of all SSL/TLS connections to our own website at www.cloudflare.com were made over SPDY/3.1.

The overall ratio of SPDY/3.1 connections that we see on our network is lower than this due to the number of bots, scrapers, and attackers using HTTP/1.x. Instead, the above number is a good representation of what legitimate traffic a regular website should see, after traffic has been sanitized.

Without actually rolling out HTTP/2, it’s not that easy to determine what percentage of users to any individual website will benefit. But, there are two approaches to getting a useful estimate up front.

Let's start with the one that you could easily replicate yourself for your own website by using Google Analytics.

The well-known website caniuse.com provides information on what browsers and their version support HTTP/2. Combine this with data from Google Analytics on how often a website was accessed by this type of browser for a given time, and you gain the information of what ratio of requests could have been served over HTTP/2. During the last 48 hours, web traffic to our own website from HTTP/2-capable browsers looked like this:

This would mean that a little more than a quarter of all browsers accessing our website could have used HTTP/2 during this time frame.

Again, we see a larger number of non-browsers, which don’t fall into any of the above buckets, on our edge. This is due to bots, crawlers, scrapers, and the like. The numbers above represent typical website traffic after it has been sanitized by CloudFlare.

After looking at the ratio of browsers that caniuse.com estimates to support HTTP/2 today, we can see a large discrepancy between our estimated 26.79% and the ratio of between 61.7% and 67.89% that caniuse.com estimates. Unfortunately, caniuse.com is overestimating the ratio of some of the above browsers. In particular, the value for "Chrome 46 for Android" appears to incorrectly include all Chrome for Android versions, even though these versions do not have HTTP/2 support.

Both SPDY and HTTP/2 provide numerous benefits to website owners. Without support for HTTP/2 or SPDY on the browser or server side, the connection can only be established via HTTP/1.x, which usually means higher page load times and a reduced experience.

Replacing SPDY with HTTP/2 today would have meant dropping support for faster web surfing from 80.38% of our end-users to 26.79% of them, which is a difference of 53.59 percentage points.

Instead, by doing both, we ensure that users with browsers only supporting SPDY/3.1 can still get the best web surfing experience on our customers’ sites, while at the same time ensuring that users with newer browser versions that only support HTTP/2 are and will continue to get the best experience possible.

After running our own Website www.cloudflare.com with HTTP/2 and SPDY support for more than 48 hours, we were able to extract some real-life numbers for connections established over HTTP/2 and SPDY versus HTTP/1.x:

These real-life numbers show that we were on the right path with not removing SPDY in favor of HTTP/2.

CC BY 2.0 image by Chris Potter

You can easily check the HTTP/2 support status for a web page yourself. For this, we need to understand first how the protocol negotiation for both HTTP/2 and SPDY works. Browser and web servers use Application-Layer Protocol Negotiation (ALPN) or the slightly older Next Protocol Negotiation (NPN) Transport Layer Security (TLS) extension to negotiate what protocol the server and client "speak".

Using OpenSSL, you can easily validate what versions CloudFlare's Edge servers are able to use:

openssl s_client -servername www.cloudflare.com -connect www.cloudflare.com:443 -nextprotoneg ''
CONNECTED(00000003)
Protocols advertised by server: h2, spdy/3.1, http/1.1

The advertised protocols include h2 for HTTP/2, spdy/3.1 for the current version of SPDY and http/1.1 for HTTP/1.1 as a fallback mechanism.

Similarly, clients will present to the web server the protocols they support.

Want to learn more about how HTTP/2 and SPDY works, the benefits it brings to your website's audience, and how we can help you speed up your website? Check out our HTTP/2 resources at cloudflare.com/http2.