Participating in the Internet democracy occasionally means that ideas and technologies that were once popular or ubiquitous on the net lose their utility as newer technologies emerge. SPDY is one such technology. Several years ago, Google drafted a proprietary and experimental new protocol called SPDY. SPDY offered many performance improvements over the aging HTTP/1.1 standard and these improvements resulted in significantly faster page load times for real-world websites. Stemming from its success, SPDY became the starting point for HTTP/2 and, when the new HTTP standard was finalized, the SPDY experiment came to an end where it gradually fell into disuse.

As a result, we're announcing our intention to deprecate the use of SPDY for connections made to Cloudflare's edge by February 21st, 2018.

Five and a half years ago, when the majority of the web was unencrypted and web developers were resorting to creative tricks to improve performance (such as domain sharding to download resources in parallel) to get around the limitations of the then thirteen-year-old HTTP/1.1 standard, Cloudflare launched support for an exciting new protocol called SPDY.

CC BY-SA 4.0 by Maximilien Brice

SPDY aimed to remove many of the bottlenecks present in HTTP/1.1 by changing the way HTTP requests were sent over the wire. Using header compression, request prioritization, and multiplexing, SPDY was able to provide significant performance gains while remaining compatible with the existing HTTP/1.1 standard. This meant that server operators could place a SPDY layer, such as Cloudflare, in front of their web application and gain the performance benefits of SPDY without modifying any of their existing code. SPDY effectively became a fast tunnel for HTTP traffic.

As the HTTPbis Working Group submitted SPDY for standardization, the protocol underwent some changes (e.g.— Using HPACK for compression), but retained its core performance optimizations and came to be known as HTTP/2 in May 2015.

With the standardization of HTTP/2, Google announced that they would cease supporting SPDY with the public release of Chrome 51 in May 2016. This signaled to other software providers that they too should abandon support for the experimental SPDY protocol in favor of the newly standardized HTTP/2. Mozilla did so with the release of Firefox 51 in January 2017 and NGINX built their HTTP/2 module so that either it or the SPDY module could be used to terminate HTTPS connections, but not both.

Cloudflare announced support for HTTP/2 in December of 2015. It was at this point that we deviated from our peers in the industry. We knew that adoption of this new standard and the migration away from SPDY would take longer than the 1-2 year timeline put forth by Google and others, so we created our own patch for NGINX so that we could support terminating both SPDY and HTTP/2. This allowed Cloudflare customers who had yet to upgrade their clients to continue to receive the performance benefits of SPDY until they were able to support HTTP/2.

When we made this decision, SPDY was used for 53.59% of TLS connections to our edge and HTTP/2 for 26.79%. Had we only adopted the standard NGINX HTTP/2 module, we would've made the internet around 20% slower for more than half of all visitors to sites on Cloudflare— definitely not a performance compromise we were willing to make!

Two years after we began supporting HTTP/2 (and nearly three years after standardization), the majority of web browsers now support HTTP/2 where the notable exceptions are the UC Browser for Android and Opera Mini. This results in SPDY being used for only 3.83% of TLS connections to Cloudflare's edge whereas HTTP/2 accounts for 66.88%. At this point, and for several reasons, now is the time to stop supporting SPDY.

CC0 by JanBaby

Looking closer at the low percentage of clients connecting with SPDY in 2018, 65% of these connections are made by older iOS and macOS apps compiled against HTTP and TLS libraries which only support SPDY and not HTTP/2. This means that these app developers need to publish an update with HTTP/2 support to enable support for this protocol. We worked closely with Apple to assess the impact of deprecating SPDY for these clients and determined that the impact of deprecation is minimal.

We mentioned earlier that we applied our own patch to NGINX in order to be able to continue to support both SPDY and HTTP/2 for TLS connections. What we didn't mention was the engineering cost associated with maintaining this patch. Every time we want to update NGINX, we also need to update and test our patch, which makes each upgrade more difficult. Further, no active development is being done to SPDY so in the event that security issues arise, we would incur the cost of developing our own security patches.

Finally, when we do disable SPDY this February, the less than 4% of traffic that currently uses SPDY will still be able to connect to Cloudflare's edge by gracefully falling back to using HTTP/1.1.

Part of being an innovator is knowing when it is time to move forward and put older innovations in the rear view mirror. By seeing 10% of HTTP requests made on the internet, Cloudflare is in a unique position to analyze overall adoption trends of new technologies, allowing us to make informed decisions on when to launch new features or deprecate legacy ones.

SPDY has been extraordinarily beneficial to clients connecting to Cloudflare over the years, but now that the protocol is largely abandoned and superseded by newer technologies, we recognize that 2018 is time to say goodbye to an aging legacy protocol.

The release of HTTP/2 by CloudFlare had a huge impact on the number of sites supporting and using the protocol. Today, 50% of sites that use HTTP/2 are served via CloudFlare.

CC BY 2.0 image by JD Hancock

When we released HTTP/2 support we decided not to deprecate SPDY immediately because it was still in widespread use and we promised to open source our modifications to NGINX as it was not possible to support both SPDY and HTTP/2 together with the standard release of NGINX.

We've extracted our changes and they are available as a patch here. This patch should build cleanly against NGINX 1.9.7.

The patch means that NGINX can be built with both --with-http_v2_module and --with-http_spdy_module. And it will accept both the spdy and http2 keywords to the listen directive.

To configure both HTTP/2 and SPDY in NGINX you'll need to run:

./configure --with-http_spdy_module --with-http_v2_module --with-http_ssl_module

Note that you need SSL support for both SPDY and HTTP/2.

Then it will be possible to configure an NGINX server to support both HTTP/2 and SPDY on the same port as follows:

server {
        listen       443 ssl spdy http2;
        server_name  www.example.com;

        ssl_certificate      cert.pem;
        ssl_certificate_key  cert.key;

        location / {
            root   html;
            index  index.html index.htm;
        }
}

Our patch uses ALPN and NPN to advertise the availability of the two protocols. To test that the two protocols are being advertised you can use the OpenSSL client as follows (sending an empty ALPN/NPN extension in the ClientHello causes the server to return a list of available protocols).

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

Many other tools for testing and debugging HTTP/2 connections can be found here.

The patch puts HTTP/2 before SPDY/3.1 and will prefer HTTP/2 over SPDY/3.1. If a web browser offers both, HTTP/2 will be preferred and used for the connection.

We continue to support SPDY and HTTP/2 across all CloudFlare sites and will keep an eye on the percentage of connections that use SPDY before making a decision on its eventual deprecation.

CC BY 2.0 image by Roger Price

HTTP/2’s main benefit is multiplexing, which allows multiple HTTP requests to share a single TCP connection. This has a huge impact on performance compared to HTTP/1.1, but it’s nothing new—SPDY has been multiplexing TCP connections since at least 2012.

Some of the most important aspects of HTTP/2 have yet to be implemented by major web servers or edge networks. The real promise of HTTP/2 comes from brand new features like Header Compression and Server Push. Since February, we’ve been quietly testing and deploying HTTP/2 Header Compression, which resulted in an average 30% reduction in header size for all of our clients using HTTP/2. That's awesome. However, the real opportunity for a quantum leap in web performance comes from Server Push.

Today, we’re happy to announce HTTP/2 Server Push support for all of our customers. Server Push enables websites and APIs to speculatively deliver content to the web browser before the browser sends a request for it. This behavior is opportunistic, since in some cases, the content might already be in the client’s cache or not required at all.

It’s been touted as one of the major features of HTTP/2, and by enabling it, we cover the entire set of HTTP/2 features for all of our users. You can see it in action on our live Server Push demo.

Server Push provides significant performance gains if used judiciously. In its most basic form, Server Push allows the server to “bundle” assets that the client didn’t ask for. It works by sending PUSH_PROMISE—a declaration of the intention to send the assets, followed by the actual assets.

Upon the receipt of a PUSH_PROMISE, the client may respond with a RST_STREAM message, indicating this asset is not needed. Even in this case, due to the asynchronous nature of HTTP/2, the client may receive the asset before the server gets the RST_STREAM message.

The PUSH_PROMISE looks a lot like an HTTP/2 GET request, and the client attempts to match received push promises before sending outgoing requests.

All of our customers using HTTP/2 now have Server Push enabled, but unfortunately, Server Push isn’t one of those features that just works—you’ll need to do a little bit of work to truly leverage the benefits of Server Push.

Our implementation follows the guidelines laid out in the W3C’s draft standard on the use of a preload keyword in Link headers[1], and we will continue to track that standard as it evolves.

So, if you want to push assets for a given request, you simply add a specially formatted Link header to the response:

Link: </asset/to/push.js>; rel=preload; as=script

