资讯专栏INFORMATION COLUMN

webpack 使用优化(一)

Caicloud / 2514人阅读

摘要:原因就是默认会把最重要的东西放到公共里,这里面包含启动应用程序的依赖项模块与模块的依赖关系以及文件的版本号等信息。

之前写了一篇关于webpack 如何使用的文章:webpack 单页面应用实战,并且写了一个 单页面应用的小项目 放到了github上。正巧公司前段时间用webpack 做了一个项目,项目不大,是基于单页面应用的。但是上线后才发现了一些问题,原来还是有一些要优化改进的地方。

webpack 单页面应用实战这篇文章基本已经满足了我们的需求。比如以下功能我们都已经实现:

将css从js中分离出来

使用loader加载css、图片等

使用插件生成html以便自动引用变更版本号的文件

配置公共js

js文件按需加载

配置开发环境

压缩js、css、html

给css、js、图片、字体等添加版本号

编译后自动打开浏览器

热替换

使用代理结合后端服务开发

编译时区分开发环境、生产环境、热替换环境

config 文件的合并

清空发布目录

看似不错,好像都已经实现了,但是具体到生产环境时还是有问题的。下面有几处优化(下面还是结合这个项目)。

优化-公共js版本号会变化的问题

这个问题在项目上线之前我没有发现,上线以后,有一次需求变化,我在改变其他js文件的时候,然后打包发布发现公共js的版本号发生了改变,最后检查下来,的确是公共js的内容发生了变化,所以对应的版本号发生了变化。原因就是webpack默认会把最重要的东西放到公共js里,这里面包含webpack启动应用程序的依赖项、模块与模块的依赖关系、以及文件的版本号等信息。所以一旦任意的js文件发生改变都会体现在公共js上。比如我们通过webpack构建后生成这样的文件:

再看下common.js 里大致包含什么内容(截取一小部分):

公共js版本号会变的问题在 github 上讨论了一段时间(点击这里),只不过之前没注意。有人用 webpack-md5-hash 插件实现了,但是感觉比较麻烦,最终还是感觉webpack 的贡献者实现的这种方式很简单,并且不需要额外的插件,在新版本的webpack中融合的很好。但是提供的这个demo太简单,在项目中我们还是要注意一些问题的。比如使用‘热替换’时就会报错。所以我们要做一些改变,我们只需要将之前配置公共js的地方:

// webpack.config.js
...
plugins:[
    // 会把 ‘entry’ 定义的 common 对应的两个js 打包为 ‘common.js’
    new webpack.optimize.CommonsChunkPlugin("common", "js/[name].js", Infinity),
]
...

改为:

// webpack.config.js
...
 new webpack.optimize.CommonsChunkPlugin(
        devServer ?
        {name: "common", filename: "js/common.js"}:
        {names: ["common", "webpackAssets"]}
    ),
...

注意: ‘devServer’ 是一个标识变量,代表‘热替换’ ,如有疑惑看上一篇配置变量标识

改成这种设置以后,当时热替换模式的时候不对common.js做处理,如果是开发模式或者发布模式,会从common.js中将各个文件的版本号以及其他重要信息抽出来,放到‘webpackAssets.js’文件中(名称可以自定义)。生成的文件如下,会多出一个文件,这个文件只有几kb:

改成这种做法后,一旦其他的文件发生改变,都会在webpackAssets.js文件中得到体现,项目的发布升级,只要额外的将这个文件升级上去即可,而不用将公共js升级上去。这样的优化会非常有利于处理缓存的问题。

优化-设置模块目录

如果项目小不设置webpack请求的模块目录没关系,但是一般项目越来越大,webpack会查找很多无用的文件,这时候设置模块目录很有必要性,可以提高webpack编译的速度。即设置 resolve.root 属性。还有一个属性是 moduleDirectories,这两个的区别可以点这里。resolve.root 接收的参数是 node_modules 文件加的绝对路径。我们在之前的webpack.config.js 中增加这个配置项:

// webpack.config.js
...
resolve:{
    root: [
        path.resolve("./node_modules")
    ],
    ...
}
...

这样设置后,webpack编译速度会大大加快,不会每个文件夹都搜索一遍。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/80167.html

相关文章

  • 浅谈webpack4.0 性能优化

    摘要:中在性能优化所做的努力,也大抵围绕着这两个大方向展开。因此,将依赖模块从业务代码中分离是性能优化重要的一环。大型库是否可以通过定制功能的方式减少体积。这又违背了性能优化的基础。接下来可以抓住一些细节做更细的优化。中,为默认启动这一优化。 前言:在现实项目中,我们可能很少需要从头开始去配置一个webpack 项目,特别是webpack4.0发布以后,零配置启动一个项目成为一种标配。正因为...

    leanxi 评论0 收藏0
  • webpack打包分析与性能优化

    摘要:打包分析与性能优化背景在去年年末参与的一个项目中,项目技术栈使用,生产环境全量构建将近三分钟,项目业务模块多达数百个,项目依赖数千个,并且该项目协同前后端开发人员较多,提高构建效率,成为了改善团队开发效率的关键之一。 webpack打包分析与性能优化 背景 在去年年末参与的一个项目中,项目技术栈使用react+es6+ant-design+webpack+babel,生产环境全量构建将...

    joy968 评论0 收藏0
  • webpack优化

    摘要:使用要给项目构建接入动态链接库的思想,需要完成以下事情把网页依赖的基础模块抽离出来,打包到一个个单独的动态链接库中去。接入已经内置了对动态链接库的支持,需要通过个内置的插件接入,它们分别是插件用于打包出一个个单独的动态链接库文件。 webpack优化 查看所有文档页面:全栈开发,获取更多信息。原文链接:webpack优化,原文广告模态框遮挡,阅读体验不好,所以整理成本文,方便查找。 ...

    ChanceWong 评论0 收藏0
  • webpack 基础与项目优化实践总结

    摘要:前言本文基于,主要涉及基本概念基本配置和实际项目打包优化。关于概念方面参考官网,常用配置来自于网络资源,在文末有相关参考链接,实践部分基于自己的项目进行优化配置。同一文件中,修改某个影响其他。 前言:本文基于weboack4.x,主要涉及webpack4 基本概念、基本配置和实际项目打包优化。关于概念方面参考官网,常用配置来自于网络资源,在文末有相关参考链接,实践部分基于自己的项目进行...

    Scorpion 评论0 收藏0
  • Webpack 最佳实践总结()

    摘要:它会代替所有的实例的值为,从而使知道那些判断表达式总是错误的,从而删除相关代码,进一步压缩打包文件模块机制项目中使用的,通过也能通过打包有用的代码,进一步减少大小。 好久没写文章,这次预计会带来3篇的 Webpack 系列文章,将会在这几天内更新完。 Webpack3 自今年6月20日正式发布而来,给我们带来Scope Hoisting和Magic Comments两大功能,可惜不在这...

    jubincn 评论0 收藏0

发表评论

0条评论

Caicloud

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<