Intercept Performance & Stability

We've been optimizing the performance, stability, and caching of this one little piece of JavaScript for five years. With a current load of 800 million pageviews per month and up to 30,000 requests per seconds, our JS has been implemented in many of the largest sites and apps in the world, from Asana to Wikipedia. You might appreciate a bit of an explanation as to what exactly each segment of the JS is doing. So here's that code:

<em><script type="text/javascript" language="javascript" src="//ethn.io/xxxxx.js" async="true" charset="utf-8"> </script></em>

And now, the explanation:

type="text/javascript" - This tells the server what kind of code this is. In this case, it is Javascript.
language="javascript" - Another way of telling the server that this is Javascript, but is recognized by older browsers. We use them both to make sure that everyone sees the Ethnio code properly.
src="//ethn.io/xxxxx.js" - a few things here. the "//" allow the code to dynamically detect if it's been placed on an HTTPS or regular HTTP page. the xxxxx.js part uses a dynamic and cached .js file to keep up maximum performance on our end.
async="true" - This just tells the browser to load everything else before it loads the Ethnio code.
charset="utf-8" - Character set encoding so that all languages display properly.

Here are some common technical questions and answers:

Is ethnio code confined to one global variable, so that there are no libraries cluttering your global namespace?
Yes, ethnio code is confined to one global "Ethnio" variable
Does ethnio wait to load until the page has fully rendered; so it doesn't hang your site if the servers are down.
Indeed we do. That's the async="true" part.
Does ethnio dynamically create a script tag after the onLoad event fires, instead of natively inserting a script tag?
No we don't dynamically create a script tag. We create an iFrame tag if the respondent clicks the next button.

Let's Talk Performance

We use all the industry-standard monitoring and optimization tools you're probably familiar with - New Relic, Munin, and Monit. Uptime stats are maintained off-domain here and go back years and years at roughly 99.87% uptime.

Size can differ a bit, but is usually between 10-15kb. Average server response time for screeners is about 8ms. This time only shows how fast our servers process requests and give responses. Transfer time to and from your servers can differ depending on just about a million variables.

We run Rails 5.2.8 with Ruby 2.7.4, and use Rails caching based on Redis to show screeners, and below are some examples of the performance tracking: