Photo by Liu Zai Hou / Unsplash

In Q2, Cloudflare released several products which enable a better Internet “end-to-end” — from the mobile client to host infrastructure. Now, anyone from an individual developer to large companies and governments, can control, secure, and accelerate their applications from the “perimeter” back to the “host.”

On the client side, Cloudflare’s Mobile SDK extends control directly into your mobile apps, providing visibility into application performance and load times across any global carrier network.

On the host side, Cloudflare Workers lets companies move workloads from their host to the Cloudflare Network, reducing infrastructure costs and speeding up the user experience. Argo Tunnel lets you securely connect your host directly to a Cloudflare data center. If your host infrastructure is running other TCP services besides HTTP(S), you can now protect it with Cloudflare’s DDoS protection using Spectrum.

So for end-to-end control that is easy and fast to deploy, these recent products are all incredible “workers” across the “spectrum” of your needs.

End users want richer experiences, such as more video, interactivity, and images. Meeting those needs can incur real costs in bandwidth, hardware, and time. Cloudflare addresses these with three products that improve video delivery, reduce paint times, and shrink the round-trip times.

Cloudflare now simplifies and reduces delivery cost of video with Stream Delivery. Pages using plenty of Javascript now have faster paint times and wider mobile-device support with Rocket Loader. If you’re managing multiple origins and want to ensure fastest delivery based on the shortest round-trip time, Cloudflare Load Balancer now supports Dynamic Steering.

Attackers are shifting their focus to the application layer. Some security features, like CAPTCHA and Javascript Challenge, give you more control and reduce false-positives when blocking rate-based threats at the edge, such as layer 7 DDoS or brute-force attacks.

Finally, Cloudflare extended privacy to consumers through the launch of our DNS resolver 1.1.1.1 on 4/1/2018! Now users who set their DNS resolvers to 1.1.1.1 can browse faster while protecting browser data with Cloudflare’s privacy-first consumer DNS service.

Tue, July 10, 2018Dynamic steering is a load balancing feature that automates traffic steering across origins in multiple geographic regions. Round-trip time (RTT) for health checks is calculated across multiple pools of load balanced servers and origins to determine the fastest server pools. This RTT data enables the load balancers to identify the fastest pools, and to direct user requests to the most responsive origins.

• Blog Post

• Product Page

• Support Article

Thu, July 5, 2018Cloudflare's Authoritative DNS now supports the following record types: CERT, DNSKEY, DS, NAPTR, SMIMEA, SSHFP, TLSA, and URI via the web and API.

Mon, June 11, 2018The Developer Portal has been updated in Q2 to include improved search, documentation for new products, and listings of upcoming Cloudflare community events.

• Developer Portal

Fri, June 1, 2018Rocket Loader has been updated to deliver faster performance for website paint & load times by prioritizing website content over JavaScript. Majority of mobile devices are now supported. Increased compliance with strict content security policies.

• Support

• Blog

Thu, May 31, 2018Cloudflare’s Stream Delivery solution offers fast caching and delivery of video content across our network of 150+ global data centers.

• Product Page

Tue, May 29, 2018On June 4, Cloudflare will be dropping support for TLS 1.0 and 1.1 on api.cloudflare.com. Additionally, the dashboard will be moved from www.cloudflare.com/a to dash.cloudflare.com and will require a browser that supports TLS 1.2 or higher.

• Product Page

• Blog Post

Mon, May 21, 2018Rate Limiting has two new features: challenges (CAPTCHA and JS Challenge) as an Action; and matching Header attributes in the response (from either origin or the cache) as the Trigger. These features give more control over how Cloudflare Rate Limiting responds to threshold violations, giving customers granularity over the types of requests to "count" to fit their different applications. To learn more, go to the blog post.

• Product Page

• Blog Post

Thu, May 10, 2018The Cache-Tag header now supports up to 1000 tags and a total header length of 16kb. This update simplifies file purges for customers who deploy websites with Drupal.

• Support article

Wed, May 2, 2018Starting May 2 2018, users can go to the new home of Cloudflare’s Dashboard at dash.cloudflare.com and share account access. This has been supported at our Enterprise level of service, but is now being extended to all customers.

• Blog Post

Thu, April 12, 2018Cloudflare is now able to validate origin certificates that use a hostname's CNAME target in Full SSL (Strict) mode. Previously, Cloudflare would not validate any certificate without a direct match of the HTTP hostname and the certificate's Common Name or SAN. This update allows SSL for SaaS customers to more easily enable end-to-end security.

• Support

• SSL for SaaS

Thu, April 12, 2018Spectrum protects TCP applications and ports from volumetric DDoS attacks and data theft by proxying non-web traffic through Cloudflare’s Anycast network.

• Product Page

• Blog Post

Wed, April 11, 2018Cloudflare workers can now control cache TTL by response code. This provides greater control over cached assets with Cloudflare Workers.

• Documentation

Thu, April 5, 2018Argo Tunnel ensures that no visitor or attacker can reach your web server unless they first pass through Cloudflare. Using a lightweight agent installed on your origin, Cloudflare creates an encrypted tunnel between your host infrastructure and our nearest data centers without opening a public inbound port. It’s more secure, more performant, and easier to manage than exposing your services publically.

• Developer Doc

• Read More

No longer a beta product, Rocket Loader controls the load and execution of your page JavaScript, ensuring useful and meaningful page content is unblocked and displayed sooner.

For a high-level discussion of Rocket Loader aims, please refer to our sister post, We have lift off - Rocket Loader GA is mobile!

Below, we offer a lower-level outline of how Rocket Loader actually achieves its goals.

Early humans looked upon Netscape 2.0, with its new ability to script HTML using LiveScript, and <BLINK>ed to ensure themselves they weren’t dreaming. They decided to use this technology, soon to be re-christened JavaScript (a story told often and elsewhere), for everything they didn’t know they needed: form input validation, image substitution, frameset manipulation, popup windows, and more. The sole requirement was a few interpreted commands enclosed in a <script> tag. The possibilities were endless.

Soon, the introduction of the src attribute allowed them to import a file full of JS into their pages. Little need to fiddle with the markup, when all the requisite JS for the page could be included in a single, or a few, external files, specified in the page’s <HEAD>. It didn’t take our ancestors long before they decided that the same JS file(s) should be in all pages, throughout their website, containing JS for the complete site. No worries about bloat; after all, the browser would cache it.

A clear, sunny, road to dynamic, interactive sites lay ahead. What could go wrong?

Those early JS adopters deduced that when the HTML parser encountered an external script, it suspended visual rendering of the page while it went off to retrieve and execute it. Simple. The more numerous and larger the scripts, the longer the wait for the page to paint. JavaScript, therefore, was very soon, most often unnecessarily, blocking page rendering.

The solutions poured in, both from the developer community and browser vendors:

• Community: Move script location to end of HTML pageA classic duh! moment. Amazingly, this simple suggestion helped, unless the script was required to help build the page, eg. using document.write for markup.

• Vendor: Use <script defer>.It’s 1997, and IE4 introduces the defer attribute. Scripts that do not contribute to the initial rendering of the page should be marked with defer, and they will load in parallel, without blocking, and be executed in their markup order before window.load is fired (later, before document.DOMContentLoaded). Script tags could remain in the <head>, and execute as if they were at the end of page.The main benefit to page rendering was the saving in script retrieval time.

