Your team wants to ship the `actualDuration` values from React's `<Profiler>` to analytics from real users' browsers. What does a standard React production build do with those measurements, and what does it take to get real numbers?

## Why the standard production build says nothing Measuring render work is itself work. To produce `actualDuration` and `baseDuration`, React must take a timestamp around each unit of work in the profiled subtree, accumulate the results as it walks back up, and keep per-component timing state so it can estimate the no-memoization cost later. That instrumentation is threaded through the hot path of rendering, which is exactly the code React optimises hardest. So React ships it out of the default production build. The consequence for your plan is blunt: leaving a `<Profiler>` in production code and expecting numbers to flow into analytics does not work with a normal build. You are not going to accidentally slow every user down with a full timing pass — but you are also not going to learn anything. ## The profiling-enabled build React publishes a production build **with** profiling enabled for exactly this case. `react-dom` exposes it as the `react-dom/profiling` entry point, and build tools and frameworks generally offer a flag that swaps it in so you do not have to rewrite imports. It is production React — minified, without development warnings — plus the timing instrumentation. That is the whole tradeoff, and it should be stated plainly to whoever is asking for the data: - **Runtime cost.** Every commit in the app pays for the measurement, not only the profiled subtrees, because the instrumentation lives in React's own work loop. - **Bundle cost.** The build is somewhat larger than the plain production build. - **Observer effect.** The numbers you collect are timings of an instrumented React. They are excellent for comparison — this route versus that one, before a change versus after — and misleading if quoted as "what users experience" on the shipped build. ## How to ship it responsibly Treat it as an experiment with an end date, not a permanent property of the app: 1. **Put it behind a build flag.** One environment variable that selects the profiling build, so returning to normal is a rebuild, not a refactor. 2. **Limit the blast radius.** A canary deployment, an internal build, or a small sampled percentage of traffic answers most questions. Whole-fleet profiling is rarely necessary to find out that one subtree costs 40 ms. 3. **Keep the callback cheap.** `onRender` runs after every commit of the profiled subtree — many times per interaction on a busy page. Push a small record into a buffer and flush it on an idle callback or on page hide; never do a network request per commit, and never do heavy formatting inside the callback, because that work lands inside the very path you are measuring. 4. **Know what decision the data drives.** "We suspect the dashboard subtree is slow on low-end devices and want the distribution across real hardware" is a reason. "It would be nice to have render times in the dashboard" usually is not, given the cost. 5. **Have a stop condition.** When the question is answered, drop back to the standard build. ## What to reach for first Before shipping an instrumented React to users, ask whether a local session answers the question. React DevTools can profile locally with no production impact at all, and most render-cost problems — a context value rebuilt each render, a list re-rendering wholesale, state held too high — reproduce on a developer machine. The genuine case for production profiling is the one you cannot reproduce: real data volumes, real device classes, real network conditions, a long tail that only shows up across thousands of sessions. ## Numbers that do not transfer Two tempting substitutes are worse than useless: - **Development-build numbers.** Development React is slower by design and includes warnings and checks that production strips. On top of that, StrictMode deliberately renders components twice in development, inflating `actualDuration`. A dev measurement is a comparison tool, not a production estimate. - **Shipping a development build to production** to "get the timings". This is the anti-pattern the question is really probing. It exposes development-only behaviour, ships a much larger and slower bundle, and produces numbers further from reality than the profiling build would. The profiling build exists precisely so nobody has to do this. The summary a senior engineer gives: profiling in production is possible, deliberately not free, and worth doing only for a question you cannot answer any other way — behind a flag, on a slice of traffic, with a cheap callback and a plan to turn it off.