|
| 1 | +--- |
| 2 | +id: profiler |
| 3 | +title: Profiler API |
| 4 | +layout: docs |
| 5 | +category: Reference |
| 6 | +permalink: docs/profiler.html |
| 7 | +--- |
| 8 | + |
| 9 | +The `Profiler` measures how often a React application renders and what the "cost" of rendering is. |
| 10 | +Its purpose is to help identify parts of an application that are slow and may benefit from [optimizations such as memoization](https://reactjs.org/docs/hooks-faq.html#how-to-memoize-calculations). |
| 11 | + |
| 12 | +> Note: |
| 13 | +> |
| 14 | +> Profiling adds some additional overhead, so **it is disabled in [the production build](https://reactjs.org/docs/optimizing-performance.html#use-the-production-build)**. |
| 15 | +> |
| 16 | +> To opt into production profiling, React provides a special production build with profiling enabled. |
| 17 | +> Read more about how to use this build at [fb.me/react-profiling](https://fb.me/react-profiling) |
| 18 | +
|
| 19 | +## Usage |
| 20 | + |
| 21 | +A `Profiler` can be added anywhere in a React tree to measure the cost of rendering that part of the tree. |
| 22 | +It requires two props: an `id` (string) and an `onRender` callback (function) which React calls any time a component within the tree "commits" an update. |
| 23 | + |
| 24 | +For example, to profile a `Navigation` component and its descendants: |
| 25 | + |
| 26 | +```js{3} |
| 27 | +render( |
| 28 | + <App> |
| 29 | + <Profiler id="Navigation" onRender={callback}> |
| 30 | + <Navigation {...props} /> |
| 31 | + </Profiler> |
| 32 | + <Main {...props} /> |
| 33 | + </App> |
| 34 | +); |
| 35 | +``` |
| 36 | + |
| 37 | +Multiple `Profiler` components can be used to measure different parts of an application: |
| 38 | +```js{3,6} |
| 39 | +render( |
| 40 | + <App> |
| 41 | + <Profiler id="Navigation" onRender={callback}> |
| 42 | + <Navigation {...props} /> |
| 43 | + </Profiler> |
| 44 | + <Profiler id="Main" onRender={callback}> |
| 45 | + <Main {...props} /> |
| 46 | + </Profiler> |
| 47 | + </App> |
| 48 | +); |
| 49 | +``` |
| 50 | + |
| 51 | +`Profiler` components can also be nested to measure different components within the same subtree: |
| 52 | +```js{2,6,8} |
| 53 | +render( |
| 54 | + <App> |
| 55 | + <Profiler id="Panel" onRender={callback}> |
| 56 | + <Panel {...props}> |
| 57 | + <Profiler id="Content" onRender={callback}> |
| 58 | + <Content {...props} /> |
| 59 | + </Profiler> |
| 60 | + <Profiler id="PreviewPane" onRender={callback}> |
| 61 | + <PreviewPane {...props} /> |
| 62 | + </Profiler> |
| 63 | + </Panel> |
| 64 | + </Profiler> |
| 65 | + </App> |
| 66 | +); |
| 67 | +``` |
| 68 | + |
| 69 | +> Note |
| 70 | +> |
| 71 | +> Although `Profiler` is a light-weight component, it should be used only when necessary; each use adds some CPU and memory overhead to an application. |
| 72 | +
|
| 73 | +## `onRender` Callback |
| 74 | + |
| 75 | +The `Profiler` requires an `onRender` function as a prop. |
| 76 | +React calls calls this function any time a component within the profiled tree "commits" an update. |
| 77 | +It receives parameters describing what was rendered and how long it took. |
| 78 | + |
| 79 | +```js |
| 80 | +function onRenderCallback( |
| 81 | + id, // the "id" prop of the Profiler tree that has just committed |
| 82 | + phase, // either "mount" (if the tree just mounted) or "update" (if it re-rendered) |
| 83 | + actualDuration, // time spent rendering the committed update |
| 84 | + baseDuration, // estimated time to render the entire subtree without memoization |
| 85 | + startTime, // when React began rendering this update |
| 86 | + commitTime, // when React committed this update |
| 87 | + interactions // the Set of interactions belonging to this update |
| 88 | +) { |
| 89 | + // Aggregate or log render timings... |
| 90 | +} |
| 91 | +``` |
| 92 | + |
| 93 | +Let's take a closer look at each of the props: |
| 94 | + |
| 95 | +* **`id: string`** - |
| 96 | +The `id` prop of the `Profiler` tree that has just committed. |
| 97 | +This can be used to identify which part of the tree was committed if you are using multiple profilers. |
| 98 | +* **`phase: "mount" | "update"`** - |
| 99 | +Identifies whether the tree has just been mounted for the first time or re-rendered due to a change in props, state, or hooks. |
| 100 | +* **`actualDuration: number`** - |
| 101 | +Time spent rendering the `Profiler` and its descendants for the current update. |
| 102 | +This indicates how well the subtree makes use of memoization (e.g. [`React.memo`](/docs/react-api.html#reactmemo), [`useMemo`](/docs/hooks-reference.html#usememo), [`shouldComponentUpdate`](/docs/hooks-faq.html#how-do-i-implement-shouldcomponentupdate)). |
| 103 | +Ideally this value should decrease significantly after the initial mount as many of the descendants will only need to re-render if their specific props change. |
| 104 | +* **`baseDuration: number`** - |
| 105 | +Duration of the most recent `render` time for each individual component within the `Profiler` tree. |
| 106 | +This value estimates a worst-case cost of rendering (e.g. the initial mount or a tree with no memoization). |
| 107 | +* **`startTime: number`** - |
| 108 | +Timestamp when React began rendering the current update. |
| 109 | +* **`commitTime: number`** - |
| 110 | +Timestamp when React committed the current update. |
| 111 | +This value is shared between all profilers in a commit, enabling them to be grouped if desirable. |
| 112 | +* **`interactions: Set`** - |
| 113 | +Set of ["interactions"](http://fb.me/react-interaction-tracing) that were being traced the update was scheduled (e.g. when `render` or `setState` were called). |
| 114 | + |
| 115 | +> Note |
| 116 | +> |
| 117 | +> Interactions can be used to identify the cause of an update, althoguh the API for tracing them is still experimental. |
| 118 | +> |
| 119 | +> Learn more about it at [fb.me/react-interaction-tracing](http://fb.me/react-interaction-tracing) |
0 commit comments