You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# DevTools: Selector Performance Tracing for Style Calculations
2
2
3
3
Authors:
4
-
-*[Brandon Walderman](https://github.com/bwalderman)*, Senior Software Engineer, Microsoft Edge
4
+
5
+
**[Brandon Walderman](https://github.com/bwalderman)*, Senior Software Engineer, Microsoft Edge.
6
+
7
+
## Feedback
8
+
9
+
Have feedback about this explainer? We want to hear it!
10
+
11
+
**[Issue #98](https://github.com/MicrosoftEdge/DevTools/issues/98)** tracks community feedback on this explainer.
5
12
6
13
## Status of this feature
7
14
8
15
This is a proposal for a new feature that is not yet in development.
9
16
10
17
## Introduction
11
18
12
-
Style recalculation is the process of iterating through DOM elements on a page, finding all of the CSS style rules that match a given element and then computing the element's actual style based on these rules.
19
+
Style recalculation (or style recalc) is the process of iterating through DOM elements on a page, finding all of the CSS style rules that match a given element and then computing the element's actual style based on these rules.
13
20
Style recalc needs to happen whenever the applicability of CSS rules may have changed. Some examples include:
14
21
15
-
- Elements were inserted or removed from the DOM
16
-
- An element's attributes (e.g. class, id) were changed
17
-
- User input such as mouse move or focus change, which can affect `:hover` rules
22
+
* Elements were inserted or removed from the DOM
23
+
* An element's attributes (e.g. class, id) were changed
24
+
* User input such as mouse move or focus change, which can affect `:hover` rules
18
25
19
-
Style recalc can be an expensive operation and long-running style or layout operations can become performance bottlenecks that web developers need to debug.
26
+
Style recalc can be an expensive operation and long-running recalc operations can become performance bottlenecks that web developers need to debug.
20
27
21
28
The DevTools performance panel records a "Recalculate Style" trace event that shows when style recalculation occurs.
22
29
@@ -33,25 +40,26 @@ We'd like to offer web developers greater visibility into how time is being spen
33
40
Developers can already see extra statistics from style recalc in the `edge://tracing` UI if the `"blink.debug"` tracing tag is enabled.
34
41
The statistics show up as a `SelectorStats` trace event which includes a table of style rules with the following columns:
35
42
36
-
- Elapsed CPU time spent evaluating the style rule (lower is better)
37
-
- Number of "fast reject" elements that were cheap/efficient to eliminate from matching (higher portion of attempts is better)
38
-
- Number of elements the Blink rendering engine attempted to match with the rule
39
-
- Number of elements that were actually matched
40
-
- CSS selector text
43
+
* Elapsed CPU time spent evaluating the style rule (lower is better).
44
+
* Number of "fast reject" elements that were cheap/efficient to eliminate from matching (higher portion of attempts is better).
45
+
* Number of elements the Blink rendering engine attempted to match with the rule.
46
+
* Number of elements that were actually matched.
47
+
* CSS selector text.
41
48
42
49
43
50
51
+
This information can be valuable to web developers, but the `edge://tracing` UI can be daunting, especially for beginners, and the `"blink.debug"` tag needs to be enabled first.
52
+
44
53
## Proposed Solution
45
54
46
-
This information can be valuable to web developers, but the `edge://tracing` UI can be daunting, especially for beginners.
47
-
The proposed solution is to display these same statistics in the details view for "Recalcuate Style" events in DevTools performance traces, where it will be more visible to web developers who are already familiar with the DevTools performance panel.
55
+
The proposed solution is to display these same statistics in the details view for "Recalculate Style" events in DevTools performance traces, where it will be more visible to web developers who are already familiar with the DevTools Performance tool.
48
56
49
57
Developers will be able to sort the table by any column, so that they can identify individual rules that take a longer time to process or have a high number of match attempts.
50
58
If available, the CSS selector text will be enhanced with a link to the source location where the CSS rule is declared. This will let web developers quickly jump to the rule they are interested in so they can continue their investigation.
51
59
52
-
Below is a mockup of the proposed design, with the new content highlighted in red. Note that links to source locations are not currently shown in this mockup but would be rendered similar to other source links found in DevTools.
60
+
Below is a mockup of the proposed design, with the new content highlighted in red. Note that links to source locations are not currently shown in this mockup but would be rendered similar to other source links found in DevTools.
53
61
54
-
62
+
55
63
56
64
## Usage
57
65
@@ -74,15 +82,11 @@ When the checkbox is enabled, a table of selector statistics will be available i
74
82
75
83
We should provide web developers with resources to understand how to use this new tool effectively. Some patterns in the data worth exploring:
76
84
77
-
- Expensive unused selectors
78
-
- Expensive broadly scoped selectors
79
-
- Underutilized selectors (low match count / match attempts)
80
-
81
-
## Feedback
82
-
83
-
Have feedback? We want to hear it! *[Issue #98](https://github.com/MicrosoftEdge/DevTools/issues/98)* tracks community feedback on this explainer.
85
+
* Expensive unused selectors.
86
+
* Expensive broadly scoped selectors.
87
+
* Underutilized selectors (low match count / match attempts).
0 commit comments