• Community: Reduce latency by reducing actual script size.What began as script obfuscation for intellectual property and vanity reasons, quickly became script minification, still used widely.

• Community: Reduce latency and http handshake instances through concatenation of all scripts, delivered as one.

• Vendor: Use <script async>.In 2010, 13 years (yes, 13, thirteen) after defer was born, HTML5 provided defer with a sibling, async. Scripts can be loaded asynchronously, be non-blocking, and be executed when they load. Markup order is irrelevant to execution order. A clear benefit over defer was that load/DOMContentLoaded events were not delayed.

• Community: Lazy Loading.Use JS to load JS by dynamically creating non-blocking script tags.

• Cloudflare: Rocket LoaderIt's 2011, and Cloudflare enters the fray, leveraging our network to reduce http requests for 1st party scripts, “bag”ging 3rd party scripts into a single file, and delaying and controlling JS execution.See Combining Javascript & CSS, a Better Way

• Vendor: Use <link rel="preload"> in the <head>.Important resources like scripts, in our case, can be specified for preload. The browser will load scripts in parallel and not block render-parsing.

Much has been written in this blog space about Rocket Loader, from its initial launch, to the current one.

If reading outdated blog posts is not your thing, perhaps watching an extremely short video of a high-profile early Rocket Loader success (June 9, 2011) is:CloudFlare Rocket Loader makes the Financial Times website (FT.com) faster

Rocket Loader improved page load times by:

1. Minimising network requests through the bundling of JS files, including third-party, speeding up page rendering

2. Asynchronously loading the bundles, avoiding HTML parsing blockage

3. Caching scripts locally (using LocalStorage), reducing refetch requests.

As browsers matured, Rocket Loader fell behind, leading to several severe shortcomings:

• It did not honour Content-Security-Policy.Rocket Loader was unaware of CSP headers, and loaded scripts indiscriminately.

• It did not honour Subresource IntegrityRocket Loader loaded scripts through XHR, so browsers could not validate the fetched script.

• It allowed for XSS PersistenceSince Rocket Loader stored scripts in LocalStorage, a site’s compromised script could exist as a trojan in a customer’s storage, loading whenever the customer visited the site.

• It was just out-of-date

  • Script bundling fell out of favour with the introduction of http2.

  • The use of eval() was finally recognised as evil.

  • Mobile use skyrocketed; mobile browsers became sophisticated; eventually Rocket Loader was unable to support mobile.

We recently rebuilt Rocket Loader from the ground up.

Although our aim remains the same, to improve customer page performance, we incorporated lessons learned. Most importantly, we learned not to aim too high. In order to satisfy all permutations of page layout, the old Rocket Loader created a virtual DOM, a decision that ultimately led to fragility. We've gone the simple, elegant route, knowing full well that there will be a minority of websites that will not benefit.

The main concept behind Rocket Loader is quite straightforward: execute blocking scripts after all other page assets have loaded.

The scripts need to be loaded and executed in the originally intended order. Only external blocking scripts curtail page resources, but any script may rely on another one. We must simulate the loading process of scripts, mimicing how the browser would handle them during page load, but do it after the page is actually fully loaded.

Rocket Loader has both a server-side and a client-side component. The goal of the former is to

1. rewrite <script> tags in the page markup to make them non-executable, and

2. insert the client-side component of Rocket Loader into the page.

The server-side component is built on top of our CF-HTML pipeline. CF-HTML is an nginx module that provides streaming HTML parsing and rewriting functionality with a SAX-style (Simple API for XML) API on top of it.

To make the scripts non-executable, we simply prepend their type attribute value with a randomly generated value (nonce), unique for each page request. Having a unique prefix for each page prevents Rocket Loader from being used as an XSS gadget to bypass various XSS filters.

Markup that looked like this:

<!DOCTYPE html>
<html>
  <head>
    <script src="example.org/1.js"></script>
    <script src="example.org/2.js" type="text/javascript"></script>
  </head>
  <body>
    ...body markup... 
    <script src="example.org/3.js" type="text/javascript"></script>
    ...more body markup... 
  </body>
</html>

becomes:

<!DOCTYPE html>
<html>
  <head>
    <script src="example.org/1.js" type="42deadbeef-"></script>
    <script src="example.org/2.js" type="42deadbeef-text/javascript"></script>
  </head>
  <body>
    ...body markup... 
    <script src="example.org/3.js" type="42deadbeef-text/javascript"></script>
    ...more body markup... 
    <script src="https://ajax.cloudflare.com/rocket-loader.js"
            data-cf-nonce="42deadbeef" defer>
  </body>
</html>

So far, no rocket science, but by making most, or all, scripts non-executable, Rocket Loader has unblocked page-parsing. Browsers display content sooner, improving perceived page load metrics, and engaging the user.

Generally, scripts can be divided into four categories, each having distinct load and execution behaviours when inserted into the DOM:

1. Inline scripts - executed immediately upon insertion.

2. External blocking scripts - start loading upon insertion, preventing other scripts from loading and executing.

3. External defer scripts - start loading upon insertion, without preventing other scripts from loading and executing. Execution should happen right before DOMContentLoaded event.

4. External async scripts - start loading upon insertion, without preventing other scripts from loading and executing. Executed when loaded.

Modified diagram from HTML Standard

To handle load and execution of all script types, Rocket Loader needs two passes.

On the first pass, we collect all scripts with our nonce onto a stack, then re-insert them into the DOM, with nonce removed, and wrapped in a comment node. These serve as our placeholders.

<!DOCTYPE html>
<html>
  <head>
    <!--<script src="example.org/1.js"></script>--> 
    <!--<script src="example.org/2.js" type="text/javascript"></script>-->
  </head>
  <body>
    ...body markup...
    <!--<script src="example.org/3.js" type="text/javascript"></script>-->
    ...more body markup... 
    <script src="https://ajax.cloudflare.com/rocket-loader.js"
            data-cf-nonce="42deadbeef" defer>
  </body>
</html>

Rocket Loader now iterates through the scripts in our stack and re-inserts them, maintaining their intended position in relevant DOM collections (document.scripts, document.querySelectorAll("script"), document.getElementsByTagName("script"), etc.).

This process of script insertion and execution differs for each script category:

Inline scripts - Placeholder is replaced with the original script element, without nonce, making the script executable. Browsers execute such scripts immediately upon insertion, in the same execution tick.

External blocking scripts - As above, but Rocket Loader waits for the script’s load event before unwinding the script stack further. This delay simulates the script's blocking behaviour manually. Only parser-inserted external scripts (i.e. scripts present in the original HTML markup) are naturally blocking. External scripts inserted or created via a DOM API are considered async. This behaviour can’t be overridden, so we need our simulation.

External async scripts - The same insertion procedure as inline scripts. Browsers treat all inserted external scripts as async, so the default behaviour suits us.

External defer scripts - These are not executed during the first pass, since in the simulated environment we haven’t reached the DOMContentLoaded event yet. If we encounter a defer script on the stack we re-insert it, as is, without removing the nonce prefix. It remains non-executable, but in the correct DOM position.

The second pass loads the defer scripts. Again, Rocket Loader collects all scripts with the nonce prefix (these are now just defer scripts) onto the execution stack, but does not replace them with placeholders. They remain in the DOM, since at this point in our simulated environment the complete document has loaded. We then activate them by replacing the <script> elements with themselves, nonce removed, and let the browser do the rest.

