- 
                Notifications
    You must be signed in to change notification settings 
- Fork 7.8k
docs: initial docs for Performance tracks #7938
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| Size changes📦 Next.js Bundle Analysis for react-devThis analysis was generated by the Next.js Bundle Analysis action. 🤖 One Page Changed SizeThe following page changed size from the code in this PR compared to its base branch: 
 DetailsOnly the gzipped size is provided here based on an expert tip. First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If  Any third party scripts you have added directly to your app using the  Next to the size is how much the size has increased or decreased compared with the base branch of this PR. If this percentage has increased by 10% or more, there will be a red status indicator applied, indicating that special attention should be given to this. | 
7ba84af    to
    b59f74c      
    Compare
  
    ee8df3b    to
    663e97f      
    Compare
  
    663e97f    to
    499511f      
    Compare
  
    499511f    to
    5f43f3f      
    Compare
  
    | @@ -0,0 +1,129 @@ | |||
| --- | |||
| title: React Performance tracks | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| title: React Performance tracks | |
| title: React performance tracks | 
It feels weird to capitalize performance. I'd either capitalize everything or just React. There are other examples of this in the doc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thinking is, Performance is capitalized here to align with "Performance panel" in the browser.
@rickhanlonii How do you feel about the naming?
|  | ||
| ### Components {/*components*/} | ||
|  | ||
| The Components track visualizes the durations of React components. They are displayed as a flamegraph, where each entry represents the duration of the corresponding component render and all its descendant children components. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should mention that not all components rendered are shown here. Only the ones taking more than a specific amount of time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, added a note:
<Note>
Unlike renders, not all effects are shown on the Components track by default.
To maintain performance and prevent UI clutter, React will only display those effects, which had a duration of 0.05ms or longer, or triggered an update.
</Note>
I am working on a feature that will record effects that triggered an update, independent of their duration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding that note, are we showing all components rendered, but not all effects, or are we also not showing all the renders?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All renders are showed, independent from their corresponding duration.
Not all effects are showed. With facebook/react#34648, we won't show the ones that took 0.05ms or less and didn't trigger any blocking updates.
5f43f3f    to
    7820e43      
    Compare
  
    7820e43    to
    9f95da2      
    Compare
  
    5df064d    to
    d2b6b67      
    Compare
  
    |  | ||
| The Scheduler is an internal React concept used for managing tasks with different priorities. This track consists of 4 subtracks, each representing work of a specific priority: | ||
|  | ||
| - **Blocking** - The synchronous updates, which could've been initiated by user interactions. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
State updates from commits (layout effects, ref assignments, etc.) are also scheduled with a blocking priority. We should probably mention that too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "The synchronous updates" are referring to the application updates, not to the state updates.
I am not sure how to update it to clarify it more
        
          
                src/content/reference/developer-tooling/react-performance-tracks.md
              
                Outdated
          
            Show resolved
            Hide resolved
        
      | <img className="w-full dark-image" src="/images/docs/performance-tracks/scheduler-cascading-update.dark.png" alt="Scheduler track: cascading updates" /> | ||
| </div> | ||
|  | ||
| [Learn more about Effects](/learn/you-might-not-need-an-effect). | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a concrete example we can link to instead? Maybe even with a backlink telling people to use the profiler to spot cascading updates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have a section that explains fully the cascading updates. Only a small paragraph on https://react.dev/learn/you-might-not-need-an-effect#updating-state-based-on-props-or-state, where it is briefly mentioned.
That's a great idea for a separate task, we could add a section to it that explains how cascading updates could be spotted with Performance tracks. Will follow up.
Adds initial docs for React Performance tracks.
These docs cover only client-side tracks for now: Scheduler and Components.