Use the React Production Build

Instructor: [0:00] As developers, our tools can be our greatest assets. That is greater when measuring and working with performance in React applications, as working with the React DeveloperTools. I already have this in Chrome, but it does have extensions for other browsers. Look into that if you don't use Chrome as your browser.

[0:17] Once you install the Chrome extension, or whatever extension you need, you're going to see it pop up in your browser, up here at the top. When I click on the red button here for the React DeveloperTools, you'll notice that it says that this page is using the development build of React. The smaller your application code size is, the faster it's going to load in the browser.

[0:37] When working locally in the development mode, React is going to ship more of the React code base to help with hints of error loading, and giving us other little tidbits in our terminals. Though, when we work in a production environment, we don't need that stuff. React will strip everything that it doesn't necessarily need for a production application.

[0:58] I won't tell you how many applications I've seen in my life, production-ready applications, that still use the development build versus the production build up on their production server.

[1:12] I've gone ahead and reversed my mode that I've set for my WebPack bundler to bundle my application as is, but using the development mode for my React app. Notice that we're at a 677 kilobytes for our two-chunk file that we have here.

[1:32] If we go over to my WebPack config file, let's make some updates to the build script that runs. If you're using create React app and you haven't ejected, then React and create React app will do this for you.

[1:46] Though a lot of enterprise level applications that aren't built on create React app, or Next.js, or just bootstrapping React themselves and you have your own WebPack file like this webpack.config.js.

[2:00] Make sure that you're working with some environment variables that you can easily switch between development and production. As you can see, by switching this to production and rerunning our build, we're going to go from 677 kilobytes to a crazy smaller number.

[2:18] We've decreased 200 kilobytes of code from our entire application by simply compiling the production build for our React application. This is a very simple thing that you can do.

[2:32] You notice that I was changing some environment variables here to production for both Babble and Note inside of this build.js file. Ultimately, what is happening is it's being called into our webpack.config.js file.

[2:46] On WebPack, you can set a mode. This is where we're going to conditionally set either production or development, depending on some variables, like we had before. This mode is how WebPack differentiates between a bundled, minified production build, versus the development build.

[3:04] That entire 200 kilobytes of data is not simply just from the React, but it's also going through and loading additional plugins within WebPack, to make sure that we're using development packages, but also minifying our entire code as it is.

[3:19] If you're not using WebPack, that's OK. There are many different bundlers, and they all have similar modes or configurations within them to make sure you're using the correct build.

[3:28] To recap, make sure you go through your application today. If you're not using create React app and you haven't ejected, then you're fine.

[3:35] If you're bootstrapping your own React application, working with your own webpack.config.js file, or whatever config file you might use for your WebPack, or Parcel, or any other bundler, make sure that you're using the production build when it goes out to your production server, and not bundling the DevBuild.