Ostensibly, we have now simulated browser script loading and execution behaviours. However, there are some one-off issues we must deal with, quirks if you will.

There is one not-so-obvious difference between our algorithm and the real behaviour of browsers. Modern browsers try to be clever with the way they manage page resources, engaging various heuristics to improve performance during page load. These are, generally, implementation-specific and not set-in-stone by any specification.

One such optimisation that affects us, is speculative parsing. Despite the official specification requiring a browser to block parsing on script execution, browsers continue parsing received HTML markup speculatively, and prefetch found external resources. For example, even with blocking scripts on a page, Chrome loads them simultaneously, in parallel.

With Rocket Loader, browsers don’t prefetch scripts, as our nonce makes them non-executable during page load. Later, when we sequentially re-insert activated scripts, we witness a sequential “waterfall” graph.

In our attempt to improve page load performance, we significantly slowed down some script loading. Ironic. Fortunately, we have a workaround: we can insert preload hints (see Preloading content with rel="preload") before we begin unwinding our script stack, giving the browser notice that we’ll soon be requiring these scripts. It begins fetching them as it would do during speculative parsing.

Our waterfall is replaced with improved parallel loading and better load metrics.

We've simulated script execution and insertion. We still need to deal with dynamic markup insertion. We can’t use document.write() directly since the document is already parsed and document.close() has been implicitely executed. Calling write() will create a new document, erasing the entire current document. We must manually parse content created by the document.write function and insert it in the intended location.

Not so simple, if one considers that document.write can insert partial markup. In the following example, if we parse and insert content on the first document.write call, we’ll completely ignore the completion of the id attribute that should be inserted with the second call:

document.write('<div id="elm');
document.write(Date.now());
document.write('">some content</div>');

So, we have a hard choice:

• We can buffer all content inserted via document.write during script execution and flush it afterwards, in which case already executed code expecting elements to be in the DOM will fail, or

• We can flush inserted markup immediately, but not handle partial markup writes.

Choosing the lesser of two evils, we decided to go with the first option: our observations showed cases like these are more common.

(Actually, there is a third option that allows for handling of both cases, but it requires proxying of a significant number of DOM APIs, a rabbit hole that we don’t want to dive into, KISS FTW, you know…).

As mentioned, it’s not enough to just insert parsed markup. There are various modifications of the DOM performed by the parser during full document parsing that contend with malformed markup. We felt we should simulate at least some of them, because, well… scripts may rely on malformed markup.

Our initial implementation even included simulation of relatively exotic mechanisms such as foster parenting, but eventually we decided to keep things simple and the only thing that Rocket Loader simulates is the squeezing out of unallowed content from the <head> element.

To perform this simulation we wrap our document.write buffer in a <head> element and feed this markup to the DOM Parser.

Using the resulting document from the parser, we identify all nodes in its <head> and move them into the page, immediately following the script that performed the document.write. If we encounter any nodes in the parsed document's <body> element, we copy all nodes that follow the current script to the <body> element, prepended with the nodes in the parsed document.

To illustrate this simulation, consider the following page markup:

<!DOCTYPE>
<head>
  <script>
    document.write(‘<link rel=”stylesheet” href=”1.css”>’);
    document.write(‘<div></div>’);
    document.write(‘<link rel=”stylesheet” href=”2.css”>’);
  </script>
  <link rel=”stylesheet” href=”3.css”>
</head>
<body>
  <div>Hey!</div>
</body>

The buffered, dynamically inserted, markup after script execution will be

<link rel=”stylesheet” href=”1.css”>
<div></div>
<link rel=”stylesheet” href=”2.css”>

and the string that we’ll feed to the DOMParser will be

<!DOCTYPE>
<head>
  <link rel=”stylesheet” href=”1.css”>
  <div></div>
  <link rel=”stylesheet” href=”2.css”>
</head>

The parser will produce the following document structure from the provided markup (note that <div> is not allowed in <head> and was squeezed out to the <body>):

<!DOCTYPE>
<html>
<head>
  <link rel=”stylesheet” href=”1.css”>
</head>
<body>
  <div></div>
  <link rel=”stylesheet” href=”2.css”>
</body>
</html>

Now we move all nodes that we found in parsed document's <head> to the original document:

<!DOCTYPE>
<head>
  <script>
    document.write(‘<link rel=”stylesheet” href=”1.css”>’);
    document.write(‘<div></div>’);
    document.write(‘<link rel=”stylesheet” href=”2.css”>’);
  </script>
  <link rel=”stylesheet” href=”1.css”>
  <link rel=”stylesheet” href=”3.css”>
</head>
<body>
  <div>Hey!</div>
</body>

We see that parsed document's <body> contains some nodes, so we prepend them to the original document’s <body>:

<!DOCTYPE>
<head>
  <script>
    document.write(‘<link rel=”stylesheet” href=”1.css”>’);
    document.write(‘<div></div>’);
    document.write(‘<link rel=”stylesheet” href=”2.css”>’);
  </script>
  <link rel=”stylesheet” href=”1.css”>
  <link rel=”stylesheet” href=”3.css”>
</head>
<body>
  <div></div>
  <link rel=”stylesheet” href=”2.css”>
  <div>Hey!</div>
</body>

And as a final step, we move all nodes in the <head>, that initially followed the current script, to after the nodes that we’ve just inserted in the <body>:

<!DOCTYPE>
<head>
  <script>
    document.write(‘<link rel=”stylesheet” href=”1.css”>’);
    document.write(‘<div></div>’);
    document.write(‘<link rel=”stylesheet” href=”2.css”>’);
  </script>
  <link rel=”stylesheet” href=”1.css”>
</head>
<body>
  <div></div>
  <link rel=”stylesheet” href=”2.css”>
  <link rel=”stylesheet” href=”3.css”>
  <div>Hey!</div>
</body>

There is one edge case which drastically changes the behaviour of our script-loading simulation. If we encounter elements with inline event handlers in the HTML markup, we need to execute all scripts that precede such elements since the handlers may rely on them.

We insert the Rocket Loader client side script in special "bailout" mode immediately before such elements. In bailout mode, we activate scripts the same way as in regular mode, except we do it in a blocking manner (remember, we need to prevent element from being parsed while we activate all preceding scripts).

As noted, it’s impossible to dynamically create blocking external scripts using DOM APIs such as document.appendChild. However, we have a solution to overcome this limitation.

Since the page is still loading, we can document.write the outerHTML of activatable script into the document, forcing the browser to mark it as parser-inserted and, thus, blocking. However, the script will be inserted in a DOM position different from its original, intended, position, which may break traversing of surrounding nodes from within the script (e.g. using document.currentScript as a starting point).

There is a trick. We leverage browser behaviour which parses generated content in the same execution tick as the document.write that produced it. We have immediate access to the written element. The execution of the external script is always scheduled for one of the next execution ticks. So, we can just move script to its original position right after we write it and have it in the correct DOM position, awaiting its execution.

The need to account for every quirk, every variation in browser parsing, is strong, but implementation would eventually only weaken our product. We've dealt with the best part of browser parser behaviours, enough to benefit the majority of our customers.

As Rocket Loader matures, and inevitably is affected by changes in Web technologies, it may be expanded and improved. For now, we're monitoring its use, identifying issues, and ensuring that it's worthy of its predecessor, which lasted through so many advances and changes in Web technology.

1. Oscar Wilde, Lady Windermere's Fan (1892), and apologies to Jethro Tull for the blog post title. ↩︎

