Figuring out and controlling what tasks run before first paint

Kris Maglione kmaglione at
Wed Aug 9 00:42:42 UTC 2017

One of my biggest frustrations in profiling startup performance 
has been the fact that exactly which code runs during before or 
after first paint changes based on arbitrary timing factors. If 
I make a 5ms improvement to one section of code, a 100ms chunk 
of code winds up running after first paint rather than before. 
If I make a 5ms improvement to another section of code, a 150ms 
chunk of code winds up running *before* first paint rather than 
after. This also shows up in the ts_paint timings on talos, 
where we have a fairly consistent cluster of high times, a 
fairly consistent cluster of low times, and very little 

Presumably, if we're OK with these chunks *ever* running after 
first paint, then they should always run after first paint. And 
vice versa.

I've made various attempts to get a handle on this, but never 
with much success. The last time, I got as far as fixing the 
broken TaskTracer build before I finally gave up trying to find 
a useful way to analyze the data. What I'd really like is a 
handle on what tasks are run, when, who schedule them (and 
when), and what code they run.

After that, I'd ideally like to find a way to run async tasks 
during startup so that I'm guaranteed which parts run before 
first paint and which run after.

Has anyone else made any progress on this front? Are there any 
other tools that I'm overlooking? Is there a sensible path 


More information about the firefox-dev mailing list