Those links can be manually added, but they’re already created automatically by many publishing tools or via plugins for popular content management systems (CMS) such as WordPress.

Only relative links will be pushed by our edge servers, which means Server Push won’t work with third-party resources.

The Link header was originally designed to let browsers know that they should preload an asset. If you still need this behavior for legacy reasons, you can append the nopush directive to the header, like so:

Link: </dont/want/to/push/this.css>; rel=preload; as=style; nopush

Server Push has the potential for tremendous performance gains. However, it’s not able to speed up every website, and it can even degrade the performance somewhat if you get overzealous. Generally, the downside of pushing assets that will end up unused is only the wasted bandwidth, while the upside is a speedup equivalent to one round trip from the client to our edge network.

Both the downside and the upside are mostly evident on slow, lossy connections, such as mobile networks. We suggest you profile the behavior of your individual website/API with and without Server Push to estimate the benefits. In our testing, we saw around a 45% performance gain when using Server Push on a mobile network.

Also note that because Server Push operates over a given HTTP/2 connection, it can only be used to push resources from your domain. If your website is bottlenecked on third-party assets, Server Push is unlikely to help you.

Some of the best use cases for HTTP/2 Server Push are:

• Uncacheable content - Content that is not cached on the edge benefits from Server Push, since it will be requested from the origin earlier in the connection.

• All assets on a requested page - By pushing all the CSS, JS, and image assets on a given page, it’s possible to transfer the entire page in a single round trip. This is only useful when no third party assets are blocking the page rendering. If the majority of the assets are cached on the client’s browser, this behavior can be wasteful.

• The most likely next page - If there is a link on the loaded page that is most likely clicked next (for example the most recent post in a blog) you could push both the HTML and all of that pages assets. When the user clicks the link, it will render almost instantly.

There are currently several tools and browsers that support Server Push. However, to visualize the performance benefits of the feature, the current Canary version of Google Chrome is the best. Here is an example of a webpage with five images loading with and without Server Push, as depicted in the timeline:

After the main page is loaded (and some processing time) the browser makes a request for the five images. After another round trip, those images are delivered and loaded.

HTTP/2 + Server Push:

With Server Push enabled, we can see that the images are delivered while the page is being processed, thus no additional round trip is required. As soon as the images are needed, Chrome matches them with existing Push Promises and immediately uses them.

In Canary Chrome, you can also see that the pushed assets are identified in the Initiator column as Push/Other.

Pushed assets will not get a timeline and are identified by a solid grey circle (unlike cached content that is identified by a non-solid circle, and a “cached” indication in the “Transferred tab”).

Plain HTTP/2:

HTTP/2 + Server Push:

Pushed assets won’t have the yellow bar in the timeline (TTFB), and under the Protocol tab, the protocol will appear as HTTPS and not HTTP/2.

Plain HTTP/2:

HTTP/2 + Server Push:

The Safari browser does not support Server Push at the moment, but support is expected in the near future.

In the future, we plan to develop new tools to help our users to make more educated decisions in regards to Server Push. Over time, CloudFlare will even be able to predict the best assets to push automatically.

This feature is very new, and CloudFlare is the first major provider to deploy it at scale. We look forward to hearing from customers who make use of Server Push, now that we’ve made it available for experimentation.

We believe that Server Push is the most important upgrade to the web since SPDY. It has enormous potential to speed up the Internet since, for the first time, it gives website owners the power to send information to a web browser before the browser even asks for it.We’ll also be monitoring the still ongoing process of HTTP/2 development, especially efforts to make Server Push more aware of the client’s cache (thus reducing the number of redundant pushes).

1. We are currently only looking at link elements in HTTP headers and not in page HTML. ↩︎

We're big fans of HTTP/2 at Cloudflare. Our customers make up the majority of HTTP/2 enabled domains today. HTTP/2 is a key part of the modern web, and its growth and adoption is changing how websites and applications are built.

On Thursday April 28, 2016, our friends at CatchPoint are hosting a live AMA (Ask Me Anything) with experts from CloudFlare, Akamai, and Google answering questions in real time about the protocol's features, adoption, and future.

When: Thursday April 28, 2016 from 2pm-3pm Eastern Time (1600-1700 UTC)

How: Ask questions ahead of time (and vote on questions). Join in real-time on Thursday.

Who: Cloudflare's own Suzanne Aldrich will join Ilya Grigorik from Google, Tim Kadlec from Akamai, and Andrew Smirnov from Catchpoint.

Need the basics on HTTP/2 ahead of time? Visit the Cloudflare HTTP/2 website.

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!

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.

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.

Life’s a little bit easier in HTTP/2. It gives the typical website a 30% performance gain without a complicated build and deploy process. In this article, we’ll discuss the new best practices for website optimization in HTTP/2.

Most of the website optimization techniques in HTTP/1.1 revolved around minimizing the number of HTTP requests to an origin server. A browser can only open a limited number of simultaneous TCP connections to an origin, and downloading assets over each of those connections is a serial process: the response for one asset has to be returned before the next one can be sent. This is called head-of-line blocking.

As a result, web developers began squeezing as many assets as they could into a single connection and finding other ways to trick browsers into avoiding head-of-line blocking. In HTTP/2, some of these practices can actually hurt page load times.

Optimizing for HTTP/2 requires a different mindset. Instead of worrying about reducing HTTP requests, web developers should focus on tuning their website’s caching behavior. The general rule is to ship small, granular resources so they can be cached independently and transferred in parallel.

This shift occurs because of the multiplexing and header compression features of HTTP/2. Multiplexing lets multiple requests share a single TCP connection, allowing several assets to download in parallel without the unnecessary overhead of establishing multiple connections. This eliminates the head-of-line blocking issue of HTTP/1.1. Header compression further reduces the penalty of multiple HTTP requests, since the overhead for each request is smaller than the uncompressed HTTP/1.1 equivalent.

There are two other features of HTTP/2 that also change how you approach web optimization: stream prioritization and server push. The former lets browsers specify what order they want to receive resources, and the latter lets the server send extra resources that the browser doesn’t yet know it needs. To make the most of these new features, web developers need to unlearn some of the HTTP/1.1 best practices that have become second nature to them.

In HTTP/1.1, web developers often combined all of the CSS for their entire website into a single file. Similarly, JavaScript was also condensed into a single file, and images were combined into a spritesheet. Having a single file for your CSS, JavaScript, and images vastly reduced the amount of HTTP requests, making it a significant performance gain for HTTP/1.1.

However, concatenating files is no longer a best practice in HTTP/2. While concatenation can still improve compression ratios, it forces expensive cache invalidations. Even if only a single line of CSS is changed, browsers are forced to reload all of your CSS declarations.

In addition, not every page in your website uses all of the declarations or functions in your concatenated CSS or JavaScript files. After it’s been cached, this isn’t a big deal, but it means that unnecessary bytes are being transferred, processed, and executed in order to render the first page a user visits. While the overhead of a request in HTTP/1.1 made this a worthwhile tradeoff, it can actually slow down time-to-first-paint in HTTP/2.

Instead of concatenating files, web developers should focus more on optimizing caching policy. By isolating files that change frequently from ones that rarely change, it’s possible to serve as much content as possible from your CDN or the user’s browser cache.

Inlining assets is a special case of file concatenation. It’s the practice of embedding CSS stylesheets, external JavaScript files, and images directly into an HTML page. For example, if you have web page that looks like this:

<html>
  <head>
	<link rel="stylesheet" href="/style.css">
  </head>
  <body>
	<img src="logo.png">
	<script src="scripts.min.js"></script>
  </body>
</html>

You could run it through an inlining tool to get something like this:

<html>
  <head>
	<style>

	  body {
		font-size: 18px;

		color: #999;
	  }
	</style>
  </head>
  <body>
	<img src="data:image/png;base64,Rw0KGgoAAAANSUhEUgAAAEAABA...">
	<script>console.log('Hello, World!');</script>
  </body>
</html>

In extreme cases, this can actually reduce the number of HTTP requests for a given web page to one. But, like file concatenation, you shouldn’t inline files you’re trying to optimize for HTTP/2.

Inlining means that browsers can’t cache individual assets. If you have CSS declarations that apply to your entire website embedded into every single HTML file, those declarations get sent back from the server every time. This results in redundant bytes being sent over the wire for every page that a user visits.

Inlining also has the unfortunate side effect of breaking stream prioritization. Because your CSS, JavaScript, and images are now embedded in your HTML, you’re effectively raising their priority to the same level as HTML content. This means that browsers can’t request assets in their preferred order, potentially increasing time-to-first-paint.