Photo by SpaceX / Unsplash

We initially launched Rocket Loader as a beta in June 2011, to asynchronously load a website’s JavaScript to dramatically improve the page load time. Since then, hundreds of thousands of our customers have benefited from a one-click option to boost the speed of your content.

With this release, we’ve vastly improved and streamlined Rocket Loader so that it works in conjunction with mobile & desktop browsers to prioritise what matters most when loading a webpage: your content.

To put it very simplistically - load time is a measure of when the browser has finished loading the document (HTML) and all assets referenced by that document.

When you clicked to visit this blog post, did you wait for the spinning wheel on your browser tab to start reading this content? You probably didn’t, and neither do your visitors. We’re conditioned to start consuming content as soon as it appears. However the industry had been focused on the load event timing too much, ignoring user perception & behaviour. Data from Google analytics has shown that 53% of visits are abandoned if a mobile site takes longer than 3 seconds to load. This makes sense if you think about the last time you browsed onto a website in a hurry - if nothing is rendered quickly on screen you’re much more likely to go elsewhere.

Paint timing metrics are a closer approximation of how your users perceive speed. Put simply, paint timing measures when something is displayed on screen, and there are various stages of paint that can be measured & reported which we’ll explain as we go.

One of the ways in which you can learn more about your website’s performance is to use one of the many great synthetic analysis tools out there. The Lighthouse tool in Chrome can run a performance audit on your page simulating a typical mobile device & connection. I ran this on Cloudflare’s homepage to illustrate the way the page loads over time:

The First Meaningful Paint (FMP) takes 4.8 seconds on this mobile device simulation. FMP doesn’t measure the time of the first paint, but it waits for any web fonts to render and for the biggest above-the-fold layout change to happen. The red line drawn at 4.8 seconds shows our FMP in this test. So what can we do to improve?

Most tools will give you suggestions, and Lighthouse calls these opportunities and orders these by their estimated time saving:

Try running a lighthouse audit on your website and see what opportunities you get.

Now is a good time to quantify the spread of JavaScript on the web. Using the excellent HTTP Archive project we can review the make up of the Alexa top 500k websites over the years. Using their data, we can see that the median number of JavaScripts on mobile has increased from 5, at Rocket Loader’s launch in June 2011, increasing nearly four fold to a whopping 19 JavaScripts in May 2018. So most of us have plenty of JavaScript on our websites and there’s a good chance it will be very high on the list of performance opportunities you can seize to improve your visitors’ experience.

Implementing this recommendation would require you to make changes to your origin application’s code to asynchronously load, defer or inline your scripts. In some cases this might not be possible because you don’t control your application’s code or have the expertise to implement these strategies. Rocket Loader to the rescue!

Without Rocket Loader

With Rocket Loader

New Rocket Loader prioritises paint time by locating the JavaScripts inside your HTML page and hiding them from the browser temporarily during the page load. This allows the browser to continue parsing the rest of your HTML and begin discovering other assets such as CSS & images that are required to render your page. Once that has completed, Rocket Loader dynamically inserts the scripts back into the page and so the browser can load these.

This bit is quite labour-intensive, so watch closely:

Let’s run lighthouse again on our homepage now we have Rocket Loader enabled:

So Lighthouse has detected that First Meaningful Paint is just over 1.5 seconds faster in this test - a really impressive improvement delivered from a single click!

To drive this home, the opportunity lighthouse identified is now officially a “passed audit”:

To measure this with real users & devices, last week we ran a simple A/B test on www.cloudflare.com where 50% of page views were optimised using Rocket Loader so we could compare performance with and without it enabled. As shown by the lighthouse audits above, our main website is a great use-case for Rocket Loader because while we do use a lot of JavaScript for some interactive aspects of our pages, most important to our visitors is reading information about Cloudflare’s network, products & features. So in short, content should be prioritised over JavaScript.

To illustrate the changes we observed, below is a graph of the Time To First Contentful Paint (TTFCP) for www.cloudflare.com visits by real users during our test. TTFCP measures the first time something in the Document Object Model (DOM) is painted on the page. For websites that are primarily for consumption of content rather than heavy interactions, this is a closer representation of a user’s perception of your website speed than measuring load time.

With Rocket Loader you can see those orange bars are grouped more to the left (faster) and higher meaning many more of our visitors were getting content on screen in under a second. In fact, the median improvement delivered by Rocket Loader during our www.cloudflare.com test lands at a 0.93 second reduction in Time To First Contentful paint or around a 45% improvement over the baseline. Boom!

So Rocket Loader continues to drive performance improvements on JavaScript heavy websites, but lots has changed under the hood. Here is a summary of the key changes:

• Improves time to first paint speed not just load time

• Now compatible with over 93% of mobile devices[1]

• Tiny! Less than 10% of the size of prior version

• Reduced complexity & better compatibility with your on-site & 3rd party JavaScripts

• Compliant with stricter Content Security Policies (CSP)

We’ve already predicted that by the end of 2018 mobile usage will reach 60%. Additionally as of July 2018 Google will begin using page speed in mobile search ranking. With that in mind providing a fast experience for mobile devices is more important than ever.

Rocket Loader beta was first launched back in 2012 at a time when mobile device usage on the web was around 15%. That version of Rocket Loader intercepted JavaScript on the page, and executed it in a virtual sandbox: a world familiar, but with behavior changed behind the scenes. Unfortunately, the technique we chose to create this virtual sandbox didn't work well on all mobile browsers. That was considered an undesirable but acceptable trade off 6 years ago, but today it’s vital customers can leverage this technique on mobile. Thanks to the reduced complexity of our approach, new Rocket Loader works on over 93%[1:1] of mobile devices in use today. For those devices that are not compatible, we simply deliver the website normally without this optimisation.

New Rocket Loader’s JS weighs in at a lightweight 2.3KB. We did some extensive refactoring during 2017 that reduced the size of the JS required to run Rocket Loader from 47KB to 32KB and saved a staggering 213 terabytes of transfer across the globe. Due to the simplicity of the way New Rocket Loader works rocket-loader.min.js resulting in a JS file that is less than 10% of the size, saving approximately another 417 Terabytes of transfer each year when Rocket Loader does its thing.[2]

New Rocket Loader does not modify the content of your JavaScript, it only changes the time at which it is loaded which means it plays nicely with any Content Security Policy (CSP) you have defined. With Rocket Loader beta, if you wanted to set a CSP that only allowed execution scripts hosted on your domain you would need to disable Rocket Loader as that would also combine & load external JavaScripts through your domain. New Rocket Loader does not use this approach and instead lets the browser load & cache the files normally. As we also enable HTTP/2 for all of our customers, any first party scripts will load over a single TCP connection, and 3rd party scripts are still asynchronously loaded meaning we can optimise their loading without proxying this content. All of this means modifying your CSP to accommodate Rocket Loader is as simple as allowing script-src for https://ajax.cloudflare.com so that Rocket Loader itself can load.

If you already have Rocket Loader enabled as of today your site is using the new version. You can modify your settings at any time by visiting the Speed section of your Cloudflare settings.

If you had Rocket Loader disabled or in Manual mode just click the button in the Speed section to turn Rocket Loader on.

As always achieving good performance typically takes a variety of approaches and Rocket Loader tackles JavaScript specifically. There are some other very simple optimisations you should also ensure are enabled:

• Caching - cache everything you can so content is served directly from any one of our 150+ data centres without waiting for your origin.

