[Feedback] Selector Performance Tracing Explainer

[bwalderman]

This issue is meant to collect feedback about the proposed Selector Performance Tracing feature explainer for Edge DevTools.

This feature is being considered to help web developers understand which elements and style rules are having the most performance impact during style recalculation.

[JakeLane]

This is awesome!

My company definitely would massively benefit from style recalculation becoming more accessible in any way. We currently have problems with CSS performance in bigger experiences and it is very difficult to give actionable feedback to developers, as most will have never looked at tracing for their day-to-day development.

I think one feature that I see missing there would be the ability to jump to the source code. Especially in production mode, hashed class names can be difficult to track down.

Misread the explainer, sounds great! It would also be cool if you could jump to the source code that triggered a change in CSS, e.g. either adding/removing CSS or updating the DOM with new styles.

[nolanlawson]

This looks really cool! I've been using SelectorStats to debug some issues with style calculation. Here is some of my feedback:

1. There is already an experimental option called Timeline: invalidation tracking which shows which elements were invalidated during style/layout. Maybe this should be enabled when the checkbox is checked?
2. When the checkbox is not checked, maybe the details on Recalculate style should say something like "Enable for more info"?
3. In cases of layout thrashing (or similar), there may be multiple Recalculate styles in the same trace. It would be great to have some way to merge the SelectorStats for each one.
4. In practice, I've found this tool most useful for identifying patterns of CSS selectors rather than individual selectors (which don't necessarily consume much time on their own). For instance, selectors containing a particular string may come from the same CSS file, CSS preprocessor, etc. Having some way to search, filter, and sum would be extremely useful: I'd be able to make statements like "If we stopped using the pattern [class*=<foo>], we would save X milliseconds total."
5. "Fast reject" is not very intuitive to most web devs – maybe upon hovering the column name, it could explain more about how the Bloom filter works? Or at least how to interpret "fast reject"?
6. Similarly, I understand why this is measured in microseconds, but maybe upon hover it could explain how to convert to milliseconds? (For those of us who don't intuitively know what μs means. 🙂)

Great work, and looking forward to this landing!

[RobMeyer]

Love this feature -- I've been using edge://tracing with Blink.debug to look at SelectorStats, but I much prefer the DevTools experience when able, so this is great to have. Some misc feedback:

1. The selector column could be a hyperlink that goes to the definition of the selector. This could be a css file in the sources tab, or for css-in-js it might be a style node under document.head.
2. Our css class names get minified at build time, so to make profiling prod-optimized builds easier, it would be great to see source-mapping support to automatically show both versions of the selector.
3. The default sort order should probably be elapsed time descending
4. It'd be great if it were possible to view an aggregate table of multiple Recalculate Style events. Perhaps multi-select or view a cumulative table of all Recalculate Style blocks within the currently viewed time range.
5. The table should be copy-pastable (e.g. into a spreadsheet)
6. The sum of all elapsed time falls short of the Recalculate Style block's own duration. It'd be nice to understand whether the rest is fixed overhead, overhead that scales (and with what factors -- dom size, selector complexity, number of selectors, etc.), related to profiling overhead itself and isn't worth being concerned about, or some other relationship.

[aluhrs13]

Awesome to see this in DevTools - Lowering the bar for debugging CSS performance is great.

A few thoughts playing with it:

• It might be nice to have a short semi-opinionated summary above the table. "X Selectors were processed, taking Y ms, and Z had no matches"
• Is the default ordering relevant/important in any way? If not, +1 to Rob's suggestion about elapsed time being default.
• +1 to the sentiment of having an aggregated view of all the recalcs in a trace. It'd be useful as a starting point for generic optimizations and to find patterns.
• You can't copy/paste large portions of the table, it seems like you can only copy what's visible. It'd be useful to pull data into Excel when there's a lot.
• There's no scrollbar which makes it difficult to tell just how long the list is.
• Microseconds threw me off too. I'll admit that I went and searched microseconds to milliseconds to make sure that I had the conversion right.

I think Rob/Nolan hit most of what I'm thinking on the docs and explanations front - Having tooltips with details and links out to details on what some of this means will be helpful once this gets towards stable/completion. Also calling attention to this option in traces that have long recalcs is a great idea from Nolan.

[spmonahan]

I learned today that this is now available in production Edge. Congrats on shipping!

I demoed this feature for my team today and one thing that came up is that it would be nice to have a way to filter the list of selectors as it can be rather long. This could of course be quite sophisticated with filtering based on time, matches, etc but I think just a simple filter for selector names would go a long way to help reduce the amount of data to consider.

[jasonwilliams]

Hi @bwalderman

I ran into a bug today where this feature really would have helped but it doesn't seem to be working in my scenario.
The bug was animations running when they shouldn't need to (and causing style recalculations) and I wanted to track down where these animations were coming from. This seemed like the perfect candidate for Selector Performance Tracing, sadly I was getting little information. To make this more difficult there were no visual changes on the page, so I couldn't look to see what was changing and approach that Node/Element.

For comparison, when the initiator is from JS or a script I can see the line it initiated from, but things become more opaque when the initiator is a CSS Animation.

Here are some steps to reproduce:

I am using Edge Version 120.0.2210.144 (Official build) (64-bit)

JS Initiators (working case)

1. Navigate to https://jason-williams.co.uk/test-cases/jsInit.html (You should see a small box on the top left)
2. Load up developer tools and go to the performance panel
3. Tick "Enable advanced rendering instrumentation (slow)"
4. Do a trace for a few seconds (4-5)
5. Try and find the recalculate style span, you should see something like this:

This doesn't show selector performance but I can at least see why the style recalculation happened

CSS (animation) initiators (failing case)

• Follow steps 1-5 as above but this time with https://jason-williams.co.uk/test-cases/cssInit.html
  In this trace we see a lot more style recalculations. Trying to home in on where these are coming from is much harder. Clicking "Reveal" just takes you to a schedule style recalculation which shows no info.

When you're dealing with a page or a web app that has many animations and activity happening, this doesn't help find where recalculation work is coming from. I also don't see the features shown in the explainer document either. I assume it's because they don't meet a threshold (each span is quite small) or there's another reason.

It would be great to be able to track down CSS Animations.

CrBug: https://bugs.chromium.org/p/chromium/issues/detail?id=1521263

[captainbrosset]

@jasonwilliams it sounds to me like the Selector Stats feature isn't really what would help you here. Would it be helpful if the Summary tab said that a CSS animation triggered the Schedule Style Recalculation event in the first place, and maybe link to where it's defined in the Sources tool?

[jasonwilliams]

Hi @captainbrosset

Yes, this would help a lot, if you raise this somewhere can you let me know so I can follow? I’m also happy to follow up with you if you want more details.

[captainbrosset]

I filed this upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1521335

[brinman]

I just discovered this functionality (Selector Stats) but it does not show up for me. I tried "Repairing" Microsoft edge, but still no "Selector Stats" tab appears:

https://jam.dev/c/9c525ca7-45bb-45ac-804f-fa7f5d055a82

[captainbrosset]

@brinman sorry about this. This is unfortunately a bug, but the good news is that it's known already, and being worked on by our team. Should be back to normal very soon.