LATEST AWESOMNESS

Safari Leaves Chrome and Firefox in the Dust Loading Editor!

When you open Animatron Editor at editor.animatron.com you are navigating directly to Cloudfront - Amazon Content Delivery Network (CDN).

Just in case you were living in a cave and don’t know what CDN is, here is how Amazon describes it:

Amazon CloudFront is a web service that gives businesses and web application developers an easy and cost effective way to distribute content with low latency and high data transfer speeds.

In other words, it is a way to make static content load quickly anywhere in the world. Animatron Editor is a javascript application – it is essentially static content – so it is a perfect candidate for distribution via a CDN.

Total size of the editor (gzipped minified javascript code) is about 1.4Mb. As you can imagine it could take quite some time to load. We are concerned about our application’s load time, and want to minimize it as much as possible. The faster it loads, the better the User eXperience – the end goal we always have in mind.

But before we could do any optimizations for Animatron Editor, we need some data to work with, which in our case meant we needed to collect and analyze our load times.

naive My first naive attempt was to measure the time between the loading of the index page and the end of the app initialization. Unfortunately, this is not the most accurate measurement. It does not account for things like DNS resolution, loading of the first page, and javascript parsing and execution. It gives us some numbers, but it’s not exactly what the user experiences.
happy After looking around, I found there is a web standard API that allows you to make all kinds of accurate measurements. It is called Navigation Timing, and the best part is that it is supported by all modern browsers.

So, if you want to measure the exact time from just before an user navigates to your page to now, all you need is the following piece of javascript:

1
2
// time interval in milliseconds from start of the navigation until now
var time = new Date().getTime() - window.performance.timing.navigationStart;

There are other interesting metrics available, but I needed only one: total time until full initialization of the Animatron Editor.

Once we started collecting Editor startup times, we needed to store the numbers somewhere, so we could analyze and chart it down the road. Our analytics software supports events collection, the easiest way to work the numbers. At Animatron, we use Mixpanel, which lets you process events with any parameters and run sophisticated queries against the data.

Here is the startup time-tracking code for Mixpanel:

1
2
3
// "Startup Time" - name of event
// {"total": time} - parameters
window.mixpanel.track("Startup Time", {"total": time});

After it is set up and deployed, wait a week or two for the data to be collected.

Here is screenshot from Mixpanel view of Animatron data we collected over a two months period. Here is the formula we ran: we take our event and plot parameter total, and then throw away intervals of more than 200 seconds (clearly anomalies). Then, we average the time and segment it by type of browser.

Y axis is time in seconds, X axis is date. As you see it takes on average 8 seconds to load the editor in Safari, 15 seconds in Chrome and around 18 seconds in Firefox!

When I first saw this chart, I was really surprised (actually I still am!). Why there is such a huge difference in loading time? I would expect that loading time would depend on geographical location, but not on the browser!

So far I have come up with two possible explanations:

A: Safari is fastest in parsing and initialization of javascript. Since our tracking code gets executed only after the whole app is loaded, parsed and initialized, then this part certainly plays a role. But, it does not explain such a huge difference between Safari and the others.

B: Safari users connected to the Net via better networks. If you take into account that Safari is mostly on Macs, and Macs are quite expensive, then you could conclude that people who buy expensive hardware on average also use more expensive (and thus faster?) networks.

Any other explanations? Please comment below if you have an idea!

puzzled