React recently introduced an experimental profiler API. This page gives instructions on how to use this API in a production release of your app.
Table of Contents
React DOM automatically supports profiling in development mode for v16.5+, but since profiling adds some small additional overhead it is opt-in for production mode. This gist explains how to opt-in.
Creating a profiling build can be done by specifying an additional --profile
flag:
yarn build --profile
npm run build -- --profile
At the moment, the only way to permanently enable production profiling in CRA apps is to eject. Then you can follow the instructions below and apply these changes to config/webpack.config.prod.js
in your app folder.
However, you can also enable profiling temporarily without ejecting.
If you only want to profile the application locally in production mode, you can do this by editing node_modules
directly.
Follow the instructions below, and apply them to node_modules/react-scripts/config/webpack.config.prod.js
. Then you can run yarn build
or npm run build
to get a profiling build. Note that your changes would be temporary and will not persist between re-runs of your package manager.
To enable profiling in production mode, modify Webpack configuration file (config/webpack.config.prod.js
) as shown below.
module.exports = {
// ...
resolve: {
// ...
alias: {
// ...
'react-dom$': 'react-dom/profiling',
'scheduler/tracing': 'scheduler/tracing-profiling',
},
// ...
},
// ...
};
Note that if you're using a version of
react
/react-dom
that's less than 16.6, you should refer to this earlier revision of the documentation instead.
Note that if you're using the
schedule
package v0.3.0-v0.4.0 you should refer to this earlier revision of the documentation instead.
When profiling locally, you might want to disable function name mangling so that you can see the component names in the profiler. Note that this will significantly increase your bundle size so only do this during local development! To do this, find the mangle
option for UglifyJSPlugin
in the config, and set it to false
. Don't forget to undo your changes before a real deployment.
If you are using Webpack 4 to bundle your apps, add the following import aliases to your production config:
module.exports = {
//...
resolve: {
alias: {
'react-dom$': 'react-dom/profiling',
'scheduler/tracing': 'scheduler/tracing-profiling',
}
}
};
Note that if you're using a version of
react
/react-dom
that's less than 16.6, you should refer to this earlier revision of the documentation instead.
Note that if you're using the
schedule
package v0.3.0-v0.4.0 you should refer to this earlier revision of the documentation instead.
When profiling locally, you might want to disable function name mangling so that you can see the component names in the profiler. Note that this will significantly increase your bundle size so only do this during local development! To do this, find the mangle
option for UglifyJSPlugin
in the config, and set it to false
. Don't forget to undo your changes before a real deployment.
Both your application and react-dom
need to use the same scheduler
version in order for tracing to work. NPM may install multiple copies if the versions don't match, in which case your application will end up tracing interactions with a difference package than react-dom
reads them from.
The safest way to ensure that this does not happen is to copy the exact scheduler
version that react-dom
specifies as a dependency.
For example, assuming you are using react-dom
version 16.5.0 you can find which version of scheduler
to use by running:
➜ npm view [email protected]
dependencies:
loose-envify: ^1.1.0 object-assign: ^4.1.1 prop-types: ^15.6.2 scheduler: ^0.10.0
The above output shows that [email protected]
depends on scheduler@^0.10.0
, so your application code will also want to use that exact version.
If you're not sure if mismatching versions are installed, you can use npm ls scheduler
to check:
➜ npm ls scheduler
├─┬ [email protected]
│ └── [email protected]
├─┬ [email protected]
│ └── [email protected]
└── [email protected]
In the above example react-dom
and my application are depending on different versions of scheduler
. This will result in multiple copies of the package being installed (one in node_modules/scheduler
and another in node_modules/react-dom/node_modules/scheduler
).
You can fix this by updating your app to use the exact version react-dom
is using:
➜ npm i scheduler@^0.10.0
➜ npm ls scheduler
├─┬ [email protected]
│ └── [email protected]
├─┬ [email protected]
│ └── [email protected]
└── [email protected]
Yarn users can check to see if mismatching versions are installed using yarn why
:
➜ yarn why scheduler
[1/4] 🤔 Why do we have the module "scheduler"...?
[2/4] 🚚 Initialising dependency graph...
[3/4] 🔍 Finding dependency...
[4/4] 🚡 Calculating file sizes...
=> Found "[email protected]"
info This module exists because it's specified in "dependencies".
=> Found "react#[email protected]"
info This module exists because "react" depends on it.
=> Found "react-dom#[email protected]"
info This module exists because "react-dom" depends on it.
✨ Done in 0.09s.
You can fix this by updating your app to use the exact version react-dom
is using:
➜ yarn add scheduler@^0.10.0
➜ yarn why scheduler
[1/4] 🤔 Why do we have the module "scheduler"...?
[2/4] 🚚 Initialising dependency graph...
[3/4] 🔍 Finding dependency...
[4/4] 🚡 Calculating file sizes...
=> Found "[email protected]"
info Reasons this module exists
- Specified in "dependencies"
- Hoisted from "react#scheduler"
- Hoisted from "react-dom#scheduler"
✨ Done in 0.09s.