Instead of inlining assets, web developers should leverage HTTP/2’s server push functionality. Server push lets your web server say stuff like, "Hold on, you’re going to need this image and this CSS file to render that HTML page you just requested." Conceptually, this is the same as inlining an asset, but it doesn’t break stream prioritization, and it allows you to leverage a CDN and the user’s local browser cache, too.

Domain sharding is a common technique for tricking browsers into opening more TCP connections than they’re supposed to. Browsers limit the number of connections to a single origin server, but by splitting your website’s assets across multiple domains, you can get it to open an extra set of TCP connections. This helps avoid head-of-line blocking, but it comes with significant tradeoffs.

Domain sharding should be avoided in HTTP/2. Each shard results in an unnecessary DNS query, TCP connection, and TLS handshake (assuming the servers use different TLS certificates). In HTTP/1.1, that overhead was compensated for by allowing several assets to download in parallel. But, this is no longer the case in HTTP/2: multiplexing allows multiple assets to download in parallel over a single connection. And, similar to asset inlining, domain sharding breaks HTTP/2 stream prioritization because browsers can’t prioritize streams across multiple domains.

If you’re currently sharding but want to leverage HTTP/2, you don’t necessarily need to go about refactoring your entire codebase. As discussed in our blog post on mixing domain sharding and SPDY, browsers recognize when multiple origin servers use the same TLS certificate. When they do, the browser will reuse the same SPDY or HTTP/2 connection for both servers. This still results in multiple DNS queries, but it’s a decent compromise solution if you want the best performance under both HTTP/1.1 and HTTP/2.

Fortunately, not everything about web optimization changes in HTTP/2. There’s still several HTTP/1.1 best practices that carry over to HTTP/2. The rest of this article discusses techniques that you should be leveraging regardless of whether you’re optimizing for HTTP/1.1 or HTTP/2.

Before a browser can request your website’s resources, it needs to find the IP address of your server using the domain name system (DNS). Until the DNS responds, the user is left staring at a blank screen. HTTP/2 is designed to optimize how web browsers communicate with web servers—it doesn’t affect the performance of the domain name system.

Since DNS queries can be expensive, especially if you have to start your query at the root nameservers, it’s still prudent to minimize the number of DNS lookups that your website uses. DNS prefetching via a <link rel='dns-prefetch' href='...' /> line in your document’s <head> can help, but it’s not a one-size-fits all solution.

It takes around 130ms for light to travel around the circumference of the earth. That’s latency that you can’t get rid of—it’s just physics. The imperfect nature of fiber optic cables and wireless connections, as well as the topology of the global Internet means that it actually takes closer to 300-400ms to transmit a network packet from your computer to a server that’s halfway around the world. User’s can perceive latency as small as 100ms, and the only way to get around the laws of physics is to put your web assets geographically closer to your visitors via a CDN.

You can take content delivery networks one step further by caching assets in the user’s local browser cache. This avoids any kind of data transfer over the network, aside from a 304 Not Modified response.

Even though HTTP/2 requests are multiplexed, it takes time to transmit data over the wire. Accordingly, it’s still beneficial to reduce the amount of data you need to transfer. On the request end, this means minimizing the size of cookies, URL and query strings, and referrer URLs as much as possible.

Of course, this holds true in the opposite direction. As a web developer, you want to make your server’s response as small as possible by minifying HTML, CSS, and JavaScript Files, optimizing images for the web, and compressing resources with gzip.

HTTP 301 and 302 redirects are sometimes a fact of life when migrating to a new platform or re-designing your website, but they should be eliminated wherever possible. Redirects result in an extra round trip from the browser to the server, and this adds unnecessary latency. You should be particularly wary of redirect chains where it takes more than a single redirect to get to the destination URL.

Server-side redirects like 301 and 302 responses aren’t ideal, but they aren’t the worst thing in the world, either. They can still be cached locally, so a browser can recognize the URL as a redirect and avoid an unnecessary round trip. Meta refreshes (e.g., <meta http-equiv="refresh"...), on the other hand, are much more costly because they can’t be cached, and they can have performance issues in certain browsers.

And that’s HTTP/2 web optimization in a nutshell. Avoiding file concatenation, asset inlining, and domain sharding not only speeds up your website, but also makes for a much simpler build and deploy process.

There are, however, a few caveats to this discussion. Most servers, content delivery networks (including CloudFlare), and existing applications don’t support server push. Servers and CDNs will catch up soon enough, but for your application to benefit from server push, you’re going to have to make some changes to your codebase.

Also keep in mind is that HTTP/2 performance gains depend on the type of content you serve. For example, websites that rely on more external assets will see larger performance gains from HTTP/2 multiplexing than ones that have fewer HTTP requests.

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.

CC BY 2.0 by JD Hancock

Last Monday we announced our SSL for Free plan users called Universal SSL. Universal SSL means that any site running on CloudFlare gets a free SSL certificate, and is automatically secured over HTTPS.

Using SSL for a web site helps make the site more secure, but there's another benefit: it can also make the site faster. That's because the SPDY protocol, created by Google to speed up the web, actually requires SSL and only web sites that support HTTPS can use SPDY.

CloudFlare has long supported SPDY, and kept up to date with improvements in the protocol. We currently support the most recent version of SPDY: 3.1.

CloudFlare's mission to bring the tools of the Internet giants to everyone is two fold: security and performance. As part of the Universal SSL launch, we also rolled out SPDY for everyone. Many of the web's largest sites use SPDY; now all sites that use CloudFlare are in the same league.

If your site is on CloudFlare, and you use a modern browser that supports SPDY, you'll find that the HTTPS version of your site is now served over SPDY. SPDY allows the browser to query for multiple objects in one request, and for the objects to be sent down the wire as they are ready to prevent hold-ups—that can be a big performance win.

Our goal is a faster, safer, more secure Internet. Universal SSL and SPDY for everyone are two big steps in that direction.

The team at CloudFlare is excited to announce the release of Universal SSL™. Beginning today, we will support SSL connections to every CloudFlare customer, including the 2 million sites that have signed up for the free version of our service.

This morning we began rolling out the Universal SSL across all our current customers. We expect this process to be complete for all current customers before the end of the day. Yesterday, there were about 2 million sites active on the Internet that supported encrypted connections. By the end of the day today, we'll have doubled that.

For new customers who sign up for CloudFlare's free plan, after we get through provisioning existing customers, it will take up to 24 hours to activate Universal SSL. As always, SSL for paid plans will be provisioned instantly upon signup.

For all customers, we will now automatically provision a SSL certificate on CloudFlare's network that will accept HTTPS connections for a customer's domain and subdomains. Those certificates include an entry for the root domain (e.g., example.com) as well as a wildcard entry for all first-level subdomains (e.g., www.example.com, blog.example.com, etc.).

For a site that did not have SSL before, we will default to our Flexible SSL mode, which means traffic from browsers to CloudFlare will be encrypted, but traffic from CloudFlare to a site's origin server will not. We strongly recommend site owners install a certificate on their web servers so we can encrypt traffic to the origin. Later today we'll be publishing a blog with instructions on how to do that at no cost. Once you've installed a certificate on your web server, you can enable the Full or Strict SSL modes which encrypt origin traffic and provide a higher level of security.

CloudFlare operates at significant scale and we're growing very quickly. To make Universal SSL work at our scale we needed to ensure it wouldn't overwhelm our resources. We had two primary concerns:

1. CPU load

2. IPv4 exhaustion

Terminating HTTPS connections requires more CPU load than terminating HTTP. The additional load varies depending on the particular cipher suite used. For instance, the cutting-edge cipher suite ECDSA imposes significantly less load on our systems as compared with a more traditional cipher suite based on RSA. As it happens, ECDSA also provides a number of performance and security benefits over older cipher suites. We've written in the past about the benefits of ECDSA including the fact that it supports Perfect Forward Secrecy and faster SSL termination (and therefore faster page load times).

IPv4 termination is the other challenge of Universal SSL. The original implementation of SSL encrypted the host header. That meant you were limited to one certificate per IP address. Given that CloudFlare controls a finite number of IP addresses, it would be impossible for us to dedicate a unique IP for every one of our millions of customers.

These challenges required that, for free customers, we limit Universal SSL support to modern browsers. Modern browsers include support for ECDSA, where many legacy browsers do not. Modern browsers also support an extension to the SSL protocol called Server Name Indication (SNI). SNI sends the web site name (the equivalent of the host header) unencrypted, which allows us to return different certificates on an IP address depending on what customer's site is requested. This allows us to serve multiple customers' sites from the same IP.

Generally, if you're running a browser that is less than 6 years old, your browser is modern and Universal SSL on CloudFlare's free plans will work. The two biggest problem children legacy browsers are:

1. Internet Explorer on Windows XP (or older)

