Single-API Firefox Telemetry Plots: telemetry-wrapper.js

Say you’ve read my earlier post on Firefox Telemetry and want to make your own plots like https://telemetry.mozilla.org does. Well, like almost everything Mozilla does, that website is open source, so we can just copy what it does… except it’s a little convoluted. It needs to support a range of requirements and configurations, after all.

But your needs are just yours, so wouldn’t it be nice if there were something a little more direct?

Enter telemetry-wrapper.js. Simply include it and its dependencies in your HTML and then call it like so:

TelemetryWrapper.go(params, element);

Then ‘element’ will suddenly (after a few seconds to collate and render the data) contain one or more plots corresponding to ‘params’.

Want to see GC_MS compared by e10sEnabled setting on Nightly 44?

TelemetryWrapper.go({
  channel: "nightly",
  version: "44",
  metric: "GC_MS",
  compare: "e10sEnabled",
}, document.body);

(e10s is looking like a win on this metric, though part of the sample population self-selected so we can’t be sure. Await blog posts from other quarters on A/B tests we’re conducting.)

How about the top three plugins activated in Firefox 42?

TelemetryWrapper.go({
  channel: "release",
  version: "42",
  metric: "PLUGIN_ACTIVATION_COUNT",
  keyLimit: 3,
}, document.body);

(no one is surprised that the top one is Flash and that most people only use it the once. But googletalk has an odd shape to it, being activated exactly twice by clients more often than any other frequency…)

The technical details are in the README. Use and reuse it to ask and answer questions about Firefox Telemetry data!

:chutten

A Firefox Telemetry Introduction

Telemetry is Firefox’s way of sending anonymous analytics data back to Mozilla to help improve Firefox. If you run Firefox and are up-to-date as of this blogpost, you probably send at least bare-minimum telemetry to Mozilla fairly regularly.

Thank you!

This data is important to figure out the size and shape of the userbase, and what sorts of issues might be happening. You can see all the telemetry from your Firefox by visiting about:telemetry.

Since this is Mozilla we’re talking about, the information collected this way is available for you (yes, you!) to run analyses on. For instance, here is a histogram showing distributions of Firefox Desktop 42 “first paint” time compared by Operating System for Windows, Mac, and Linux.

plot showing Firefox first paint measures, compared by operating system. Windows and Mac have similar distributions, but Linux trends to longer durations before first paint.

We can see that maybe there’s something we could be doing to make Linux startup speed faster on that release, as a largish part of its histogram is shifted right into the higher values.

But how has startup speed been trending? Here is an evolution plot showing median startup time over the past four Firefox Desktop beta versions on Windows.

plot showing the evolution of Firefox for Windows first paint times over four beta releases. There is a noticeable downward trend.

The general trend has been downward (faster startup? Excellent.) However, it might be a bit slower in the latest rev (Grr. We need to watch this.) This evolution plot shows progress is fairly flat through beta releases, which is what we’d expect based on how stable the builds are that reach that step.

Now, if we graph the same plot by the date the browser submitted the telemetry, instead of the date the browser was built, we see something very interesting indeed.

an evolution plot showing Firefox for Windows first paint times. There are peaks every Saturday where first paint is slower.

What are these peaks? They happen every week on the same day… how often is Beta updated again? (Correlation is not causation, so maybe there’s another reason for the reliable frequency of those distributions.)

Right now I will be working on increasing the relevance and usefulness of the telemetry data you have so kindly provided. My next task will be to determine whether the new multi-process Firefox feature (“Electrolysis” or “e10s”) causes Firefox to crash any more often if someone has Firefox’s accessibility features turned on. This will be an important measure to determine when this feature will be able to be shipped in a later Firefox release.

If you’re interested, there is a lot more material you can read about how to use the various telemetry tools, how Mozilla uses the data that comes out of it, and how you can help to make it better.

:chutten