• Minify & Compress - Enable minification of your HTML, CSS & JS in your Speed settings to losslessly reduce the total byte size of your web pages and enable Brotli compression so browsers that support this new compression method receive smaller responses.

• Optimise your images - Polish will automatically reduce the size of images on your website with support for highly efficient formats such as WebP. You can also turn on Mirage to optimise images for mobile devices with poor connectivity.

• Use HTTP/2 - You get HTTP/2 support automatically as long as your site is served over HTTPS. Move as much as your content as you can onto your Cloudflare enabled URLs so all of that content can be multiplexed down a single TCP connection.

• Use Argo & Railgun - For dynamic content Argo and Railgun can help optimise the connection & transfer between Cloudflare and your origin server.

1. Rocket Loader utilises a browser API called document.currentScript which is currently supported by 93.7% of mobile devices and growing: https://caniuse.com/#feat=document-currentscript ↩︎ ↩︎

2. Back of the envelope calculations based on 270 million rocket-loader.min.js responses served per week with a 29.7KB saving per serving. ↩︎

Cycling image Photo by Dimon Blr on Unsplash.

Mirage and Rocket Loader both optimise the loading of a web page by reducing and deferring the number of assets the browser needs to request for it to complete HTML parsing and rendering on screen.

.has_images { overflow: auto; } @media (min-width: 600px) { .has_images p { float: left; width: 50%; } .has_images img { float: right; margin: 1em; width: 40% } }

With Mirage, users on slow mobile connections will be quickly shown a full page of content, using placeholder images with a low file-size which will load much faster. Without Mirage visitors on a slow mobile connection will have to wait a long time to download high-quality images. Since it’ll take a long time, they will perceive your website as slow:

With Mirage visitors will see content much faster, will thus perceive that the content is loading quickly, and will be less likely to give up:

Browsers will not show content that until all the Javascript that might affect it has been loaded and run. This can mean users wait a significant time before seeing any content at all, even if that content is the only reason they’re on visiting the page!

Rocket Loader transparently defers all Javascript execution until the rest of the page has loaded. This allows the browser to display the content the visitors are interested in as soon as possible.

Both of these products involve a two step process: first our optimizing proxy-server will rewrite customers’ HTML as it’s delivered, and then our on-page Javascript will attempt to optimise aspects of the page load. For instance, Mirage's server-side rewrites image tags as follows:

<!-- before -->
<img src="/some-image.png">

<!-- after -->
<img data-cfsrc="/some-image.png" style="display:none;visibility:hidden;">

Since browsers don't recognise data-cfsrc, the Mirage Javascript can control the whole process of loading these images. It uses this opportunity to intelligently load placeholder images on slow connections.

Rocket Loader uses a similar approach to de-prioritise Javascript during page load, allowing the browser to show visitors the content of the page sooner.

The Javascript for both products was written years ago, when ‘rollup’ brought to mind a poor lifestyle choice rather than an excellent build-tool. With the big changes we’ve seen in browsers, protocols, and JS, there were many opportunities to optimise.

Designed for the ecosystem of the time, both products were loaded by Cloudflare’s asynchronous-module-definition (AMD) loader, called CloudflareJS, which also bundled some shared libraries.

This meant the process of loading Mirage or Rocket Loader looked like:

1. CFJS inserted in blocking script tag by server-side rewriter

2. CFJS runs, and looks at some on-page config to decide at runtime whether to load Rocket/Mirage via AMD, inserting new script tags

3. Rocket/Mirage are loaded and run

Dynamic loading meant the products could not benefit from optimisations present in modern browsers. Browsers now scan HTML as they receive it instead of waiting for it all to arrive, identifying and loading external resources like script tags as quickly as possible. This process is called preload scanning, and is one of the most important optimisations performed by the brower. Since we used dynamic code inside CFJS to load Mirage and Rocket Loader, we were preventing them from benefitting from the preload scanner.

To make matters worse, Rocket Loader was being dynamically inserted using that villain of the DOM API, document.write - a technique that creates huge performance problems. Understanding exactly why is involved, so I’ve created a diagram. Skim it, and refer back to it as you read the next paragraph:

As said, using document.write to insert scripts is be particularly damaging to page load performance. Since the document.write that inserts the script is invisible to the preload scanner (even if the script is inline, which ours isn’t, preload scanning doesn’t even attempt to scan JS), at the instant it is inserted the browser will already be busy requesting resources the scanner found elsewhere in the page (other script tags, images etc). This matters because a browser encountering a non-deferred or asynchronous Javascript, like Rocket Loader, must block all further building of the DOM tree until that script is loaded and executed, to give the script a chance to modify the DOM. So Rocket Loader was being inserted at an instant in which it was going to be very slow to load, due to the backlog of requests from the preload scan, and therefore causes a very long delay until the DOM parser can resume!

Aside from this grave performance issue, it became more urgent to remove document.write when Chrome began to intervene against it in version 55 triggering a very interesting discussion. This intervention would sometimes prevent Rocket Loader from being inserted on slow 2G connections, stopping any other Javascript from loading at all!

Clearly, document.write needed to be extirpated!

CFJS was authored as a shared library for Cloudflare client-side code, including the original Cloudflare app store. This meant it had quite a large set of APIs. Although both Mirage and Rocket Loader depended on some of them, the overlap was actually small. Since we've launched the new, shiny Cloudflare Apps, CFJS had no other important products dependant upon it.

Before joining Cloudflare in July this year, I had been working in TypeScript, a language with all the lovely new syntax of modern Javascript. Taking over multiple AMD, ES5-based projects using Gulp and Grunt was a bit of a shock. I really thought I'd written my last define(['writing', 'very-bug'], function(twice, prone) {}), but here I was in 2017 seeing it again!

So it was very tempting to do a big-bang rewrite and get back to playing with the new ECMAScript 2018 toys. However, I’ve been involved in enough rewrites to know they’re very rarely justified, and instead identified the highest priority changes we’d need to improve performance (though I admit I wrote a few git checkout -b typescript-version branches to vent).

So, the plan was:

1. identify and inline the parts of CFJS used by Mirage and Rocket Loader

2. produce a new version of the other dependencies of CFJS (our logo badge widget is actually hardcoded to point at CloudflareJS)

3. switch from AMD to Rollup (and thus ECMAScript import syntax)

The decision to avoid making a new shared library may be surprising, especially as tree-shaking avoids some of the code-size overhead from unused parts of our dependencies. However, a little duplication seemed the lesser evil compared to cross-project dependencies given that:

• the overlap in code used was small

• over-general, library-style functions were part of why CFJS became too big in the first place

• Rocket Loader has some exciting things in its future...

Sweating kilobytes out of the minified + Gzipped Javascript files is be a waste of time for most applications. However, in the context of code that'll be run literally millions of times in the time you read this article, it really pays off. This is a process we’ll be continuing in 2018.

Switching out Gulp, Grunt and AMD was a fairly mechanical process of replacing syntax like this:

define(['cloudflare/iterator', 'cloudflare/dom'], function(iterator, dom) {
    // ...
    return {
        Mirage: Mirage,
    };
})

with ECMAScript modules, ready for Rollup, like:

import * as iterator from './iterator';
import { isHighLatency } from './connection';

// ...

export { Mirage }

Once the parts of CFJS used by the projects were inlined into the projects, we ended up with both Rocket and Mirage being slightly larger (all numbers minified + GZipped):