2. Android pre-Ice Cream Sandwich

We've been studying browser traffic for the last year in order to determine what percentage of requests come from browsers that qualify as modern. The answer varies widely depending on the region. Globally, more than 80% of requests come from modern browsers, and that percentage is growing quickly.

A recent test showed the percentage of requests in countries around the world that come from modern browsers. Iran is the worst region in the world with only 52.01% of requests coming from modern browsers. Antarctica is the best region in the world with 99.44% of requests coming from modern browsers. You can mouse over different regions to see the percentage of requests that come from modern browsers.

While Universal SSL on our free service requires a modern browser, CloudFlare's paid plans have always and will always support both modern and legacy browsers. In the coming months, because of the benefits of ECDSA certificates, we plan on offering paid users the option to return ECDSA certificates if we detect a modern browser, while reverting to RSA certificate if we detect a legacy browser.

If SSL is a must-have for you, we still recommend using a paid CloudFlare plan (which start as inexpensively as $20/month). If SSL is a nice-to-have, support on the free plan is likely sufficient to serve the vast majority visitors from most regions around the world. Note finally that Universal SSL does not disable your ability to accept unencrypted traffic. HTTP will continue to work as it always has before. You can, however, now use CloudFlare's Page Rules to force all traffic to HTTPS even if you're a free customer. (PS - Going forward, also we plan to support the ability to add HSTS headers.)

One additional benefit of Universal SSL is it allows us to broadly support of the SPDY protocol which requires an encrypted connection. SPDY improves web performance in a number of ways we've written about before. All CloudFlare customers will, by the end of the day today, also have SPDY enabled by default — massively increasing the size of the SPDY universe.

We also have plans to expand the universe of supported browsers slightly by taking advantage of connections that arrive over IPv6 for browsers that don't support SNI. About 16% of unique IP addresses that connect to CloudFlare do so via IPv6 (note: that calculation takes only the first 8 bytes as unique in any IPv6 address connecting to our network). Since IPv6 addresses are virtually infinite, we don't have the same limitations as we do with IPv4 and can therefore return a unique certificate for every IPv6 address.

Our bigger hope, however, is that Universal SSL will be yet another reason, along with Google and Firefox deprecating SHA-1-signed certs and Microsoft ceasing support for Windows XP, to encourage people to upgrade to a modern browser running on a modern OS. Sometimes progress requires sacrificing some backward compatibility. The good news here is that none of CloudFlare's current free customers supported any version of SSL previously, so the encrypted web tomorrow is only better and no worse.

To that end, CloudFlare customers can help encourage the remaining users of old browsers to upgrade using a CloudFlare App. The A Better Browser app can be installed with one click on any web site that uses CloudFlare. It automatically detects if the visitor is using an old browser and adds a banner at the top of the page suggesting that they upgrade.

Last Wednesday we had a CloudFlare Board meeting. We went over our plans for launching Universal SSL and how doing so may hurt our revenue given that SSL is one of the reasons people upgrade to a paid plan. But everyone on CloudFlare's Board was unanimous: even if it does hurt revenue in the short term, it's the right thing to do.

Brad Burnham, who is the partner at Union Square Ventures who led our last round of financing, reminded me during the meeting of the Joi Ito essay about how the Internet is a belief system. Inherent to Joi's point is that small groups of people, working together, can create great things. That, fundamentally, is the Internet.

The team behind Netscape first introduced SSL back in February 1995, originally intended to facilitate ecommerce online. As the Internet grew in importance, governments, ISPs, and hackers began to intercept, throttle, and censor traffic as it flowed across the network to serve their ends. In response, SSL's importance expanded beyond ecommerce to help ensure a free and open web. As Google and the IETF work on the next generation Internet protocols like SPDY and HTTP/2, it's no wonder encryption is at their heart. And so, in order for CloudFlare to fulfill its mission of helping build a better Internet, we knew one of the most important things we could do was enable Universal SSL for all our customers — even if they don't pay us.

Having cutting-edge encryption may not seem important to a small blog, but it is critical to advancing the encrypted-by-default future of the Internet. Every byte, however seemingly mundane, that flows encrypted across the Internet makes it more difficult for those who wish to intercept, throttle, or censor the web. In other words, ensuring your personal blog is available over HTTPS makes it more likely that a human rights organization or social media service or independent journalist will be accessible around the world. Together we can do great things.

The Internet is a belief system. At CloudFlare, we're proud today that we're playing a part in helping advance that belief system. And, having proven that Universal SSL is possible at our scale, we hope many other organizations will follow in turning SSL on for all their customers and at no additional cost.

If you are already a CloudFlare customer, we're rolling out Universal SSL throughout the day today. We expect it will be fully provisioned for most current customers within the next 24 hours. If you're a new customer, note that it will take up to 24 hours from when you sign up to provision SSL for our free service (and, again, if you're in a hurry, it's still instant for all paid plans).

One final note: if you signed up for CloudFlare through one of our hosting partners, it will be a bit longer before we can enable Universal SSL. This is due to a technical limitation on how we need to provision the Universal SSL certificates. We think we can solve the technical limitation and expect that we'll be able to support Universal SSL through partners before the end of the year. Until then, hang tight.

This is a day the CloudFlare team has been looking forward to for the last three years. It took a ton of work. We couldn't have done it without the help of a number of great people both on our own team and at other organizations that provided assistance. Special thanks to Globalsign, Comodo, Ryan Hurst, Christopher Soghoian (ACLU), Peter Eckersley (EFF), and Adam Langley (Google).

Over the next few days, we'll be posting a series of articles about the details behind how we made Universal SSL a reality. There were a number of hard technical, business, and legal challenges we had to overcome to make today possible. The people that worked on solving them are excited to share their stories. Stay tuned.

Update: It's taking us a bit longer to provision Universal SSL for all our customers than we'd originally anticipated. We're now expecting the provisioning process to be complete on Thursday, October 2 @ 0700 UTC. We've published a new blog post on how you can track our progress and what errors you may see if you try and visit your site over HTTPS before the provisioning process is complete.

The document contains a simple diagram proposing that "browsers" on heterogenous machine types would be able to access Hypertext Servers to view information.

In one of the great understatements of computing history, Tim Berners-Lee, the author of the proposal, wrote a parenthetical comment that allowing heterogenous machine types to access these proposed Hypertext Servers would be "a boon for the world in general".

The most visible part of the explosion of the World-Wide Web is that we are all using it every day. But we don't often stop to think about the technical changes that underlie the web browsers that we use. Part of CloudFlare's work is to stay on top of the web as it changes so that everyone with a web server has the latest technology.

Here's a brief timeline of significant changes in web technology.

March 12, 1989: Tim Berners-Lee outlines the web in "Information Management: A Proposal"

Christmas Day, 1990: Berners-Lee releases the first version of his WorldWideWeb web browser.

1991: the first HTTP standard HTTP/0.9 is written up. It reflects that state of HTTP as implemented by early web browsers.

March 9, 1992: The ViolaWWW browser is released. It remains popular until Mosaic is released.

July 1992: Port 80 is assigned for the HTTP protocol in RFC 1340.

November 3, 1992: Internal CERN document entitled HTML Tags is first HTML specification of any kind.

January 23, 1993: The Mosaic web browser is released and becomes very popular.

February 25, 1993: Marc Andreessen proposes that the web should have an <img> tag so that images could be displayed in a browser along with text.

1994: The first mobile web browser, PocketWeb for the Apple Newton, is released.

February 1995: Netscape introduced SSL for secure HTTP connections.

September 1995: Netscape introduces JavaScript.

November 24, 1995: HTML 2.0 is described in RFC 1866.

1996: Macromedia introduces Flash. It becomes Adobe Flash in 2005.

May 1996: The specification for HTTP/1.0 is released as RFC 1945.

November 1996: SSL 3.0 is released (it is described in RFC 6101). The W3C issues a Working Draft describing XML.

December 17, 1996: CSS Level 1 is published as a recommendation by the W3C.

January 1997: The specification for HTTP/1.1 is released as RFC 2068. The W3C releases a draft specification for HTML 3.2.

December 18, 1997: The specification for HTML 4.0 is released.

1998: Microsoft introduces XMLHTTP as part of work being done on Outlook Web Access. XMLHTTP later became XMLHTTPRequest and helped kick off Web 2.0.

May 12, 1998: W3C publishes a specification for CSS Level 2.

December 1998: IPv6 is written up in RFC 2460. The specification of HTML 4.01 is released.

January 1999: TLS 1.0 is described in RFC 2246. It is destined to replace SSL.

December 2000: Mozilla introduces support for XMLHTTPRequest in Gecko 0.6.

February 2004: Apple adds support for XMLHTTPRequest to Safari 1.2.

