This article is part of my React Primer and Best Practices series on Getting Started with Web Front-end and Best Practices. This article starts with a few simple steps to help you optimize the React application package body – a bear’s full stack path – SegmentFault.

Bundle Size

In front end projects, especially in mobile environments, we are particularly concerned about user loading speed. One of the limitations of loading speed is the number of concurrent connections. Due to the HTTP 1.1 protocol, the browser has a certain limit on the number of concurrent connections. However, we can use module packaging tools such as Webpack to package modules into a file (such as Webpack2 React Redux Boilerplate). Another problem is that the package size is too large when the first screen loads. This chapter focuses on optimizing the package size after the React project is packaged and compiled. Let’s take a look at the package size without any optimization, that is, the package size in the development environment:

Modules Analysis

Before optimization, we first need to know the module composition of our package body and whether there are some modules that can be loaded asynchronously. Here, the author can use the module list provided with Webpack Dashboard:

Here we see ECharts taking a larger share of the pie, but in fact ECharts supports chart modules that do not need to be displayed on the first screen, but are displayed after the user clicks, so such modules can be loaded asynchronously. Alternatively, we can use the specialized Webpack Stats Analyzer tool for analysis:

Add the appropriate plug-ins

plugins: [
    new webpack.DefinePlugin({ // <-- key to reducing React's size
      'process.env': {
        'NODE_ENV': JSON.stringify('production')
      }
    }),
    new webpack.optimize.DedupePlugin(), //dedupe similar code 
    new webpack.optimize.UglifyJsPlugin(), //minify everything
    new webpack.optimize.AggressiveMergingPlugin()//Merge chunks 
  ],
Copy the code

After adding these plug-ins, the package size can be significantly reduced:

Use GZip compression

Take a look at the effect first, and it’s obvious:

Compile time compression

npm install compression-webpack-plugin --save-dev plugins: [ new webpack.DefinePlugin({ 'process.env': { 'NODE_ENV': JSON.stringify('production') } }), new webpack.optimize.DedupePlugin(), new webpack.optimize.UglifyJsPlugin(), new webpack.optimize.AggressiveMergingPlugin(), new CompressionPlugin({ <-- Add this asset: "[the path]. Gz [query]", the algorithm: "gzip" test: / \. Js $| \. CSS $| \. HTML $/, threshold: 10240, minRatio: 0.8})]Copy the code

Finally, we need to set up Express for appropriate path forwarding:

app.get('*.js', function (req, res, next) {
  req.url = req.url + '.gz';
  res.set('Content-Encoding', 'gzip');
  next();
});
Copy the code

Dynamic Gzip

The author uses Express to build server-side rendering service, and can add compression plug-in:

//Simply do this to add dynamic gzipping (not preferred) npm install compression --save //install var compression = Require (" compression will "); //import to express app app.use(compression()); //add this as the 1st middlewareCopy the code

The downside of this approach, however, is that it increases the server load at run time, so it is not recommended.