So we made a significant file-size saving (about half a jQuery’s worth) vs the original file-size required to completely load either product.

Before, our original insertion flow looked something like this:

// on page embed, injected into customers' pages
<script>
  var cloudflare = { rocket: true, mirage: true };
</script>
<script src="/cloudflare.min.js"></script>

Inside cloudflare.min.js we found the dynamic code that, once run, would kick off the requests for Mirage and Rocket Loader:

// cloudflare.min.js
if(cloudflare.rocket) {
    require(“cloudflare/rocket”);
}

Our approach is now far more browser friendly, roughly:

// on page embed
<script>
  var cloudflare = { /* some config */ }
</script>
<script src="/mirage.min.js"></script>
<script src="/rocket.min.js"></script>

If you compare the new insertion sequence diagram, you can see why this is so much better:

Theory implied our smaller, browser-friendly strategy should be faster, but only by doing some good old empirical research would we know for sure.

To measure the results, I set up a representative test page (including Bootstrap, custom fonts, some images, text) and calculated the change in the average Lighthouse performance scores out of 100 over a number of runs. The metrics I focussed on were:

1. Time till first meaningful paint (TTFMP) - FMP is when we first see some useful content, e.g. images and text

2. Overall - this is Lighthouse's aggregate score for a page - the closer to 100, the better

So, improved metrics across the board! We can see the changes have resulted in solid improvements, e.g a reduction in our average time till first meaningful paint of 694ms for Rocket, and 49ms for Mirage.

The optimisations to Mirage and Rocket Loader have resulted in less bandwidth use, and measurably better performance for visitors to Cloudflare optimised sites.

a:not([href]) { text-decoration: inherit !important; color: inherit !important; }

1. The following are back-of-the-envelope calculations. Mirage gets 980 million requests a week, TTFMP reduction of 50ms. There are 1000 ms in a second * 60 seconds * 60 minutes * 24 hours * 365 days = 31.5 billion milliseconds in a year. So (980e6 * 50 * 52) / 31.5e9 = in aggregate, 81 years less waiting for first-paint. Rocket gets 270 million requests a week, average TTFMP reduction of 694ms, (270e6 * 694 * 52) / 31.5e9 = in aggregate, 301 years less waiting for first-meaningful-paint. Similarly 980 million savings of 16kb per week for Mirage = 817.60 terabytes per year and 270 million savings of 15.2kb per week for Rocket Loader = 213.79 terabytes per year for a combined total of 1031 terabytes or 1.031 petabytes.

2. and a tiny 1.5KB file for our web badge - written in TypeScript ? - which previously was loaded on top of the 21.6KB CFJS

3. shut it Hume

4. Thanks to Peter Belesis for doing the initial work of identifying which products depended upon CloudflareJS, and Peter, Matthew Cottingham, Andrew Galloni, Henry Heinemann, Simon Moore and Ivan Nikulin for their wise counsel on this blog post.

Even though CloudFlare offsets most of the load to your website via caching and request filtering, a certain amount of traffic will still pass through to your host. Knowing the limits of your plan can help prevent a bottleneck from your hosting plan.

CloudFlare allows you to block IP address individually or IPs from entire regions. If you don’t want or need traffic from certain IPs or regions, you can block them using your Threat Control panel. This is useful for sites who know where their visitors usually come from.

Take action to prevent attacks to your site during peak season by configuring your firewall to only accept traffic from CloudFlare IP addresses during the holidays. If you only accept CloudFlare IPs, you can prevent attackers from getting to your original IP address and knocking your site offline.

CloudFlare operates as a reverse proxy to your site so all connections come from CloudFlare IPs, so restricting our IPs can cause issues for visitors trying to access your site. The list of our IP can be found here: https://www.cloudflare.com/ips

By default CloudFlare caches static content with our CDN; however, you can extend our caching by creating custom Page Rules. Under the Page Rules section of your account, you can set a pattern--either your entire website, or a section of your site--then turn on the “Cache everything” option. Creating a page rule and setting the Cache Everything option helps reduce the number of times CloudFlare has to hit your origin to download cacheable items.

Setting up a custom Page Rule like this is ideal if you have a campaign going on over the holiday season. With the Cache Everything option enabled, CloudFlare will be serving your entire site, taking the load off of your server completely, making you site as fast as possible.

Edge Cache Expire TTL and the Browser Cache Expire TTL allows you to determine how long we cache resources at our edge, and how long browsers will cache assets.

To ensure visitor’s IPs show in your back-end server logs you can install mod_cloudflare to restore original visitor IP back to server logs. Our IP addresses will show up in your logs unless you install the modification to make sure you are logging the visitors’ actual IP addresses.

Auto Minification is a method that helps your site send as little information as possible to increase performance. It works by taking JavaScript, CSS, and HTML and removing all comments and white spaces.

Rocket Loader is an asynchronous JavaScript loader. It ensures that individual scripts on your page won’t block other content from loading, loads third party scripts in the order they are ready, and bundles all script into a single request so multiple responses can be streamed---in short, it makes your page render much faster on any device.

At a high level, Rocket Loader works like this:

(Available for Pro, Business, and Enterprise plans)Mirage will determine which images are visible to the end user and send those first, then other images that are off the screen will be lazy loaded as needed. This feature is especially useful for sites that with many images like most ecommerce sites

For example: if your sites has a images of seventy different t-shirts for sale, rather than having the customer wait for all seventy images to load, Mirage quickly delivers the images immediately visible to the user, then loads the rest of the images as the customer scrolls down. By having the most important images load lightning fast, the end user’s experience is improved.

(Available for Pro, Business, and Enterprise plans)Polish recompresses images to make them as small as possible in order to increase site performance.

For example: You may have images on your site that are not optimally compressed. When CloudFlare puts those images into cache it will automatically recompress them making them smaller, and allowing them to be loaded as quickly as possible. CloudFlare can compress images in a lossless or lossy way.

If you want to make quick changes to your page and have your visitors see that change immediately, you can purge individual files from CloudFlare’s cache.

For example, if you are running a sale only for Black Friday, and you want new content displayed to your visitors, you can purge a single page so that CloudFlare will return to your origin server to fetch a new version of that page for our cache.

Please Note: if you purge your entire cache your origin will receive a flood of traffic until CloudFlare get all of your assets back into our cache.

Even if you don’t implement any of the suggestions above you are still ahead of the game by being on CloudFlare’s network. Since we have 28 data centers around the world, we bring your site close to your visitors. And since we run an Anycast network, visitors are automatically directed to the closest data center meaning that your site will be faster as the request travels over a shorter distance.

We wish you all the best this holiday season! Good luck!

We get asked this question all the time: How do I make my website faster? So, on Thursday, we're holding a webcast to go through our recommendations and also answer your questions live.

We'll discuss:

• the basics of getting set up for speed

• what to cache and why

• image optimization and virtualization techniques (Polish and Mirage)

• JavaScript optimization (Rocket Loader)

This session is geared toward website owners who want to understand the basics of performance on CloudFlare and who may have no prior knowledge of our service. CloudFlare makes your websites faster, safer and smarter. Join us on Thursday, December 12 from 10 to 10:30am Pacific (18:00 to 18:30pm UTC) and we'll show you how simple it is to go faster. Register here.

The incident raises two good points: 1) the risk of Javascript widgets creating a "single points of failure" on your web page; and 2) the ways in which CloudFlare can help protect you from similar errors.