February 18, 2005: The term AJAX is used to describe dynamic web sites using XMLHTTPRequest and JavaScript.

April 2006: TLS 1.1 is described in RFC 4346. The W3C releases a Working Draft describing XMLHTTPRequest.

October 2006: Microsoft Internet Explorer 7 supports XMLHTTPRequest.

January 2008: First draft version of HTML 5 is released.

August 2008: TLS 1.2 is described in RFC 5246.

April 12, 2011: CSS Level 2.1 becomes a W3C Proposed Recommendation.

November 2011: SPDY is introduced by Google.

December 2011: RFC 6455 describes WebSockets.

February 2012: SPDY Version 3 is described an Internet Draft.

November 2013: SPDY Version 3.1 is specified. Work on SPDY continues as part of HTTP/2.0.

And so the web continues to evolve. New specifications and new protocols are tested and defined. HTML5 is an ongoing effort, as is CSS Level 3. Google recently began experimenting with a new web protocol called QUIC.

CloudFlare helps customers stay on top of the ever changing web with features like automatic IPv6, support for SPDY/3.1, and complete support for TLS.

25 years on the web is still growing, evolving and changing. Here's to 25 more years!

PS If reading that list of changes wasn't enough nostalgia for you... visit the web page that got it all started.

When Tim Berners-Lee wrote the original proposal he sent it to his boss. His boss wrote on the top of it Vague but exciting.... It did turn out to be the latter!

Back in June 2012 CloudFlare started a beta rollout of Google's then new SPDY protocol and we took a detailed look at how SPDY makes web sites faster.

Since then we've watched carefully as SPDY has evolved through different versions and have been keeping an eye on a new Google-driven protocol called QUIC. In August 2012 we rolled out SPDY for all our customers by making it a simple (one click) configuration option.

As SPDY has progressed we've become more and more confident in the protocol and made it automatic for all our Pro, Business and Enterprise customers. No click needed. (Since SPDY runs over SSL/TLS to use it a web site must have an SSL certificate).

Last week we rolled out the most recent version of SPDY, 3.1, for all customers. SPDY/3.1 is supported by Google Chrome and Mozilla Firefox. As older versions of SPDY (particularly SPDY/2) are being deprecated it's vital for us to keep up to date.

To see whether a site is served over SPDY it's possible to use the CloudFlare Claire extension for Google Chrome. Here it's showing that the popular Hacker News site is served over SPDY.

To discover the exact version used you can dive into Chrome's chrome://net-internals where the version is shown for each connection. Here connections to Google, CloudFlare and Hacker News are all using the latest version.

A key advantage of SPDY is its ability to multiplex many HTTP request streams onto a single TCP connection. In the past, various hacks (such as domain sharding) have been used to get around the fact that only sequential, synchronous requests were possible with HTTP over TCP. SPDY changed all that.

SPDY/3 introduced flow control so that SPDY clients (and servers) could control the amount of data they receive on a SPDY connection. SPDY/3.1 extended flow control to individual SPDY streams (each SPDY connection handles multiple simultaneous streams of data). Flow control is important because different clients (think of the differences in available memory in laptops, desktops and mobile phones) will have varying limitations on how much data they can receive at any one time.

Part of the service CloudFlare provides is being on top of the latest advances in Internet and web technologies. We've stayed on top of SPDY and will continue to roll out updates as the protocol evolves (and we'll support HTTP/2 just as soon as it is practical).

The most recent web protocol we've started experimenting with is QUIC. QUIC is radically different from HTTP or SPDY because it uses UDP as its underlying transport. Currently, we have an internal QUIC server running serving a static version of the CloudFlare home page. As our experiments with QUIC progress we'll make an alpha site available for people who, like us, are interested in experimenting with bleeding edge technologies.

If you're interested in playing with QUIC today you'll need to build the test QUIC server and client that are part of the Chromium project, get Google Chrome Canary and enable QUIC in chrome://flags. You'll probably also want the latest Wireshark (the development release) which is capable of decoding QUIC frames.

And once QUIC makes the move from experimental to beta we'll be sure to make it available for our customers.

It’s common knowledge that domain sharding, where the resources in a web page are shared across different domains (or subdomains), is a good thing. It’s a good thing because browsers limit the number of connections per domain: splitting a web page across domains means more connections and hence faster page downloads. Overall domain sharding results in a better end-user experience, and can be a useful way of sharing load across web servers.

But with the adoption of Google’s SPDY protocol the domain sharding situation is totally different. In fact, domain sharding can hurt performance when SPDY is in use and isn’t recommended. To understand why, here’s the popular 4chan.org web site downloaded without SPDY but using SSL (it’s possible to do this comparison without SSL, but less interesting because the timings are very different).

You can see that there are three domains involved: www.4chan.org (from which the initial HTML is downloaded), s.4cdn.org and t.4cdn.org. 4chan is using two domains to shard resources like JavaScript, CSS and images. After the initial HTML is downloaded on line 1, the browser (I used IE 10 here) looks up the DNS entry for s.4cdn.org and t.4cdn.org and opens three connections to each (lines 2 to 7).

In the diagram above the orange represents the TCP connection, and the purple the SSL negotiation. After using those 6 connections to download a resource, the same connections are reused (classic HTTP/1.1 Keep-Alive behaviour) to get further resources. Finally, line 16, there’s a separate connection to send Google Analytics information.

Now take a look at the same site downloaded using SPDY/2 via Google Chrome.

Line 1 shows the same sort of connection, SSL negotiation and download of the page (here it took 591ms to complete vs. 549 ms above). But then the behaviour is totally different. Line 2 shows a single TCP connection and single SSL negotiation to s.4cdn.org. That connection is then used to download all the resources for s.4cdn.org and t.4cdn.org in parallel. Finally, there’s the same, separate Google Analytics connection. What you’re seeing there is SPDY in action.

The SPDY version was slightly faster: the page was visually complete at 1.1s; with SSL without SPDY it was 1.3s (although you’d have to account for differences in paint time between IE 10 and Chrome to really understand those values). There are two important things happening in the SPDY version:

Firstly, Chrome has noticed that s.4cdn.org and t.4cdn.org are the same site (they have the same IP addresses and the certificate for s.4cdn.org is valid for t.4cdn.org as well: it’s a wildcard certificate for 4cdn.org) and so it doesn’t bother with separate SSL connection: one will do. It then requests resources from each of those domains across the same SPDY connection. To do that it simply specifies the correct Host in the SPDY request. These can be see in the chrome://net-internals view. Here are two requests on the same SPDY connection for different Hosts.

t=1386958552557 [st= 1] SPDY_SESSION_SYN_STREAM --> fin = true --> accept: */* accept-encoding: gzip,deflate,sdch accept-language: en-US,en;q=0.8,fr;q=0.6 cache-control: no-cache host: s.4cdn.org method: GET pragma: no-cache referer: https://www.4chan.org/ scheme: https url: /js/fp-combined-compiled.7.js user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 version: HTTP/1.1 --> stream_id = 5 --> unidirectional = false t=1386958552577 [st= 21] SPDY_SESSION_SYN_STREAM --> fin = true --> accept: image/webp,*/*;q=0.8 accept-encoding: gzip,deflate,sdch accept-language: en-US,en;q=0.8,fr;q=0.6 cache-control: no-cache host: t.4cdn.org method: GET pragma: no-cache referer: https://www.4chan.org/ scheme: https url: /cgl/thumb/1386957763148s.jpg user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 version: HTTP/1.1 --> stream_id = 7 --> unidirectional = false

So, Chrome has detected that these domains are actually the same machine and made a single connection. That’s great, and doesn’t have a performance impact, but the actual decision to shard at all has had an impact.

Secondly, notice how in the SPDY case there are two TLS negotiations (one for www.4chan.org and one for s.4cdn.org). The site could have loaded much faster if all the resources had been on www.4chan.org (or on domains that shared a certificate; for this reason wildcard certificates work well with SPDY connections because the browser can use a single shared connection) because the entire download could have been done in a SPDY connection. Because 4chan uses a special domain (on a different IP with a different certificate) for resources it’s necessary to set up a new connection. In the example above, all the resources have to wait for a DNS lookup (27 ms), TCP connection (29 ms) and SSL negotiation (71 ms) before the SPDY connection can start requesting them. That’s a total of 127 ms. The page was visually complete in 1100 ms; if a single domain had been used then SPDY would have saved another 127 ms (almost 12% of the time).

