From 5fbd58b807f20b540e462095e93d805ca63beb7b Mon Sep 17 00:00:00 2001 From: Luke Childs Date: Sun, 25 Sep 2016 17:40:36 +0100 Subject: [PATCH] Add performance section --- README.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/README.md b/README.md index 1cd25ae..06bc323 100644 --- a/README.md +++ b/README.md @@ -47,3 +47,11 @@ If the browser supports service workers a service worker will silently cache all These three enhancements really compliment each other and allow for a very native app like experience that even works offline for modern devices. + +## Performance + +The fact that all assets beyond HTML and CSS are loaded asynchronously means that the browser can crack on with rendering the page without waiting for anything it doesn't need right away to load. All HTML, CSS and JavaScript is also aggressively minified and then compressed with gzip to squeeze every last byte out. + +In the enhancement JavaScript, as much work as possible is outside of the DOM ready event handler. This means even if the DOM isn't ready yet, we get as much work as possible out of the way so that when the DOM is ready we can inject the enhancement elements as soon as possible. This helps to reduce jitter as the elements are added after load making the website appear less laggy. + +All information is provided by the [Onionoo](https://onionoo.torproject.org/) API. I've written a simple node API client as a separate reusable module ([onionoo-node-client](https://github.com/lukechilds/onionoo-node-client)). It caches the API responses in memory (respecting Onionoo's `Cache-Control` headers) meaning that once the cache has warmed up the server responds very quickly. It also takes a bit of load off the Oninoo API server. Atlas makes all API requests clientside, meaning a large number of users will result in heavy traffic to Onionoo.