Chromium F12 Profiler: The Main Thread Pane<!-- --> | <!-- -->Web Performance Tips

Chromium F12 Profiler: The Main Thread Pane

The majority of my time spent analyzing the CPU component of a web application's performance trace is within the Chromium F12 Profiler's Main Pane.

This pane visualizes all CPU activity taking place on the Main Thread, including Tasks and Rendering Frames.

In this tip, we'll discuss this Main Pane in detail, and how to read it effectively.

A screenshot highlighting the Main Profiler Pane in Chromium DevTools


You should collect a trace and familiarize yourself with the basic of the Chromium F12 Profiler.

Representing Time

Like all Panes in the Chromium F12 Performance Profiler, time is represented from left to right. This means the earlier events collected during the Trace are represented on the left, with later events filling in from left to right:

A screenshot highlighting Main Profiler Pane Time


Each unit of execution that takes place on the Main Thread is called a Task.

Tasks are visualized as grey blocks (representing their time to execute). JavaScript Tasks also will have detailed callstack information visualized as a flamegraph.

A screenshot highlighting the Tasks run on the Main Thread

Not all Tasks that take place on the Main Thread will be JavaScript Tasks, and, as a result, not all Tasks will have a detailed flamegraph in the F12 Profiler.

You can see the time it takes to execute a Task by hovering over the root Task band:

A screenshot highlighting the time it takes to execute a Task on the Main Thread

Thread Inactivity

If there is no Task taking place on the Main Thread, the Profiler UI will leave that section of time as empty:

A screenshot highlighting Main Thread Inactivity

The design of the browser event loop is intentionally non-blocking. If there is sizeable gaps representing Main Thread inactivity, that could indicate you are not giving the browser any work to do.

Note: Depending on your scenario, you may or may not want the Main Thread to have period of inactivity. Learn about this more at my detailed tip on Main Thread inactivity.

Task Colorization

In the Tasks presented in the Chromium F12 Main Thread pane, the Profiler will colorize certain activities consistently to make it easy to visually spot bottlenecks or inefficiencies.


HTML and CSS parsing get colorized as a Blue color:

A screenshot highlighting HTML Parsing activity

JavaScript Tasks

JavaScript engine related Tasks are usually colorized as an Orange color at the base:

A screenshot highlighting the Orange base of the JavaScript related Tasks

JavaScript engine related Tasks include script compilation, executing event listeners, firing timers, garbage collection, and any other JavaScript-related work.

Below the engine-related bands, JavaScript callstacks are colorized consistently based on what script is executing the captured stack frame in the flamegraph:

A screenshot highlighting the colors of a JavaScript flamegraph

In this example, several scripts are included in the callstack. In the Profiler, each script gets assigned a consistent color across the trace for each stack frame originating from it.

Browser APIs

In a JavaScript callstack, occasionally, you will see a Brown color. This indicates that the work taking place is a browser API, like setTimeout or createElement:

A screenshot highlighting the colors of Browser APIs

Style and Layout

As part of the browser's Rendering Pipeline Recalculate Style and Layout will run intermittently. These will be colorized as a Purple:

A screenshot highlighting the colors of Recalculate Style and Layout

The purple colorization is usually related to any work that updates or interacts with the data structures that back the visual elements on the page.

Paint and Compositing

Shortly after Recalculate Style and Layout run, the browser will typically run a Paint event, and sometimes some additional Composite Layers work. These will be colorized as Green:

A screenshot highlighting the colors of Recalculate Style and Layout

Work colorized as Green typically indicates the browser is preparing to generate pixels to the UI, and is doing (or preparing to do) some sort of graphics related work to display a Frame.

Tying Back to the Trace Overview

At the top of the Profiler, there's the Trace Overview section:

A screenshot highlighting the Trace Overview section

We can use our expanded knowledge of Profiler colors to quickly spot regions of activity or inactivity, and guess as to what kind of activity is taking place.

For example, in my trace, I can quickly see in the Trace Overview section what type of work is taking place primarily:

A screenshot of the Trace Overview section

Furthermore, I can use the Selection capabilities of the Profiler to drill into the region of interest. For example, if I wanted to look at what was taking place in the CSS or HTML Parsing block I called out above, I can scope the selection to it:

A screenshot of the Trace Overview section

Here I can see the majority of this time is going to parsing a Stylesheet.


With this knowledge, you can more easily find and understand how the browser is executing your web application, so you can quickly spot inefficient regions of interest.

That's all for this tip! Thanks for reading! Discover more similar tips matching CPU and Profiler.