Webpack的性能优化有哪些

• 实现按需加载，通过用户的一些操作作为触发时机，如react-router按需加载的触发条件是路由发生变化

• 公共代码提取(webpack.optimization):相同的资源被重复的加载,浪费用户的流量和服务器的成本; 每个页面需要加载的资源太大，导致页面首屏加载缓慢，影响用户体验。

• 压缩文件js、css：parallel-uglify-plugin使用多线程压缩Js,不能和uglify.js混用。

• 接入CDN：网站接入CDN，需要将网页的静态资源上传到CDN服务器，使用CDN地址访问。hash一般是结合CDN缓存来使用，通过webpack构建之后，生成对应文件名自动带上对应的MD5值。如果文件内容发生改变的话，那么对应文件hash值也会改变，对应的HTML引用的URL地址也会改变，触发CDN服务器从原服务器上拉取对应数据，进而更新本地缓存。但是实际使用时，这三种hash计算还是有一定区别。（hash、chunkhash、contenthash）

  • contenthash表示由文件内容产生的hash值，内容不同产生的contenthash值也不一样。在项目中，通常做法是把项目中css都抽离出对应的css文件来加以引用。

  • chunkhash和hash不一样，它根据不同的入口文件(Entry)进行依赖文件解析、构建对应的chunk，生成对应的hash值。我们在生产环境里把一些公共库和程序入口文件区分开，单独打包构建，接着我们采用chunkhash的方式生成hash值，那么只要我们不改动公共库的代码，就可以保证其hash值不会受影响。

  • hash是跟整个项目的构建相关，构建生成的文件hash值都是一样的，所以hash计算是跟整个项目的构建相关，同一次构建过程中生成的hash都是一样的，只要项目里有文件更改，整个项目构建的hash值都会更改。

    如果出口是hash，那么一旦针对项目中任何一个文件的修改，都会构建整个项目，重新获取hash值，缓存的目的将失效。

• 开启gzip压缩：开启gzip压缩可以有效压缩资源体积，压缩比率在3到10倍左右，可以大大节省服务器的网络带宽，提高资源获取的速度，但需要注意的是：并不是经过gzip压缩之后，所有文件都会变小。根据gzip使用的算法特性，代码相似率越大压缩效率越高

• 接入treeShaking,剔除无用代码：可以用来找出有用的代码，去除JavaScript用不上的死代码；但是它依赖于ES6静态模块语法（import\export的导入导出）

• 开启Scope Hoistion:Scope hoising即作用域提升；在构建过程中，webpack会借助ES6模板化的静态特性，确定模块的依赖关系,将一个bundle中的静态依赖提升到顶部。（所以需要和接入treeShaking一样配置Bable开启ES6模板化）

  • 原理：分析模块间的依赖关系，尽可能的将零散的模块合并到一个函数中去，前提不能造成代码冗余，因此只有被引用了一次的模块才能被合并。
  • 好处：代码体积减小、代码运行时因为创建的函数作用域更小了，内存开销也随之减小。

1、有哪些常见的Loader？他们是解决什么问题的？

• file-loader：把文件输出到一个文件夹中，在代码中通过相对 URL 去引用输出的文件
• url-loader：和 file-loader 类似，但是能在文件很小的情况下以 base64 的方式把文件内容注入到代码中去
• source-map-loader：加载额外的 Source Map 文件，以方便断点调试
• image-loader：加载并且压缩图片文件
• babel-loader：把 ES6 转换成 ES5
• css-loader：加载 CSS，支持模块化、压缩、文件导入等特性
• style-loader：把 CSS 代码注入到 JavaScript 中，通过 DOM 操作去加载 CSS。
• eslint-loader：通过 ESLint 检查 JavaScript 代码

2、有哪些常见的Plugin？他们是解决什么问题的？

• define-plugin：定义环境变量
• commons-chunk-plugin：提取公共代码
• uglifyjs-webpack-plugin：通过UglifyES压缩ES6代码

3、Loader和Plugin的不同？

不同的作用

