Outreachy Saga: Part III – What is perf-html?

I joined Outreachy as a Mozilla intern and a member of Performance Tooling Team, which falls under Developer Experience Team. Phew! I work closely with my team and especially my mentor, Julien.

(Shoutout also to the rest of the team: Florian, Greg, Nazim, Markus and Gerald)

Our team works on perf-html (also called, the Profiler), Mozilla’s own profiler, which is used for analysing performance (when and how a page is rendered – graphics and layouts and such – how efficient the JavaScript code is, and all the magic that happens in C++).

It’s a very complex tool currently used by Firefox’ own engineers. Which explains why the project isn’t exactly beginner friendly.

Perf-html has great documentation and even video tutorials, but even after reading and watching all of that, initially I still found it hard to understand how it works, how it’s used and why you would use it all.

The thing is, in order to really take advantage of perf-html you need to be familiar with Firefox’ codebase. Which I’m not.

However, even if you’re not a Firefox engineer, you can still use perf-html to improve your code performance (and you can also use the simpler Performance tool inside the Firefox DevTools).

Perf-html comes as a Firefox add-on. Once you install the add-on, it’s easy to capture your first profile.

For example, this is a profile of the CNN.com website loading.

Pretty colours right?

You’ll notice the colourful graph right in the middle of the page. That’s the timeline. The yellow stuff is Javascript, the purple stuff is Layout, the green Graphics, and so on.

When analysing, you’ll start off by looking for a red bar on top of the timeline graph, which indicates that a substantial amount of work has been done there (or even that something was stuck).

If I zoom in onto that section, I get this:

Let’s say I’m only interested in the Javascript bits (all that yellow stuff), I can filter that out as well and then I can start dissecting the code, function by function (by looking at the running time of the function, for example, and finding ways of improving that).

Oh yes, the Profiler works best if you have the actual codebase available.

Essentially, the Profiler collects information in two ways: Samples (a snapshot of activity every 1 millisecond by default, but you can change that), and Markers (these are markers placed in your code that are told to collect information at specific times and occurrences).

Depending on what you want to analyze, you might find either the Samples or Markers data more useful.

From talking to Firefox engineers, there is no one right way of analysing the information and everyone has their preference: if you are a numbers person you’ll probably spend a lot of times in the Call Tree – a tree of all the functions – and if you are a more visual person, you might prefer the Flame Graph.

The Profiler is used by the majority of Firefox’ engineers, with the overreaching goal of making Firefox more performant.

We also have several contributors, some have been regulars for a number of years (shoutout to Michael)

I initially applied to work on perf-html not only, because it’s a very important tool (speed is everything on the web), but also because I was given a standalone project to work on which is all about accessibility.

Perf-html is highly complex and dense with information and my main job is to make it more usable and accessible to everyone.

So far I’ve dealt with keyboard navigation, focus indicators, ARIA roles and hiding elements that should not be added to the DOM tree (Firefox’ accessibility inspector really helps with that).

I’ve also learned a lot about git, working in a team and Agile. I’ll be speaking about my work on accessibility at the 2019 FOSDEM conference.

So far, an exciting and productive journey and I can’t wait to see what’s going to happen next!