We've been optimizing the performance and caching of this one little piece of JS for 4 years. You might appreciate a bit of an explanation as to what exactly each segment of the JS is doing. So here's that code:
And now, the explanation:
- 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 questions about the code we recently got and will be working to fill in:
- Is ethnio code confined to one global variable, so that there are no libraries cluttering your global namespace?
Working on this
- 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 naively inserting a script tag?
Uh oh, I think we might just naively insert a script tag. Also checking.
Let's Talk Performance
We use all the industry-standard monitoring and optimization tools you're probably familiar with - New Relic, Pingdom, 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 RubyOnRails 4.2.3 on Ruby 2.12 on Nginx and Unicorn with PostgreSQL and Redis. We use Rails caching based on Redis to show screeners, and below are some examples of the performance tracking: