Browse Source

Add performance section

pm2
Luke Childs 8 years ago
parent
commit
5fbd58b807
  1. 8
      README.md

8
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. These three enhancements really compliment each other and allow for a very native app like experience that even works offline for modern devices.
<img width="2160" src="http://i.imgur.com/Ltkf40H.jpg" /> <img width="2160" src="http://i.imgur.com/Ltkf40H.jpg" />
## 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.

Loading…
Cancel
Save