Measure Component Render Costs with <Profiler>
React's <Profiler> is a stopwatch for your components, measuring render times programmatically. Wrap any UI tree to log detailed performance metrics on every update, helping you pinpoint slow renders. The footgun: It's disabled in production by default.
Why it exists
The visual profiler in React DevTools is great for interactive debugging, but it can't automatically collect performance data from users in the field. The <Profiler> component was created to solve this by providing a programmatic API to measure render performance and log it over time.
The mental model
Think of <Profiler> as a performance harness you wrap around a component tree. It doesn't render any visible UI. Instead, it observes its children. When they render, it executes your callback function with a detailed report of what rendered and how long it took, letting you ship that data to an analytics service.
How it works
You wrap a component tree with <Profiler> and provide two props: a string id to label the measurement, and an onRender callback function. This callback receives several arguments, but the most important are phase ('mount' or 'update'), actualDuration, and baseDuration.
actualDuration is the time spent rendering the wrapped components for the current update. baseDuration is the estimated worst-case time to render the entire subtree without any optimizations. Comparing actualDuration to baseDuration on updates tells you how effective your memoization (like React.memo) is. A low actualDuration is the goal.
When to use it
Use <Profiler> to collect and aggregate real-world performance data. It's perfect for sending metrics to an analytics platform to track component render times across different user segments, browsers, or application versions. This helps you spot performance regressions that you might miss in local development.
When not to use it
Do not use it for one-off debugging during development; the React DevTools Profiler tab is much faster and more interactive for that. Critically, do not ship it in a standard production build expecting it to work. The overhead it adds means it's disabled by default, and your onRender callback will not be called unless you enable the special profiling production build.
One canonical example
To measure a Navigation component, you would define a callback and wrap the component. The onRender callback could then send the data to a logging service.
function logRenderTime(id, phase, actualDuration) {
myAnalyticsService.log('react-render', { id, phase, actualDuration });
}// Inside your app layout:
<Profiler id="Navigation" onRender={logRenderTime}>
<Navigation />
</Profiler>
This setup will send the actualDuration for the Navigation component to your analytics service every time it mounts or re-renders.
Interview question
What is the most critical reason a React <Profiler> component's onRender callback might not execute when deployed in a production environment?
- a.The onRender callback is asynchronous, and the React scheduler prioritizes rendering over callback execution.
- b.The baseDuration is significantly higher than actualDuration, indicating efficient memoization that bypasses the onRender call.
- c.The component wrapped by <Profiler> has not mounted or updated since the application loaded.
- d.The application is deployed with a standard production build, which disables the <Profiler> component by default.Correct
Why? this is the answer
The card explicitly states that <Profiler> is disabled in standard production builds by default, and its onRender callback will not be called unless a special profiling production build is enabled. Option C describes a general condition for the callback not firing, not a production-specific failure of the profiler itself.
Just read this? Test yourself on what you have been reading.
Read the original → react.dev
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.
See open roles