• Loader直译为”加载器”。Webpack将一切文件视为模块，但是webpack原生是只能解析js文件，如果想将其他文件也打包的话，就会用到loader。 所以Loader的作用是让webpack拥有了加载和解析非JavaScript文件的能力。
• Plugin直译为”插件”。Plugin可以扩展webpack的功能，让webpack具有更多的灵活性。 在 Webpack 运行的生命周期中会广播出许多事件，Plugin 可以监听这些事件，在合适的时机通过 Webpack 提供的 API 改变输出结果。

不同的用法

• Loader在module.rules中配置，也就是说他作为模块的解析规则而存在。 类型为数组，每一项都是一个Object，里面描述了对于什么类型的文件（test），使用什么加载(loader)和使用的参数（options）
• Plugin在plugins中单独配置。 类型为数组，每一项是一个plugin的实例，参数都通过构造函数传入

4、如何利用webpack来优化前端性能？（提高性能和体验）

用webpack优化前端性能是指优化webpack的输出结果，让打包的最终结果在浏览器运行快速高效。

• 压缩代码。删除多余的代码、注释、简化代码的写法等等方式。可以利用webpack的UglifyJsPlugin和ParallelUglifyPlugin来压缩JS文件， 利用cssnano（css-loader?minimize）来压缩css
• 利用CDN加速。在构建过程中，将引用的静态资源路径修改为CDN上对应的路径。可以利用webpack对于output参数和各loader的publicPath参数来修改资源路径
• 删除死代码（Tree Shaking）。将代码中永远不会走到的片段删除掉。可以通过在启动webpack时追加参数–optimize-minimize来实现
• 提取公共代码。

5、webpack热更新的原理。

首先要知道server端和client端都做了处理工作

1. 第一步，在 webpack 的 watch 模式下，文件系统中某一个文件发生修改，webpack 监听到文件变化，根据配置文件对模块重新编译打包，并将打包后的代码通过简单的 JavaScript 对象保存在内存中。
2. 第二步是 webpack-dev-server 和 webpack 之间的接口交互，而在这一步，主要是 dev-server 的中间件 webpack-dev-middleware 和 webpack 之间的交互，webpack-dev-middleware 调用 webpack 暴露的 API对代码变化进行监控，并且告诉 webpack，将代码打包到内存中。
3. 第三步是 webpack-dev-server 对文件变化的一个监控，这一步不同于第一步，并不是监控代码变化重新打包。当我们在配置文件中配置了devServer.watchContentBase 为 true 的时候，Server 会监听这些配置文件夹中静态文件的变化，变化后会通知浏览器端对应用进行 live reload。注意，这儿是浏览器刷新，和 HMR 是两个概念。
4. 第四步也是 webpack-dev-server 代码的工作，该步骤主要是通过 sockjs（webpack-dev-server 的依赖）在浏览器端和服务端之间建立一个 websocket 长连接，将 webpack 编译打包的各个阶段的状态信息告知浏览器端，同时也包括第三步中 Server 监听静态文件变化的信息。浏览器端根据这些 socket 消息进行不同的操作。当然服务端传递的最主要信息还是新模块的 hash 值，后面的步骤根据这一 hash 值来进行模块热替换。
5. webpack-dev-server/client 端并不能够请求更新的代码，也不会执行热更模块操作，而把这些工作又交回给了 webpack，webpack/hot/dev-server 的工作就是根据 webpack-dev-server/client 传给它的信息以及 dev-server 的配置决定是刷新浏览器呢还是进行模块热更新。当然如果仅仅是刷新浏览器，也就没有后面那些步骤了。
6. HotModuleReplacement.runtime 是客户端 HMR 的中枢，它接收到上一步传递给他的新模块的 hash 值，它通过 JsonpMainTemplate.runtime 向 server 端发送 Ajax 请求，服务端返回一个 json，该 json 包含了所有要更新的模块的 hash 值，获取到更新列表后，该模块再次通过 jsonp 请求，获取到最新的模块代码。这就是上图中 7、8、9 步骤。
7. 而第 10 步是决定 HMR 成功与否的关键步骤，在该步骤中，HotModulePlugin 将会对新旧模块进行对比，决定是否更新模块，在决定更新模块后，检查模块之间的依赖关系，更新模块的同时更新模块间的依赖引用。
8. 最后一步，当 HMR 失败后，回退到 live reload 操作，也就是进行浏览器刷新来获取最新打包代码。