Open Bug 1491111 Opened 6 years ago Updated 1 year ago

Slow restyles when loading in network panel


(Core :: CSS Parsing and Computation, defect, P3)




Performance Impact low
Tracking Status
firefox64 --- affected


(Reporter: dholbert, Unassigned)


(Blocks 1 open bug)


 0. Install profiler from , and toggle its "Sequential Styling" checkbox.
 1. Turn off content-blocking ( at about:preferences#privacy )
 2. Open DevTools network panel.
 3. Start profiling (with
 4. Visit (which triggers a lot of network panel activity)
 5. Stop profiling, when load is coimplete.

Here's my profile of these STR:
(Showing only the Main Thread, to focus on the Network Panel's rendering activity.)

This bug is focusing on the fact that we've got some long restyles.

E.g. these four:
 - 40ms long restyle:
 - 38ms long restyle:
 - 28ms long restyle:
 - 27ms long restyle:

If there's anything we can do here (on the engine side or the network-panel frontend side) to mitigate these slow flushes, it'd be great for developer experience when using the network panel.
Actually I'm not sure I had content-blocking fully disabled in comment 0's profile. For that profile, I technically had only turned off blocking just for (using the icon in the URL bar).  I think I still had some things blocked, though (and hence wasn't working our DevTools network panel quite as aggressively) -- after turning off content-blocking in preferences and hard-reloading, my load took much longer and had many more requests, *and* more & slower slow-restyles.

Here's that profile, zoomed to some slow restyles towards the end of the load:

And here's e.g. one 90ms long restyle:
and here's a 102ms restyle from comment 1's profile:
(Also, for the record: I enabled webrender in the profile from comment 1 here.)
Whiteboard: [qf]
So, those flushes come from offsetTop getters, it'd be good to know what changed from the last flush. Of course avoiding that getter is ideal and avoids us doing a bunch of work.

Other bits that look somewhat slow in the profile is custom variable substitution and such. Then there's a long tail of property cascading, and DidSetComputedStyle doing image stuff.

Looks like we make a pretty good job at avoiding selector-matching, but there's room for improvement above... Do we know what interaction triggers this restyle in particular?
> Do we know what interaction triggers this restyle in particular?

These restyles are all in response to rows being added (or updated with timing info) to show network requests, in the devtools networking panel.

I don't know what's happening to cause them on a more specific level than that, though.
Priority: -- → P3
Whiteboard: [qf] → [qf:p3:f67]
Whiteboard: [qf:p3:f67] → [qf:p3]
Performance Impact: --- → P3
Whiteboard: [qf:p3]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.