Description
Precise Activation RFC
Table of Contents
One large (and mostly correct) criticism of react scan is it can be very noisy for a large set of problems. Re-renders are not always expensive, and re-renders are not always the problem.
To resolve this, this RFC proposes to:
- Only show core outline visualizations when we detect slow renders
- Provide a direct summary of what caused slowdown in toolbar
- A new set of visualizations applied to the dom which provide a summary of what happened
Only show core outline visualizations when we detect slow renders
React scan can be extremely noisy when there are no problems. For example, scrolling on twitter causes large re-renders, but no drops in performance. This leads to a noisy-first experience that forces the user to turn off react scan till they explicitly have a problem.
Screen-2025-01-27-002837.1.mp4
To transform react-scan to an "on first" experience, we can only show react-scan outlines when the user actually wants to see react-scan outlines. This can be formalized - only show react-scan outlines when re-renders meaningfully slowed down the app.
Meaningfully is initially defined as:
-
200ms interaction times
-
50ms task times
With the use of bippy instrumentation, fiber timings, and browser API's, we can directly calculate:
- How long a task took
- The percentage of the task taken up by react renders
This means we can precisely trigger react-scan overlays when component renders meaningfully slowed down the app.
Note: We will still provide an option to always have react-scan always on.
Provide a direct summary of what caused slowdown in toolbar
While ephemeral outlines when the app is slow is an improved default, it is still not sufficient information to make any decision. The user will still have to manually find the problem (perhaps through the react profiler), find the re-rendering components, optimize them, check back on react-scan to see if anything changed.
This is a suboptimal debug flow:
- It requires an external tool to completely understand the problem
- The external tools publicly available are either too hard to understand (react devtools, chrome profiler) or too slow to use (console logs, performance.now)
React-scan internals already know a significant amount of information about where the problem lies.
This RFC proposes to leverage the react-scan toolbar's dynamic UI to create a notification to show a slow problem was detected.
Clicking this notification would reveal a UI containing beginner-consumable information about performance problems.
This toolbar UI will leverage the runtime powering react-scan replay to collect information about the problem https://react-scan.com/replay
Note: The UI for presenting this data on the toolbar is still undefined
The data we have access to (roughly ordered by predicted usefulness) is:
- Component render times
- % offscreen renders
- Forced reflows
- Components that could have been memoized
- Useful to verify react compiler impact
- Useful for the large set of users that can't move to react compiler (organizational reasons)
- Components with unstable props, state, or subscribed context
- Unstable is defined as the reference of the javascript object changed
- Components with props/state/subscribed context that had unnecessary references changes
- Unnecessary reference changes is defined as if the object is structurally comparable to the previous object, and its equal
- Slow CSS properties used
- Slow CSS mutations
- Unnecessary renders (a render is defined as unnecessary if it rendered with no consequence to the dom)
We also have data that can help verify performance optimizations:
- All the components that were successfully memoized and avoided rendering during the slow interaction/long task
A new set of visualizations applied to the dom which provide a summary of what happened
The approach that worked very well for react-scan is visually overlying UI over a fibers stateNode when it re-renders. Formally, we visualized performance problems in a very digestible way.
It is not the case showing re-render outlines is the only useful visualization that exists for performance problems.
The set of visualizations we can do in the current react-scan model (always on) is limited. Outlines must deliver the information they represent semantically in <1000ms (roughly, the time it takes for outlines to fade out).
There is a hard ceiling of the maximum amount of information we can represent in <1000ms (each visualization takes time to process, so stacking visualization stacks like debuffs in a video game).
In the new react-scan model, we will provide digestible summaries the user can understand through the toolbar. The user must manually decide to view the summary, which means the user can review the summary for any period of time (our new ceiling is ∞ ms).
Because of this, the universe of visualizations we can perform at this time significantly increases.
For example, we can trivially visualize slow component renders with a heatmap based on component render times during the slow interaction or long task:
(A dummy example of a component render time heatmap on the react-scan website)
TLDR
The features laid out in this RFC can enable react-scan to become a "digestible always on profiler" to allow users with no performance experience to quickly find performance problems