“This is the 13th day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021”

Webpack performance optimization

You learned earlier that WebPack is a build tool, and then you can use WebPack to improve performance. Why and how performance can be improved has never been understood. Once in the interview, I was awkwardly asked by the interviewer. This article is a brief introduction to webPack performance optimization.

Performance optimization for WebPack can be divided into two main parts.

  • Development environment performance optimization
  • Production environment performance optimization

1. Performance optimization of development environment

  1. Optimize packaging build speed
  • HMR

HMR: Hot module replacement HMR: Hot module replacement What it does: When a module changes, only that module is repackaged (instead of all modules), which can greatly improve build speed

  • Style files: you can use the HMR function: because style-loader implements ~ internally
  • Js file: HMR function cannot be used by default –> Need to modify js code, add code supporting HMR function
  • Note: the HMR function can only handle other files that are not entry JS files.
  • HTML files: the HMR function is disabled by default. It also causes problems: HTML files cannot be hot updated.
  • Solution: Modify the entry entry to import the HTML file
  devServer: {
    contentBase: resolve(__dirname, 'build'),
    compress: true.port: 3000.open: true.// Enable HMR
    // When the WebPack configuration is changed, the webpack service must be restarted for the new configuration to take effect
    hot: true
  }
Copy the code
  1. Optimized code debugging
  • source-map

Source-map: a technique that provides source-to-build-code mapping (mapping to trace source code errors if errors are made after a build)

The difference between inline and external:

  1. External generated file, inline not
  2. Inline builds are faster

Development environment: fast, debug friendly fast (eval>inline> Cheap >…) Eval-cheap-souce-map Eval-source-map debugging is more friendly souce-map cheap-module-souce-map cheap-souce-map

eval-source-map / eval-cheap-module-souce-map

Production environment: Should source code be hidden? Inline will make the code bigger, so don’t use inline nosource-source-map to hide everything in production. Hidden-source-map will only hide the source code, prompting post-build code error messages

source-map / cheap-module-souce-map

devtool: 'eval-source-map'
Copy the code

Second, production environment performance optimization

  • Optimize packaging build speed
    • oneOf
    • Babel cache
    • Multi-process packaging
    • externals
    • dll
  • Optimize the performance of code execution
    • Cache (hash – chunkhash – contenthash)
    • tree shaking
    • code split
    • Lazy loading/preloading
    • pwa

Cache: Babel cache

cacheDirectory: true  
Copy the code

Make the second package build faster

File resource cache Hash: A unique hash value is generated for each Wepack build. Problem: Because JS and CSS use the same hash value. If repackaged, all caches will be invalidated. Chunkhash: Hash value generated by chunk. If the package comes from the same chunk, the hash value is the same. Problem: JS and CSS hash values are the same. Because CSS is introduced in JS, it belongs to the same chunk contenthash: Generates hash values based on the contents of the file. Different files must have different hash values

Make the code run online and cache easier to use