为什么使用webpack多入口配置时热加载变得如此缓慢？
- 内容介绍
- 相关推荐
本文共计630个文字，预计阅读时间需要3分钟。
之前为公公司搭建了一套webpack多页面应用脚手架，起初用得顺滑，资源整合打包，组件化开发，各种组件复用，需要什么就拿什么。后来入口接入了50个页面，慢慢发现每次保存后都要热更新。
之前为公司搭建了套webpack多页面应用脚手架，起初用得挺爽，资源整合打包，组件化开发，各种组件复用，需要什么就拿什么，后来入口有50个页面了，慢慢的发现了每次按保存后的热加载等待时间越来越长，需要等待10几秒，实在太影响开发效率，于是我查找原因。
观察发现，每次到热加载时会在emitting HtmlWebpackPlugin这停留很久。
于是我想知道它到底停留了多长时间呢？
在package.json内加入--profile，它会告诉你编译过程中哪些步骤耗时最长。
停止npm，重新运行webpack-dev-server，修改下文件按保存，观察控制台，发现总花费时长为15035毫秒，在emitting就花费了13239毫秒，这emitting应该就是指上面的图片的emitting HtmlWebpackPlugin了，看来我们解决HtmlWebpackPlugin，热加载速度就能恢复正常了。
HtmlWebpackPlugin就是我们入口对应的的html页面，new的页面越多，热加载速度就会越慢。
我尝试注释掉所有html页面，只留下一个案例详情html页面，重新启动webpack-dev-server，修改文件按下保存，发现速度惊人，只用了772毫米，看来问题出在html-webpack-plugin这个插件上。
本文共计630个文字，预计阅读时间需要3分钟。
之前为公公司搭建了一套webpack多页面应用脚手架，起初用得顺滑，资源整合打包，组件化开发，各种组件复用，需要什么就拿什么。后来入口接入了50个页面，慢慢发现每次保存后都要热更新。
之前为公司搭建了套webpack多页面应用脚手架，起初用得挺爽，资源整合打包，组件化开发，各种组件复用，需要什么就拿什么，后来入口有50个页面了，慢慢的发现了每次按保存后的热加载等待时间越来越长，需要等待10几秒，实在太影响开发效率，于是我查找原因。
观察发现，每次到热加载时会在emitting HtmlWebpackPlugin这停留很久。
于是我想知道它到底停留了多长时间呢？
在package.json内加入--profile，它会告诉你编译过程中哪些步骤耗时最长。
停止npm，重新运行webpack-dev-server，修改下文件按保存，观察控制台，发现总花费时长为15035毫秒，在emitting就花费了13239毫秒，这emitting应该就是指上面的图片的emitting HtmlWebpackPlugin了，看来我们解决HtmlWebpackPlugin，热加载速度就能恢复正常了。
HtmlWebpackPlugin就是我们入口对应的的html页面，new的页面越多，热加载速度就会越慢。
我尝试注释掉所有html页面，只留下一个案例详情html页面，重新启动webpack-dev-server，修改文件按下保存，发现速度惊人，只用了772毫米，看来问题出在html-webpack-plugin这个插件上。