How to use profiling in production mode for react-dom

index.md

Table of Contents

• Profiling in production
  • Create React App
  • Webpack 4
• Troubleshooting
  • Tracing broke after an NPM update

Profiling in production

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.

Create React App

Enabling profiling permanently

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.

Enabling profiling temporarily

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.

Changing the Webpack config

To enable profiling in production mode, modify Webpack configuration file (config/webpack.config.prod.js) as shown below.

react-dom@^16.5.2 / schedule@^0.5.0

module.exports = {
  // ...
  resolve: {
    // ...
    alias: {
      // ...
      'react-dom': 'react-dom/profiling',
      'schedule/tracing': 'schedule/tracing-profiling',
    },
    // ...
  },
  // ...
};

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.

Optional: Disabling mangling for local profiling

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.

Webpack 4

If you are using Webpack 4 to bundle your apps, add the following import aliases to your production config:

react-dom@^16.5.2 / schedule@^0.5.0

module.exports = {
  //...
  resolve: {
    alias: {
      'react-dom': 'react-dom/profiling',
      'schedule/tracing': 'schedule/tracing-profiling',
    }
  }
};

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.

Optional: Disabling mangling for local profiling

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.

Troubleshooting

Tracing broke after an NPM update

Both your application and react-dom need to use the same schedule 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 schedule version that react-dom specifies as a dependency.

Fixing this with NPM

For example, assuming you are using react-dom version 16.5.0 you can find which version of schedule to use by running:

➜ npm view [email protected]

dependencies:
loose-envify: ^1.1.0  object-assign: ^4.1.1 prop-types: ^15.6.2   schedule: ^0.3.0  

The above output shows that [email protected] depends on schedule@^0.3.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 schedule to check:

➜ npm ls schedule
[email protected] /Users/bvaughn/Desktop/test-schdeule
├─┬ UNMET DEPENDENCY [email protected]
│ └── UNMET DEPENDENCY [email protected] 
├─┬ UNMET DEPENDENCY [email protected]
│ └── UNMET DEPENDENCY [email protected] 
└── UNMET DEPENDENCY schedule@^0.2.0

In the above example react-dom and my application are depending on different versions of schedule. This will result in multiple copies of the package being installed (one in node_modules/schedule and another in node_modules/react-dom/node_modules/schedule).

You can fix this by updating your app to use the exact version react-dom is using:

➜  npm i schedule@^0.3.0
➜  npm ls schedule      
[email protected] /Users/bvaughn/Desktop/test-schdeule
├─┬ [email protected]
│ └── [email protected]  deduped
├─┬ [email protected]
│ └── [email protected]  deduped
└── [email protected] 

Fixing this with Yarn

Yarn users can check to see if mismatching versions are installed using yarn why:

➜ yarn why schedule       
[1/4] 🤔  Why do we have the module "schedule"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found "[email protected]"
info Has been hoisted to "schedule"
info This module exists because it's specified in "dependencies".
=> Found "react-dom#[email protected]"
info This module exists because "react-dom" depends on it.
=> Found "react#[email protected]"
info This module exists because "react" depends on it.
✨  Done in 0.70s.

You can fix this by updating your app to use the exact version react-dom is using:

➜  yarn add schedule@^0.3.0
➜  yarn why schedule
[1/4] 🤔  Why do we have the module "schedule"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found "[email protected]"
info Has been hoisted to "schedule"
info Reasons this module exists
   - Specified in "dependencies"
   - Hoisted from "react-dom#schedule"
   - Hoisted from "react#schedule"