Facebook Connect works as a piece of Javascript that is embeded on pages. When the bug occurred, the Javascript effectively hijacked the page and directed it somewhere else. It may seem like installing a widget such as the Facebook button is harmless, but today's incident shows how much harm it can actually cause.

Björn Kaiser wrote a great blog post last year about the risks that embedded Javascript widgets can create, and how their failure can create a single point of failure (SPOF) on your site. In the post, he describes how you can test the embedded widgets on your page to see what would happen if any of them fail. Given that no widget provider, even Facebook, is infallible it is important to understand the risk of widget failure bringing down your site.

There are two distinct ways in which CloudFlare helps protect you from Javascript widgets taking down your site. The first is via our Rocket Loader feature.

While we don't describe it this way often, Rocket Loader is effectively an on-page Javascript optimizer. It sits in front of widgets and makes sure they load as fast as possible. It also has a number of failsafes that can protect from any widget hijacking your site the way Facebook's Connect service did today. While we primarily describe Rocket Loader as a performance feature, in this role it's also very helpful for security and site availability.

The second way we protect sites from misbehaving Javascript widgets is through CloudFlare's app store. Many CloudFlare apps are Javascript widgets of one kind or another. When you install any CloudFlare app, we go through the process of making sure that the app performs well and can run asychronously. This greatly reduces the risk of an CloudFlare-installed app becoming a SPOF. Moreover, because we can install, upgrade, and remove apps centrally, if a problem likeFacebook's had occurred with one of the CloudFlare apps, we could quickly remove it from pages to keep it from causing harm.

Today's Facebook incident shows the risks of misbehaving Javascript widgets, but it also helps drive home the point on how CloudFlare is really building a better web. To that end, we will continue to invest in improving Rocket Loader and adding more and more apps to the CloudFlare Apps Marketplace. If you haven't turned on Rocket Loader or added an app through the CloudFlare Apps Marketplace, you now have one more reason check them both out.

There were two talks: I was preceded by designer Laura Kalbag who talked about designing icons for WordPress sites. This is something that she made look incredibly easy using a tool called Sketch. I suspect that however good Sketch is, I'd end up drawing icons that looked awful!

My talk was about using WordPress and CloudFlare together. CloudFlare has a ton of features and I highlighted some that are of great interest to WordPress users including the CloudFlare WordPress Plugin and our integration with W3TC.

The other features that people found most interesting were:

1. Always Online: CloudFlare crawls the WordPress site and keeps a copy in a special cache. If the original site goes down CloudFlare serves up the most recent version from the crawler cache with a banner indicating that it is old content. This helps keep sites online when things go badly wrong.

2. Auto-minify: many WordPress sites have large amount of HTML, CSS, and JavaScript (especially if they use lots of plugins). Auto-minify helps shrink those resources so that sites are delivered faster to web browsers.

3. Rocket Loader: a tool that reorganizes the loading of resources such as CSS and JavaScript to that they are downloaded to web browsers quickly by bundling them.

4. A new, unannounced feature that I'm calling "Help, I've gone viral!" which allows any web site owner to instantly tell CloudFlare to start completely caching a URL (overriding any caching headers set by the site) to cope with load. With this if a URL goes viral and is overloading a WordPress site it's possible to just paste in its URL and ask CloudFlare to take the load of that page. We'll be writing more about that feature when it's released.

And, of course, other CloudFlare features like Easy SSL, SPDY, and IPv6 help everyone get the latest technology onto their site quickly.

In announcing the award, the WSJ specifically called out three technologies we launched over the last year: Rocket Loader, Railgun, and the Automatic IPv6 Gateway.

Rocket Loader helps ensure that scripts and other resources don't slow down page load times. Too often, third party scripts like buttons, widgets, and ads can block a page from loading. These problems are exacerbated on mobile devices. Since mobile bandwidth is limited, and connections are fickle, needing to open connections to multiple third party services can seriously degrade mobile performance.

Rocket Loader's innovative approach fetches multiple third party objects through a single connection to CloudFlare's network. Instead of needing to open new requests to each service, a device only needs to establish a single connection to CloudFlare's network. Our servers, which do not have the same constraints, can then open connections to all the services needed to download the objects. The net result is pages load faster and aren't blocked if an ad or Twitter button fails to load quickly.

Rocket Loader is available to all CloudFlare customers for free. We've found it often improves page load performance an additional 30% over the other benefits delivered by CloudFlare's systems, with the biggest performance gains seen on mobile devices.

The caching model for the Internet is based on files. CloudFlare caches static files (images, CSS, Javascript) at our edge and, in doing so, saves approximately 70% of the average websites' bandwidth and requests. While CloudFlare works well with dynamic content, since the file changes it is impossible for it to be cached.

CloudFlare spent a year studying the properties of the dynamic web. In the process, we realized that while many sites are dynamic, the amount they actually change is very small: less than 5% every 24 hours. Railgun changes the caching model of the Internet to allow only the portions of a file that have changed to be sent across the network.

Railgun was inspired by CloudFlare's continued expansion of data centers. As CloudFlare's network grew to include 23 data centers, the latency from a browser to our network shrank. However, the latency from our network back to our customers' web servers grew. Business and Enterprise customers, as well as customers on CloudFlare Optimized Hosting Partners, can use Railgun to achieve a 99.6% compression ratio when sending data to our network. That means what used to take 200 packets can now be sent in a single packet and, more practically, even highly dynamic sites can, for the first time, be as fast as if the data center were next door regardless of where a visitor is surfing from.

One of the most vexing challenges the Internet faces is the move from IPv4 to IPv6. The IPv4 protocol was designed to only accommodate approximately 4 billion devices simultaneously connected to the network at any given time. As we close in on this theoretical limit we are literally running out of addresses. While it's hard to imagine, that means the seemingly limitless Internet is running out of space.

The solution is a new protocol — IPv6 — which can support a vastly larger number of connected devices. Unfortunately, IPv6 networks cannot interoperate with IPv4 networks meaning the Internet has been faced with a giant chicken-or-egg problem. Web surfers are reluctant to upgrade to IPv6 because there's no IPv6 web content, and web publishers are reluctant to switch because there are not IPv6 web surfers.

CloudFlare realized we could help solve this problem by providing our Automatic IPv6 Gateway. The free service allows anyone to maintain their existing IPv4 infrastructure and be available on the IPv6 web just by signing up for CloudFlare. While that is great for existing customers, the bigger opportunity is actually with new entrants to the Internet. As it becomes more expensive to launch an IPv4 infrastructure, CloudFlare will allow new Internet publishers to put their content on IPv6 but still reach legacy IPv4 surfers.

CloudFlare's Automatic IPv6 Gateway was so successful that CloudFlare doubled the number of IPv6 websites available the day we launched the product. Today, CloudFlare provides IPv6 connectivity to more websites than any other provider.

CloudFlare's team comes to work every day excited to invent the future of the Internet. Our goal is nothing short of rebuilding a faster, safer, smarter web. We are honored to be recognized by the Wall Street Journal for the second year in a row as one of the world's most innovative companies. And we're hard at work on the next technologies in our continuing efforts to build a better Internet.

You can read more about CloudFlare's award on the Wall Street Journal's website.

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.

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.

CloudFlare has partnered with a number of CloudFlare Certified Partners to make it simple for website owners that want a faster and safer website. Since signing up for CloudFlare through a hosting partner is different than signing up for CloudFlare directly, we wanted to provide some quick tips to help you get the most out of your CloudFlare experience.