So, for SPDY it’s actually better to not shard; for non-SPDY domain sharding remains a useful technique. (If you are interested in the actual test data the IE 10/SSL test is http://www.webpagetest.org/result/131213_FK_QC1/ and the Chrome/SPDY test is http://www.webpagetest.org/result/131213_NE_QCQ/).

The question then becomes, can you have the best of both worlds? With a little DNS trickery it’s possible to set up a site that works well whether SPDY is available or not. Since I don’t have access to 4chan to do live experiments, I copied the www.4chan.org home page and all the included resources to my own web server and set up three domains: r.jgc.org (the root domain), s.jgc.org (equivalent to s.4cdn.org) and t.jgc.org (equivalent to t.4cdn.org). I then manually edited the HTML and CSS so that all the linked resources pointed to either s.jgc.org and t.jgc.org in the same manner as the original 4chan site. But, critically, I used a single certificate for all three domains. Here’s the site being loaded using IE 10 over SSL.

And here’s the site loaded using Chrome with SPDY.

As you can see, the domain sharding worked in IE 10. There are multiple connections to the s.jgc.org and t.jgc.org domains downloading resources in parallel. And the same configuration worked for Chrome with SPDY because it detected that these shared a certificate and used a single SPDY connection for everything (including the initial page download).

In Chrome there was only a single TCP connection and a single DNS lookup needed despite the presence of three domains. The IE 10/SSL version was visually complete in 1100 ms and used 9 TCP/SSL connections (plus one extra for Google Analytics). The Chrome/SPDY version was visually complete 200ms (at 900ms) and used… a single SPDY connection (plus an extra connection for Google Analytics). If you’re interested the IE 10/SSL test is here and the Chrome/SPDY test is here.

For the best performance for the older browsers and the latest, shiny SPDY browsers domain sharding should still be used but using a certificate that covers the domains used means that only a single SPDY connection will be needed.

CloudFlare Makes This EasyCloudFlare has both simple SSL options and push button SPDY available. By setting up SSL on CloudFlare with subdomains you'll automatically get SPDY as well. In the test above it took me about 10 minutes to set up the test subdomains on jgc.org and enable both SSL and SPDY.

Thanks to Andrew Galloni for his assistance reviewing and investigating the interaction between SPDY and domain sharding.

So, Go has become an important part of CloudFlare Engineering.

And because of that we are actively hiring for people who know Go or want to learn it. We'll soon be open sourcing some of our Go programs and want to find more people to work on our Go code base.

We're currently using Go for PKI tools, our Railgun web optimizer, a new high-performance DNS server and a curl-like tool for SPDY. And we've hosted the GoSF meetup in the past.

So, if you're interested in writing Go code, contributing to Golang itself and having your code go into production against billions of page views per day, get in touch.

About a month and a half ago, CloudFlare announced limited support for SPDY as part of a private beta. SPDY is the new protocol pioneered by Google to make the web faster. If you're curious, we've written about what makes SPDY speedy in previous blog posts.

Since that announcement, we've been testing SPDY with a couple hundred of CloudFlare's customers, as well as on CloudFlare.com itself, in a private beta. The results have been great and today we're excited to announce that SPDY is now available to any eligible CloudFlare customer from theirPerformance Settings page.

The current implementation of SPDY requires TLS/SSL. As a result, SPDY is only supported for paying CloudFlare customers who have SSL enabled. Even if you don't have your own SSL certificate installed on your server, you can take advantage of SPDY by enabling CloudFlare's Flexible SSL. If you're a Free customer, you can upgrade to one of CloudFlare's paid plans and enable SPDY immediately. If, in the future, the SPDY protocol supports non-HTTPS connections, we plan to extend SPDY support to Free customers as well.

Assuming you have SSL enabled, you can turn SPDY on with a single click for all traffic that passes through CloudFlare. SPDY will automatically be enabled for HTTPS traffic to browsers like Chrome and the latest version of Firefox which supports the protocol.

With widespread SPDY support, we're excited to continue to push the web forward as we continue our mission of building a faster, safer Internet.

The solution to problems like Ashton's is to use an encrypted HTTPS connection which requires a website to support SSL. The problem is that the SSL protocol imposes a heavy burden. I'm fairly technically savvy and still find the process of installing and maintaining SSL keys on a web server Byzantine. SSL sessions also add considerable CPU load to web servers and slow down web performance.

CloudFlare is the web performance and security company. For security, we believe it is incumbent on us to make SSL easier and more widely deployed. Given that, in order to maximize performance, we are spending significant resources in order to improve the performance of SSL.

SSL imposes an additional tax on web performance, but it's important to understand exactly how. The primary source of the SSL performance tax comes from the initial setup of a new connection. Before any web page data can be exchanged, a SSL session must be "negotiated" between the client and the server. A simplified version of this process is as follows.

If you have multiple resources on your web page under different domains, your visitors' browsers will need to negotiate an SSL session for each domain. Because each SSL session requires at least 4 additional exchanges, the problems of flakey connections with high loss rates (e.g., connections to mobile devices) are amplified over HTTPS.

SSL certificates are issued by a certificate authority (CA). The CA attests that the website behind the certificate is who they say they are. Sometimes, after a certificate is issued, it is lost or compromised and needs to be revoked. CAs maintain a list of certificates that have been revoked, known as a Certificate Revocation List (CRL). Browsers, when they access a SSL-protected site, can query to download a CA's CRL and parse the list to see if a particular site is on it. Alternatively, they can issue a request via the Online Certificate Status Protocol (OCSP) to check if a particular site has had its certificate revoked.

The problem is, for most CAs CRL and OCSP performance appears to be an afterthought. The CRL and OCSP servers are also not typically geographically distributed or tuned for performance. Verisign, one of the largest CAs, averages nearly 300ms to respond to a OCSP request. That inherently means an additional third of a second gets added to your page load time for any visitor connecting to your site if you're using Verisign's SSL. To add insult to injury, most CAs don't yet accept IPv6 requests to their CRL or OCSP servers.

The problem of CRL and OCSP slowness is a significant enough impact on SSL performance that browser vendors have begun to discuss removing the verifications entirely. While that may help performance, it would hurt overall web security and make it harder to reliably trust a site's SSL.

A number of other factors further contribute to SSL's overall slowness. Often certificates are chained using a number of intermediate certificates, which can increase the amount of data that needs to be exchanged during the initial session negotiation. Most sites haven't taken the time to optimize their crypto cypher. Choosing a crypto cypher that is too weak can subject your site to a number of potential vulnerabilities. On the other hand, choosing a stronger cypher can add load if your site is already CPU bound.

Overall, we regularly hear from customers who want to have SSL protection on their sites but find it either too difficult or to resource intensive. The end result is that many sites that should use SSL don't, sacrificing security for performance. And, for those sites that do support SSL, it is often implemented in a way that causes a significant performance penalty. Neither case is good for the web, so we wanted to see what we could do to help fix the problem.

CloudFlare is working on a number of initiatives to speed up SSL. First, we have a number of techniques to limit the number of connections that a browser needs to make and therefore reduce the number of session initiation handshakes that need be made. Rocket Loader, for example, combines requests for scripts, even across third party services, into a single connection under a site's own domain. We're also rolling out support for SPDY for all SSL-enabled sites, which allows requests to be multiplexed across a single connection.

Beyond reducing the number of connections to improve SSL performance, we're working with Globalsign, our primary CA, to speed up CRL and OCSP. Today, Globalsign's CRL and OCSP requests are powered through CloudFlare's global network and response times are under 100ms. We are also planning on rolling out OCSP stapling, which allows the query for whether a certificate is invalid to be sent from the server without making an additional request to the CA's infrastructure.

CloudFlare runs all its own infrastructure, which allowed us to spec the hardware for maximum SSL performance. We worked with Intel to integrate a custom tuned version of OpenSSL which takes advantage of special instruction sets on our servers' CPUs to make encryption and decryption as fast as possible. In our tests, it is about 30% faster and uses fewer CPU resources. This allows us to choose stronger cyphers that maximize performance without suffering a performance penalty.

Equally important, we've worked to make SSL as easy as possible, regardless of the capabilities of your own infrastructure. SSL is included automatically for every paid CloudFlare plan and is provisioned automatically with a single click. We allow customers to choose Full SSL, which ensures end-to-end encryption, or Flexible SSL, which encrypts the connection from the browser to CloudFlare's network, the riskiest part of the transaction, but doesn't require you to run SSL on your origin server. This allows you to add SSL to services like Google AppEngine and Tumblr, which don't allow SSL support themselves or only include it as an expensive add on.

While CloudFlare's Pro accounts include SSL certificates issued by our own systems, with the launch of our Business and Enterprise tiers, customers can now upload their own certificates to use on our network. This allows support of extended validation (EV) certificates on our optimized infrastructure.

As new performance technologies like SPDY require SSL support, and as new threats continue to emerge online, ensuring SSL runs as fast and secure as possible becomes increasingly important. CloudFlare will continue to work to make SSL performance faster in order to fulfill our mission of building a web that is both safer and faster.

We start with a simple ping. Here's a ping from my laptop machine (which is connected via 802.11g WiFi to a 20Mbps broadband connection) to a machine at Google. Looks like I'm getting a roundtrip time of about 20ms.

Here's the same ping done from my iPhone on the same WiFi network at the same location in the house. The ping time has gone up to about 60ms. So, in this instance, the round trip time had tripled just from going from laptop to phone.

But to see the real cost of mobile it's necessary to switch off WiFi and onto 3G. Here's the ping time on 3G to the same machine. Here's it's both much higher (we're now into 1/10 to 1/5 of a second territory) but it's also variable:

And then I get up and move to the front of the house and try again. The ping time has changed completely (the number of bars didn't) and I'm seeing between 0.5s and 1s of round trip time. That will have a serious effect on web browsing.

And for a final test I return to my original location and grip the iPhone firmly in my hand. The number of bars falls away and the round trip time becomes infinite! Pings simply aren't working any more.

What this illustrates is something that any smartphone user knows instinctively: network performance on phone is very variable and susceptible to location and environment. TCP would actually work just fine on a phone except for one small detail: phones don't stay in one location. Because they move around (while using the Internet) the parameters of the network (such as the latency) between the phone and the web server are changing and TCP wasn't designed to detect the sort of change that's happening.

In past posts I've looked at the effect of high latency on web browsing and TCP's connection and slow start cost. One of the fundamental parts of the TCP specification covers congestion avoidance: the detection and avoidance of congestion on the Internet. At the start of a connection TCP's slow start prevents it from blasting out packets until it's detected the maximum possible speed it can transmit at, and during a connection TCP actively watches for signs of congestion. The smooth running of the Internet as a whole relies on protocols like TCP being able to detect congestion and slow down. If not there'd likely be a congestion collapse.

Image credit: joiseyshowaa

TCP spots congestion by watching for lost packets. On the wired Internet lost packets are a sign of congestion: they're a sign that a buffer in a router or server somewhere along the route packets are taking is full and is simply dropping packets. When lost packets are detected by TCP it slows down.

That all falls apart on mobile networks because packets get lost for other reasons: you move around your house while surfing a web page, or you're on the train, or you just block the signal some other way. When that happens it's not congestion, but TCP thinks it is, and reacts by slowing down the connection.

It seems like it might be a simple matter to change the congestion avoidance algorithm in TCP to take into account the challenges of mobile networks, but it's actually an area of active research with many different possible replacements for the existing basic algorithm. It's hard because trying to balance maximizing throughput, preventing congestion on the Internet, dealing with actual congestion, and spotting phony congestion is complex.

Image credit: mikecogh

And if that weren't enough mobile networks also introduce another tricky problem: packet reordering. Although TCP is designed to cope with reordering of packets (because they might have followed different routes between source and destination) large reordering can occur in mobile networks when a mobile phone is handed off from one tower to the next.

For example, a stream of packets being transmitted by a moving mobile user (perhaps sending a large email) might be split with some going down one route through one tower and the rest through a different tower and by a different route.

This causes problems for some of the newer congestion avoidance algorithms (such as TCP New Reno) and can cause additional slow downs.

CloudFlare helps solve these problems for our customers in two ways. Firstly, we customize the parameters inside the TCP stacks in our web servers to tune for the best possible performance and secondly we actively monitor and classify the connections from people surfing our customers' sites.

By classifying connections we are able to dynamically determine the best way to behave on a connection. We know whether this is likely to be a high-latency mobile phone browsing session, or a high-bandwidth broadband connection in someone's home or office. Doing that allows us to give the best performance to end users, and ensure that customers' web sites are snappy wherever and however they are accessed.

And we continually look at ways of improving network performance for our customers by tuning TCP, monitoring performance, opening new data centers and introducing features like Rocket Loader, Mirage, Polish, SPDY, and Railgun.

Image credit: Loco_2

Google has proposed a new protocol for downloading web pages called SPDY and CloudFlare will shortly be making it available in beta form. SPDY is designed to make web browsing faster without replacing HTTP. This blog post explains how it works and why it helps.

Current web browsing makes use of the HTTP protocol running over TCP.The TCP protocol underlies many other uses of the Internet (such assending and receiving email) because it provides reliable delivery ofdata. HTTP is independent of TCP and provides a mechanism for a webbrowser to ask for pages, graphics and other files needed to display aweb page.

SPDY sits between HTTP and TCP to speed up the HTTP protocol by changing how it interacts with TCP. First, let's look at getting a web page with HTTP over TCP without SPDY and then see how that changes with SPDY.

A typical web browsing session goes something like this: you type cloudflare.com into your browser and it sends an HTTP request over TCP to the cloudflare.com server asking for the the HTML of the page. The page is delivered and the browser sets about parsing the page to determine what else it needs to download (e.g. the style sheets and images that make up the page).

Here's a screen shot from Firebug running in Mozilla Firefox. You can see the page being downloaded at the top and then the parts of the page (such as JavaScript, CSS and images) being downloaded in parallel.

But what's not clear from that view is how Firefox is actually connecting to the web server and retrieving the parts of the page. For that it's necessary to dig a little deeper. Using a combination of Wireshark and a custom program written in Processing here's a view of the TCP connections and downloading of each part of the CloudFlare home page.

The scale at the top shows elapsed time in seconds. Down the left hand side is the identifier of each TCP connection; each row in the diagram is a single TCP connection. On the right hand side is a number indicating how many separate parts of the page (images, CSS, JavaScript) were downloaded by the connection on that row.

The colors just indicate different parts of the page being downloaded. The size of the bars equates to the total time to get that part of the page.

The first connection begins by downloading the HTML of the page and then straight after that Firefox reuses the connection and opens another 6 connections to retrieve parts of the page. By opening multiple connections Firefox gets to download in parallel, by reusing a connection Firefox saves time starting a connection.

After the first set of connections there are another set used to download parts of the page. Some of these connections are reused multiple times.

It's likely pretty obvious why Firefox uses multiple simultaneous connections (because downloading can happen in parallel), but its reuse of connections is a little less obvious. Connections are reused because of two costs: connection set up time and TCP slow start.

First, it takes time to set up a TCP connection. The browser connects to the server and goes through a handshake to establish the connection. In the example above each connection was taking roughly 50ms to establish. If you did that for all 36 items being downloaded it would add up to 1.8s (longer than the entire download took). So, clearly reusing a connection helps.

Image credit: Charles & Clint

But TCP slow start also matters. In a previous post I looked at the effect of bandwidth and latency on downloading. What that post didn't mention is that the theoretical download speed is only reached after a period of slowness at the beginning of a TCP connection.

To avoid causing congestion on the Internet, every TCP connection starts slowly and works up to the maximum speed available. This is called TCP Slow Start. So, each time a new TCP connection is established there's a double penalty: connection set up time and slow start. TCP slow start is also problematic on high latency links because detecting the maximum speed available on the connection requires back-and-forth packet exchanges.

Thus, to make efficient use of TCP the ideal browser would open a small number of connections and reuse them. That way the connection cost would be low, TCP slow start would be minimized and download speed would be maximized.

So, why did Firefox open 20 separate connections and only reuse them for a small number of requests each? Take a look at the line corresponding to connection 47108 in the diagram. Notice how a small download (in blue) had to wait behind a large download (in red).

Since the web browser can't predict how large or small the response to each request will be it is not able to order requests for efficient delivery. So, there's a balancing act to find the right number of connections to minimize page load time as bandwidth, latency, connection time and slow start have to be taken into account.

Using a small number of connections would result in blocking (a long slow download of say a large image could block a small quicker download because there's no 'overtaking' in HTTP); a large number of connections would avoid blocking and pay the price of connection set up and slow start.

Also, opening a large number of connections would place a load on the web server as each connection takes up resources on the server itself.

These problems come about in part because HTTP is synchronous: a request is made for part of a page and the connection it was made on needs to wait for the response. A better protocol would allow multiple requests to be sent and the responses returned in the order they are available. Line 47108 would look very different in that case: all three requests could be sent and the small one would be returned first even though it was the second request.

Image credit: Capt' Gorgeous

SPDY fixes all these problems in one go.

SPDY allows a single connection to be used for multiple requests. The requests can be sent in any order and responses come back in the order that they are available. Since a single connection is used the connection set up cost and slow start are minimized. Since requests can be answered in any order there's no blocking.

Of course, SPDY also does other things (such as compression of previously uncompressed parts of HTTP), but its core benefit is that it decouples HTTP from TCP and in doing so allows asynchronous, overlapping HTTP requests on a single connection. All without changing HTTP at all.

And shortly CloudFlare will be rolling out SPDY to our customers. Information about the beta is here.

In 2009, Google began work on a new network protocol to make web pages faster. Dubbed SPDY (pronounced "speedy"), the protocol is designed to solve many of the bottlenecks that slow HTTP down. Beginning today, we're rolling out a beta of SPDY to CloudFlare customers. Read this post and then, if you're interested in participating in the beta, complete the beta application form.

Standard HTTP needs to make a new TCP request for all the objects on the page, Because there is significant overhead for each new TCP connection, all these connections slow down performance significantly. SPDY's biggest win comes from what is known as connection multiplexing. This means that mutiple objects from a particular site are requested and retrieved from a single request. Less connection overhead means faster page loads.

HTTP also requests objects in a particular order and one slow resource can block the loading of other resources. SPDY allows the browser to query for multiple objects in one request and for the objects to be sent down the wire as they are ready and out of order. Again, this can increase performance by not holding up the delivery of objects that are available quickly because some take longer to request.

SPDY includes some other performance wins as well. It allows HTTP headers to be compressed, which isn't possible with standard HTTP connections. The compression algorithm uses a HTTP-aware dictionary, which means common strings that appear in headers don't need to be sent across the network. Every byte you don't need to send not only reduces bandwidth use but, more importantly, increases web performance.

While there is a lot of excitement around SPDY, there are some caveats. The first is that only certain browsers support the protocol. Google's Chrome and the latest release of Firefox (version 11+) contain SPDY support. While the Internet Engineering Task Force (IETF) is considering SPDY as an official Internet protocol, it has not yet been adopted so it's not clear whether there will be additional support from browsers such as Microsoft's Internet Explorer and Apple's Safari.

SPDY is built on top of TLS, which means it requires a site to have a valid SSL certificate in order to work. This, unfortunately, limits SPDY only to CloudFlare's paid customers who have enabled Flexible or Full SSL support. Microsoft is working on revised IETF proposal that is SPDY-like, but removes the requirement for SSL/TLS. If the TLS requirement is removed in the future, we'll make SPDY (or whatever it comes to be called) available more broadly.

Very few sites currently support SPDY (Google's sites and Twitter being the most notable to support the protocol). As a result, there haven't been a significant number of real world case studies. A recent article by an Akamai researcher pointed out that for much of the web SPDY's performance wins will be limited. We've confirmed similar findings in our tests. The primary reason for this caveat is that most sites are a collection of objects from multiple sources. Since SPDY's multiplexing only works on a per-domain basis, if a site has objects pulled from multiple sources then even if all those sources support SPDY connections still won't be able to be multiplexed between them.

Finally, SPDY is complicated to setup for a lot of sites. Support on most web servers is nascent and unproven. Because of this, sites have been hesitant to setup SPDY support themselves.

The good news is CloudFlare is making SPDY extremely easy and features like Rocket Loader remove some of the biggest SPDY caveats, making the protocol even speedier. For SPDY support, CloudFlare acts as a gateway. Similar to how CloudFlare's Automatic IPv6 Gateway works, an origin server doesn't need to support SPDY. Instead, visitors with browsers that support SPDY connect to CloudFlare over the protocol. We handle the multiplexing and begin sending down objects we already have in our cache. The request to the origin server for non-cached objects is sent over standard HTTP/S. As a result, CloudFlare customers can implement SPDY support with a single click.

CloudFlare's Rocket Loader also helps with some of the multiplexing limitations. Rocket Loader was built to provide multiplex-like support over a standard HTTP connection. By gathering all scripts, regardless of where they're hosted, into a single HTTP request, Rocket Loader limits the number of HTTP connections that are needed. This also means that even third party scripts that appear on your page are requested under your site's domain. As a result, if you enable SPDY and Rocket Loader together then you will be able to get the benefits of multiplexing even for many of the object that make up your site even if they are hosted outside of your domain.

CloudFlare is rolling out the SPDY beta to select customers over the coming weeks. To be eligible for the beta, you need to have SSL enabled which requires one of CloudFlare's paid plans. As mentioned above, this is a limitation of the protocol and if that limitation is removed in the future then we'll plan on rolling out SPDY support more broadly. If you're interested in trying it, complete the beta application form and we'll send you an invitation as space is available.

At CloudFlare, we're committed to making the web speedier in every way we can. We're excited to offer the first easy way for websites that want to support SPDY to be able to do so easily and in a way that will get the most out of the protocol.

At CloudFlare, we built our own CDN from the ground up. We used the latest technologies like solid state drives for screaming I/O and Anycast routing and geo load balancing to make it as fast and efficient as possible. But we didn't want our efforts to make the web faster to stop with the traditional CDN. There were two core problems we wanted to address. The first was that a website can no longer be thought of as served from a single web server in a single location. Websites are collections of multiple apps, widgets, and tags that include everything from the ad network code inserted on a page to include advertising to the Facebook Like button.

Anyone surfing the web has noticed the alert in the lower-left of your browser that says: "Waiting for _________ to load." In the past, if any one of these third party apps was slow to load, no matter what you did to improve your own site's performance, they could drag you down. While this lag is annoying on desktops, it's nearly impossible on a mobile device. Think of it this way: each one of those connections to another third party service is another opportunity for your mobile phone provider to screw up.

The second problem was that any script on a web page could potentially block it from rendering. The way browsers work, whenever a piece of script is encountered by default the browser needs to stop and wait for it to render before it can finish drawing the page. Again, we've all seen this: a site that the top part of the page loads, then it hangs while it waits for an ad, then the rest of the page fills in.

Compare that with how some of the Internet Giant's sites load. Facebook, for example, renders the page extremely quickly with the initial content you can see, then fires the scripts necessary to load in ads and make the pages interactive. The experience is not just a site that loads faster, but one that feels much snappier. And, again, with their more limited memory and CPU, the lag created by processing scripts is only amplified on mobile devices.

At CloudFlare, our team has spent the last year figuring out how we could leverage our technology to address both these issues. The first step in this is what we call Rocket Loader™. Rocket Loader does a bunch of things:

1. It ensures that all the scripts on your page will not block the content of your page from loading;

2. Loads all the scripts on your page, including third party scripts, asynchronously;

3. Bundles all the script requests into a single request over which multiple responses can be streamed;

4. Uses LocalStorage on most browsers and nearly all smart phones to more intelligently store scripts so they aren't refetched unless necessary.

At a high level, here's a diagram that outlines a way to think about it.

CloudFlare adds two layers of cache for third party scripts that don't change often. First, we can store the scripts on our global CDN, so they are close to all your visitors and get the benefits of our extensive network (and an already-open HTTP connection). Second, on most modern browsers and smartphones, we use the browser's LocalStorage cache to intelligently store the resources that the site needs in order to avoid round trips to the server. Here's the Firebug waterfall chart of two pages loading before/after Rocket Loader is applied:

Google has done great work in this space, creating a protocol called SPDY. It is great, does many of the same performance optimizations and some others as well, but unfortunately only works with the Chrome browser. Rocket Loader will bring many of the same performance benefits promised by SPDY, but works on most browsers and all smart phones, whether your visitors are surfing your site from an iPhone, Android, or Windows device.

What's also really cool about this is, unlike some other companies that have done limited work in the space, CloudFlare doesn't need to cache your content in order to make these improvements. We modify the HTML on-the fly as it passes through our network, without slowing down page delivery. This means that CloudFlare can improve the performance of even highly dynamic websites without forcing you to flush your cache every time there's an update to your pages.

Want to see it in action? Check out the performance of the Financial Times site loaded side-by-side in a Firefox browser.

Despite the fact that FT is using one of the top-tier CDNs, Rocket Loader is able to double the site's performance. We don't mean to pick on the Financial Times: I personally love their content. While the improvement here is dramatic, we saw similar benefits across most major media sites despite heavy CDN usage.

People ask us all the time if CloudFlare is a CDN, and the answer at some level is yes. We run a globally distributed, load-balanced network that caches static content closer to the visitor. But, really, we've built something that's much more. We've taken the lessons learned from the last 15 years of CDNs, improved on those, and then applied many new technologies that take web performance to an entirely new level. You can learn more from a presentation Chris and Jason from our engineering team recently gave on the technology behind Rocket Loader.

Rocket Loader doesn't cost us anything more to deploy, and we believe everyone should have access to a fast site, so we include it in all of our plans: even the free one. Give it a try with one click from your CloudFlare settings page. If you find any pages with bugs, let us know through our special bug reporting page for the feature. This is a radical new approach to web performance, and we're pushing updates daily to make it better and better.