31

CloudFlare has quite a ground-breaking technology called Rocket Loader (both on free and paid accounts). But how does it actually work?

They have a couple of pages that describe the technology, but not a lot of technical details. One key feature is that it makes all Javascript load in a non-blocking fashion (asynchronously), which is quite an incredible feat! This means the HTML/CSS can be rendered without waiting for scripts to load and run.

CloudFlare Rocket Loader diagram

How is that possible?

Surely it cannot simply change all <script> tags to use async="true" or defer="true" as this would break several things...

  1. Scripts still need to load in the correct order (for example, you can't load jQuery plugins until the jQuery library has loaded.)
  2. document.write() calls in these scripts need to function (apparently these do nothing in typical async scripts).
  3. What about the DOMContentLoaded event? If some scripts get loaded after this has triggered, do their event-handlers go untriggered?

And as a developer, is there anything else I need to be aware of to ensure my sites/scripts/plugins remain compatible with Rocket Loader?

27

CloudFlare describes Rocket Loader like this...

Rocket Loader is a general-purpose asynchronous JavaScript loader coupled with a lightweight virtual browser which can safely run any JavaScript code after window.onload.

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.

So that's pretty cool, but how does it achieve it?

From what I've read and discovered from running CloudFlare + Rocket Loader on my own site, it works roughly like this...

  1. When a HTML page is requested from a CloudFlare server, after loading it from the origin web host, it rewrites all script tags into <script type="text/rocketscript">

  2. Browsers naturally ignore the script tags as they don't understand the format "text/rocketscript"

  3. CloudFlare also injects an additional cloudflare.min.js script into the page which performs the magic (see formatted version here). This is the only script initially loaded by the browser (asynchronously).

  4. This script parses the page for any scripts with the type "text/rocketscript".

  5. It then checks if any of these scripts already exist in the browser's local storage. If not, it then makes an AJAX request for them (combined in logical bundles) from the CloudFlare CDN. I'm not quite sure how it works out how to group the scripts together.

  6. The CDN servers gather the scripts (which may come from several different servers: Google, Twitter, Facebook, other CDNs etc.), either from their cache, or from the origin servers, and then combine, minify and GZIP them before sending them back to the browser.

  7. This virtual browser thing that they refer to must simply be some JavaScript that then runs each of these scripts in the right order, doing such things as:

    • Catching all calls to document.write() and injecting that content into the correct location on the page. (Possibly by overwriting the browser's write() function with a custom one?)
    • Retriggering events such as DOMContentLoaded and load.

I'm actually quite shocked that it works (although perhaps it doesn't always). But under normal circumstances, I don't think developers need to do anything special to make their JavaScript compatible.

This is a community wiki, so please edit and add any additional detail that is missing.

  • 2
    As noted above, this can result in issues and consequently might need to be disabled, so test prior to deploying. – dan Apr 4 '14 at 23:54
  • The virtual browser possibly is a shadow DOM like the ones used by modern frameworks like Backbone, Angular, Ember, Knockout, etc. – kaiser Jan 14 '15 at 22:57
  • 3
    If we go to any cloudfare enabled page which has this rocketscript thing enabled, we can see in the console that document.write is indeed been mutated. I get function (b,d,e,g,h){if(u.getActivated())return c.apply(f,arguments);try{return j[a].apply(f,arguments)}catch(i){return j[a](b,d,e,g,h)}} as the string value. So the hypothesis that document.write has be overwritten is indeed correct. – user3459110 Dec 1 '15 at 14:15
  • Italian translation of the above post, if anyone is intrested: klayz.com/community/… – Glauco Zega Jan 2 '16 at 15:04
  • 5
    One thing I have noticed is that rocket loader uses document.write. Since Chrome 53, DevTools issues warnings for problematic document.write() statements and this use of it triggers a warning. In fact, CloudFlare's use of document.write() would be blocked by Chrome 53 + on a 2G connection. See Chrome Developers for more info developers.google.com/web/updates/2016/08/… – davemac Oct 24 '16 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.