Open Bug 1491111 Opened 6 years ago Updated 1 year ago

Slow restyles when loading cnn.com in network panel

Categories

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

defect

Tracking

()

Performance Impact low
Tracking Status
firefox64 --- affected

People

(Reporter: dholbert, Unassigned)

References

(Blocks 1 open bug)

Details

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

ACTUAL RESULTS:
Here's my profile of these STR:  https://perfht.ml/2xawKhj
(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: https://perfht.ml/2CR2JbW
 - 38ms long restyle: https://perfht.ml/2CV1vfM
 - 28ms long restyle: https://perfht.ml/2x8Mu4F
 - 27ms long restyle: https://perfht.ml/2xa20gC

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 CNN.com (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 cnn.com 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:
https://perfht.ml/2xa4ueW

And here's e.g. one 90ms long restyle: https://perfht.ml/2x8HRaz
and here's a 102ms restyle from comment 1's profile: https://perfht.ml/2xgzpGD
(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.