You have about 2 seconds before your application starts feeling slow to your visitors. This comfortable 2 seconds is your latency budget. We'll look at three things that leech this precious time: the armour of TLS, JavaScript Pixies, and the Speed of Light itself. After that, we'll share the dream of speedy user experiences for everyone around the world.

If you're sending data across the Internet, it's unprotected unless it's encapsulated within Transport Layer Security (TLS). TLS enables HTTPS and HTTPS prevents eyes from peering into traffic-in-motion. The armour-y goodness of HTTPS comes at a cost: a visitor's first connection must complete a three-trip encryption handshake.

The dance plays out like this:

The visitor says clientHello then proposes a cryptographic method, or CipherSuite, to use with the server. →

The server responds with serverHello, agrees on a CipherSuite, presents a public key tied to its private key then sends it to the client. ←

The client receives the public key from the server, then encrypts and delivers its secret key information to the server using that public key. →

The client notifies the server that it is finished. →

The server agrees with the client that it, too, is finished. ←

Advancements within HTTP/2 and the TLS protocol reduce this handshake by one trip and remove it entirely for repeat visitors. However, HTTP/2 and TLS 1.3 are not yet ubiquitous and even with two trips the back-and-forth can be an issue depending on distance. We'll touch more upon the limitations of time and space further on...

The Pixies are not to be trusted! They are tricksters; with beautiful landing pages and sublime marketing promises they'll tell you: "Just put a wee' snippet here and wield powerful features!"

Now you have a handful of robust analytical widgets super-charged with heat-maps, full-session play-back, buttons, trinkets, doo-dads, whirlyjigs -- everything you can ever dream of -- and you didn't have to code any of it! But you've been tricked.

When you take JavaScript from someone else and plunk it in your pages you've given the third-party the power of arbitrary code execution.

The third-party can...

This is a spooky reality:

If your application uses third-party JavaScript, it is no more secure than the third-party.

Turning to performance, depending on how you have installed the JavaScript you may experience issues rendering your pages due to blocking. If there is an issue and the JavaScript is unable to render, then your other site scripts will not load -- your code has been blocked!

Even if you've placed all of your JavaScript at the bottom of your HTML files and have set each snippet to be asynchronous, you are still susceptible to window.onload being blocked until the snippet load has completed.

The last straw: whether the code is optimized is far out of your hands. If the code isn't minified, concatenated, or well-written then you're out of luck.

Your server may still run HTTP/1.X. If the JavaScript references external assets that are hosted elsewhere, each connection outwards requires DNS resolution and a TLS handshake -- if it's secured. Your browser will limit the number of connections you can make outwards to 6 on average; if the JavaScript is chatty it could saturate all available TCP connections, which is blocking of a different sort.

Third-Party JavaScript Pixies... With their tongues of honey and promises of stars and moons, they appear as friends. When you dig deeper, you realize the depths of their fiendish nature. While there are exemplary implementations that are coded well, secure, and made by trust worthy folks, those are few and far between. Beware!

One must empathize with light; to blaze through air at a blistering 299,700 km/s and have fleshy meatbags call you slow. But it's the truth! The speed of light is a limitation on the speed of your applications. Data can travel no faster than the speed of light.

The distance from Australia to Vancouver is 13,192km. If you're travelling by passenger airplane at about 600km/h it would take you 18h25m to go one way or 36h50m for a round-trip. If you're a photon of light zooming at 299,700 km/s, a one-way trip takes 44.0038 milliseconds, the round-trip taking 88.0076 milliseconds.

Our minds cannot comprehend this speed but they sure can comprehend the drudgery of a slow web-page. Returning to the Armour of TLS; if we have three round-trips in our handshake, that means TLS has a theoretical optimal speed of 264.0228ms between Vancouver and Australia.

If we declare a latency budget of 2 seconds to deliver a fast and comfortable user experience, you're left with - at most - 1,735.9772 ms to generate your application! Now consider congestion, JavaScript devilry, your own inevitible bugs, suboptimal connections...

Fly exists to solve these problems; provide safer and faster HTTPS over HTTP/2 around the globe and beat-back the rampant ascension of leaky and dangerous JavaScript.

When you connect an application to Fly, you connect to a global Application Delivery Network. You weave all of your applications, services, and backends that are hosted in one place through edge-servers spread around the globe.

Each edge-server provides HTTP/2 and shortens the distance required to facilitate a TLS handshake. One less trip and shorter trips leaves more time available in your latency budget for your application. As for the speed of light, well... you can either double the speed of light or half the distance you need to travel. We chose the latter option, the limits of physics abiding earthbound mortals, and so forth.

Now to dastardly JavaScript; the problems we exposed are such because the code rendering has been off-loaded to the client. Each user's browser is responsible for chewing the JavaScript, thus exposing each individual. In order to fix this problem, we assert that the logic should move from the client to the edge-network.

Each edge-server is a reverse-proxy fluent in application logic. Given the relative restrictions within a proxy, the type of code that can be ran and the information the code has access to is much more limited. The attack vector is not as exposed as the browser client and everything is isolated within one site, instead of forked off into dozens hiding behind the scripts.

We've started moving popular JavaScript services onto the edge. We've shipped pre-packed components like Google Analytics as Middleware to provide a safe way of receiving analytics data that won't put your site or your users at risk. Within Fly, one can also use AWS Lambda as Middleware to invoke JavaScript functions within the request/response cycle instead of on the client. You can write Lambda on the request, response, or out-of-band.

Fly ensures that you start with as much room as possible in your latency budget after your users connect from anywhere in the globe. It'll also keep dastardly JavaScript Pixies from bogging things down and bringing risk to your clients.

Fly is a platform that helps you build and launch dynamic applications to users around the world. You can pack all of your things on One Hostname, plug-in powerful, and serve your pages at blazing speeds from a global HTTP/2 and HTTPS network!

Fly started when we wondered "what would a programmable edge look like"? Developer workflows work great for infrastructure like CDNs and optimization services. You should really see for yourself, though.