1. You do not need to change your name servers when activating through a hosting partner. You would still manage your DNS entries at your hosting provider or registrar.

2. CloudFlare can only be enabled for CNAME records when activating through a hosting partner. To enable CloudFlare on your root domain (yourdomain.com), which is an A record, you need to have your hosting partner set a 301 redirect from your root domain to www. Not only will the redirect help accelerate and protect the root domain, this will also make the statistics in your CloudFlare account accurate. Note: If you have a naked domain, 'yourdomain.com', and you don't want your visitors to go to 'www.yourdomain.com', then you need to signup directly with CloudFlare.

3. What you should do if you see any of the following error messages after enabling CloudFlare:

"Host Not Configured to Serve Web Traffic" error message will appear on the first request to your site after activating through a partner, then will go away after a few minutes. If it lasts for more than 10 minutes,then contact your hosting provider and our support teams will work together to resolve.

"CloudFlare-nginx 502 Bad Gateway": This is an issue on the CloudFlare network. We deal with these quickly (less than 10 minutes). We publish all announcements regarding our network status on @CloudFlareSys.

"Website is Unavailable": Either your server is offline and we don't have a copy of your site in cache or something on the origin server is blocking CloudFlare's IPs.

If your server is online, then work with your hosting provider to find out what could be blocking CloudFlare's IPs on your server. The most common culprit is a security solution like a firewall like CSF or IP tables. As soon as the block is removed, the error page will disappear.

SSLIf you have SSL on the domain(s), you will need to upgrade to a Pro account. The cost for a Pro account is $20.00 per month for the first website and $5.00 for each additional site. In addition to the SSL support, you will also receive additional security and performance benefits.

Note: You will find the option to upgrade to Pro in your CloudFlare account.

Development ModeIf you are making changes to the static content on your website, temporarily bypass CloudFlare's cache so any changes appear immediately. You can find Development Mode either right in your hosting provider's control panel or by logging in to your CloudFlare account under CloudFlare Settings.

PageRulesPageRules gives you more powerful performance and configuration options, including:Advanced Caching ConfigurationsExcluding URLS from CloudFlare's default caching and security optionsSetting URL forwards and redirects

CloudFlare has developed web content optimization features called Rocket Loader and Auto Minify. Both Rocket Loader and Auto Minify are designed to load your site's resources even faster than the default CloudFlare configuration.

Rocket LoaderRocket Loader will speed up the delivery of your pages by automatically asynchronously loading your JavaScript resources. Rocket Loader works well for websites that have a lot of ads, widgets or plugins.

Auto MinifyRemoves all unnecessary characters from HTML, CSS, and JavaScript to reduce file size.

Note: Both of these features are still in beta. If you encounter any issues, such as a broken plugin or JavaScript not working properly, then please turn the feature off and report any bugs to our team.

To turn on Rocket Loader and Auto Minify, you need to log in to your CloudFlare account and go to CloudFlare Settings.

IPv6 GatewayMake your website IPv6 compatible, by turning on the CloudFlare IPv6 gateway.

The CloudFlare Support Center has answers to a number of questions. Searching our knowledge base is the fastest way to get a quick response to the majority of questions. Don't see the answer to your question? Please contact CloudFlare.

We frequently post about product updates, early beta access to new features, system issues, and giveaways, so we recommend that you follow us on Facebook, Twitter or Google+:

• Facebook

• Twitter

• Google+

Thank you for joining CloudFlare in partnership with your hosting provider.

This problem is magnified on mobile devices. Your smart phone can stream video from YouTube without stuttering, because it is a single HTTP connection, but it often falters on seemingly simple web pages, because they are made up of a number of separate objects that need to all be loaded through their own HTTP requests. Mobile networks have reasonable bandwidth once a connection is established, but each new connection has a probability of failing that can block page loading.

Combining Javascript and CSS seems like a sensible solution, but it runs into multiple problems:

• Combined Javascript or CSS can clobber the namespace of other scripts and create unpredictable bugs.

• Combined Javascript or CSS can become large and unwieldy with all code that is needed site-wide leading to a slow initial-load time.

• One change to any part of the combined Javascript and CSS file invalidates the whole file in the browser's cache and requires a slow re-download.

• Combined files can lose the benefits of cross-site Javascript CDNs (like CDNJS.com) which effectively pre-load common scripts into the visitor's cache before they arrive at your site.

• It can be difficult or impossible to combine third party scripts like those used for things like Google AdSense, Facebook's Like Button, or the Twitter Follow Button.

At CloudFlare, we decided that while the goal of reducing the number of HTTP requests was important for improving web performance, there had to be a better way than naively concatenating Javascript and CSS.

CloudFlare's approach to reducing HTTP requests is revolutionary. Dubbed "Rocket Loader," the system automatically detects tags that would require a new HTTP request. Instead of combining the files and leading to the issues above, Rocket Loader instead focuses on combining what really matters for performance: requests.

Just as YouTube opens a single HTTP connection and then streams down the video, Rocket Loader opens a single HTTP connection to CloudFlare's network and then streams the individual files through one request. The benefit is that, while there's only one request, the files remain atomic. As a result, unpredictable bugs are avoided, the browser can cache files locally and not re-request them, if one file changes it doesn't invalidate all the sites' other scripts, and it works as well with your own scripts as it does for third party scripts like AdSense and Facebook.

The net effect is you get the benefits of HTTP request reduction without the downsides of file combination. What does that translate into? Usually another 20% performance benefit on top of what CloudFlare already delivered, and even more for mobile devices.

CloudFlare allows you to have full control over how Rocket Loader is enabled. You can choose Manual mode, in which case you need to mark the scripts you want to be combined on the page. You do this by adding cf-async="true" as the first attribute in the script tag:

\

Alternatively, you can have CloudFlare automatically apply Rocket Loader to all the resources on your page. In this case, if there's one resource that you don't want to be loaded via Rocket Loader, you can exclude it by adding cf-async="false" as the first attribute in the script tag:

\]

Rocket Loader is a great example of technology that CloudFlare has developed to solve a real problem the right way rather than sheepishly following the conventional wisdom. Rocket Loader leverages CloudFlare's global CDN platform in order to get the best possible performance for our users. We have big plans on how to expand Rocket Loader and help reduce the number of HTTP requests even more. Because it makes such a difference in web performance, we include Rocket Loader for free for every CloudFlare website. You can activate it from your CloudFlare Settings page with a single click, or learn more about all the ways CloudFlare can help optimizes your site.

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.

Yesterday our CEO and co-founder, Matthew Prince, dropped in on TechCrunch Disrupt in NYC to give an update on CloudFlare and to make a few announcements. CloudFlare couldn't have been more excited to present at TechCrunch Disrupt and debut our CloudFlare Apps and Rocket Loader services. You can tell by watching Matthew's presentation that we've been busy.

We've also received some great media clips, including articles from TechCrunch and Robert Scoble - complete with a video of Matthew and Michelle explaining CloudFlare Apps and Rocket Loader.

Thanks to all our customers for the tweets, likes, comments, and overall CloudFlare love you've been spreading.

In appreciation of our users, we're sending out CloudFlare t-shirts this week. If you'd like us to send you one, please send us an email to support@cloudflare.com with "t-shirt" in the subject - be sure to include your name, address and shirt size.