[RFC] Add <PerformanceTracks>

[rickhanlonii]

This is mostly vibe coded so I need to review and edit this myself, but I wanted to open an RFC to see if this is something that is valuable to add.

Overview

Adds a <PeformanceTracks> component that allows you to render a docs-branded diagram of the React Performance Tracks. Also includes a convertTrace script that converts an exported performance trace to a copyable <PerformanceTracks> snippet for that trace:

node scripts/convertTrace.js trace.json

<PerformanceTracks
  data={{
    duration: 1000,
    tracks: {
      scheduler: {
        blocking: [
          {
            type: "event",
            name: "click",
            start: 0,
            duration: 76,
          },
          // ...
        ],
        // ...
      },
      // ...
    },
  }}
/>

Features

• Ensures the entries expand enough to show the label so "Event: click" is not collapsed to "Ev..."
• Uses a log(2) scale to reduce the length of entries (like long Suspense entries)
• Scrollable, but attempts to scale down if it's close to not needing to scroll
• Can add annotations to call out parts of the trace
  • I think these can be improved a lot

Screenshot

Dark Mode

Light Mode

Video

Screen.Recording.2026-02-10.at.1.06.37.PM.mov

TODO

• Actually review and clean up the code

[github-actions]

Size changes

Details

📦 Next.js Bundle Analysis for react-dev

This analysis was generated by the Next.js Bundle Analysis action. 🤖

⚠️ Global Bundle Size Increased

Page	Size (compressed)
global	115.17 KB (🟡 +81 B)

Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

Five Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page	Size (compressed)	First Load
/404	130.14 KB (🟡 +3.81 KB)	245.31 KB
/500	130.15 KB (🟡 +3.82 KB)	245.32 KB
/[[...markdownPath]]	132.58 KB (🟡 +3.82 KB)	247.75 KB
/errors	130.39 KB (🟡 +3.82 KB)	245.56 KB
/errors/[errorCode]	130.37 KB (🟡 +3.82 KB)	245.54 KB

Details

Only 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 next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

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.

[MaxwellCohen]

I really like the idea of this component. Having a clearer understanding of the computation tasks React executes is very helpful for building better apps with React.
Some feedback

1. Leverage React.lazy or next dynamic to lazy load, and add treeshake to this component for the overall React.dev performance, since it won't be on every page (there might be other components that should be lazy loaded too). The first load sizes seem a little large overall.
2. The mobile and small screen view is less than ideal

3. The accessibility tree in Chrome makes it look like this component would not be very useful for screen readers (just listing out React render steps).