浅谈webpack性能榨汁机(打包速度优化)

最近对项目的本地开发环境进行了打包速度优化,原有项目,网上能搜到的优化方案基本都加了,在16年低配mac pro 上打包时间为25秒多,但我发现细节做一些调整可能大大降低打包时间,最终优化到7秒多

dll

原有项目是线上和本地公用一套dll配置,因为antd这类ui库需要按需加载所以不能放到dll中,这时可以单独写一个dll配置,将所有第三方库添加到dll中。

这时因为.babelrc中添加了babel-plugin-import插件会导致优化不生效,所以需要对开发环境单独配置babel

options的babelrc设置为false,然后重写一份babel配置,一定不要添加“import”插件

一个新问题,因为没有import插件,导致所有antd组件样式丢失。这时我在index-template.html中加入一行注释<!-- local-style -->,在本地打包时将其替换为antd相应版本在cdn上的css文件

缓存

cache-loader专治花里胡哨!虽然你能在webpack的配置里找到n种缓存设置,但我发现cache-loader可以替代其它选项,它会在你的项目中创建一个 .cache-loader的文件夹,里面存放缓存文件,因为是直接写入硬盘,所以第一次打包的时候会多消耗几秒

babel-loader & 多线程

上面的图中可以看到我将babel-loader升级到8+,新的preset和plugin都有了命名上的变化。preset-env是用来替代以前201X的,通过targets可以指定目标代码(编译后代码)的版本,因为是本地开发,可以指定到chrome的高版本,这样很多新语法都不需要转换,可以节省一点时间(打包速度在10秒以下之后减一秒都是10%的提升啊!)不过这个方案要慎重使用,因为会造成线上本地环境不统一,难保不出现什么神奇的bug

拔掉HappyPack提升性能

在测试的过程中我发现一个神奇的事情,就是HappyPack反倒会降低打包时间,我经过反复测试,似乎babel-loader8+自带了多线程优化,所以HappyPack已经没用了(反而因为线程通信造成了资源浪费)。babel-loader8+的cpu使用率以及打包时间和babel-loader6+加HappyPack是相差不多的,但我在google上搜索时并没有看到有人提及此事,官网也没看到有个说明(管他那么多呢,能提升速度就行啦!)

后续计划

这个项目是两个人迭代一年份的代码量,按照上面的配置大部分项目应该都可以优化到10秒左右的速度(看项目大小,20秒以下应该都是正常的),还有一些小的优化细节对性能影响不大所以忽略掉了。目前webpack还是3+版本,因为4的一些变化担心影响过大,暂时没升级,升级之后应该还会有一些小提速
这7秒还不是最终的速度,我估计5秒应该没啥问题,后面再想优化就需要脑洞大开了

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • webpack4.0打包优化策略整理小结

    本文介绍了webpack4.0打包优化策略整理小结,分享给大家,具体如下: webapck4 新特性介绍-参考资料 当前依赖包的版本 1.优化loader配置 1.1 缩小文件匹配范围(include/exclude) 通过排除node_modules下的文件 从而缩小了loader加载搜索范围 高概率命中文件 module: { rules: [ { test: /\.js$/, use: 'babel-loader', exclude: /node_modules/, // 排除不处理的目录

  • vue webpack打包优化操作技巧

    临近春节,公司很多同事都提前回家过年,剩余人员根据禅道去修改bug,当bug修正完毕以后,我们需要重新打包给运维,上测试服给测试同事提测,但是由于项目本体比较庞大,所以打包时间太过漫长(二十五分钟以上:sob:),所以有了打包优化的想法(其实想法早就有了,但是因为平时工作计划比较充实,所以一直没有去完成这个工作),这次正好有时间,所以去重新考虑了这个问题! webpack是react项目标配的打包工具,和NPM搭配起来使用管理模块实在非常方便.   webapck 把所有的静态资源都看做是一个

  • 浅谈React + Webpack 构建打包优化

    本文介绍了React + Webpack 构建打包优化,分享给大家,具体如下: 使用 babel-react-optimize对 React 代码进行优化 检查没有使用的库,去除 import 引用 按需打包所用的类库,比如 lodash . echart 等 lodash 可以采用babel-plugin-lodash进行优化. 需要注意的是 在 babel-react-optimize 中使用了 babel-plugin-transform-react-remove-prop-types 这

  • vue-cli webpack2项目打包优化分享

    减小文件搜索范围 配置 resolve.modules Webpack的resolve.modules配置模块库(即 node_modules)所在的位置,在 js 里出现 import 'vue' 这样不是相对.也不是绝对路径的写法时,会去 node_modules 目录下找.但是默认的配置,会采用向上递归搜索的方式去寻找,但通常项目目录里只有一个node_modules,且是在项目根目录,为了减少搜索范围,可以直接写明 node_modules 的全路径:同样,对于别名(`alias)的配置

  • 浅谈Webpack打包优化技巧

    前端的打包工具从之前的browserify.grunt.gulp到现如今的rollup.webpack,涌现出了很多优秀的打包工具,而目前最火的无疑是webpack,无论是当前热门的框架还是工具库很多都选择了它作为打包工具,因此在开发中webpack作为打包工具是一个很好的选择.在最近的项目开发中我也用到了webpack,其中也碰到了不少优化方面的问题,这里总结一下webpack打包优化的一些细节和方法. 首先,这次项目用到的是vue的全家桶,在webpack的配置方面直接用的是 vue-cli

  • webpack dll打包重复问题优化的解决

    关于webpack dll的使用,我这里不做过多介绍,网上都有,一撸一大把,今天我要说的是在使用dll plugin过程中出现的一个包依赖问题,这个问题导致打出来的包会包含重复的代码. 优化背景 最近在给公司项目优化的时候,由于 内部CDN上传文件大小限制了500K ,所以用了webpack dll来进行拆分打包,我将拆分的包分为三部分: vue生态包( vue . vuex . vue-router . vuex-class . vue-class-component 等周边生态的库) vue

  • 浅谈webpack性能榨汁机(打包速度优化)

    最近对项目的本地开发环境进行了打包速度优化,原有项目,网上能搜到的优化方案基本都加了,在16年低配mac pro 上打包时间为25秒多,但我发现细节做一些调整可能大大降低打包时间,最终优化到7秒多 dll 原有项目是线上和本地公用一套dll配置,因为antd这类ui库需要按需加载所以不能放到dll中,这时可以单独写一个dll配置,将所有第三方库添加到dll中. 这时因为.babelrc中添加了babel-plugin-import插件会导致优化不生效,所以需要对开发环境单独配置babel opt

  • 浅谈C++性能榨汁机之伪共享

    前言 在多核并发编程中,如果将互斥锁的争用比作"性能杀手"的话,那么伪共享则相当于"性能刺客"."杀手"与"刺客"的区别在于杀手是可见的,遇到杀手时我们可以选择战斗.逃跑.绕路.求饶等多种手段去应付,但"刺客"却不同,"刺客"永远隐藏在暗处,伺机给你致命一击,防不胜防.具体到我们的并发编程中,遇到锁争用影响并发性能情况时,我们可以采取多种措施(如缩短临界区,原子操作等等)去提高程序性能,

  • 浅谈Webpack是如何打包CommonJS的

    目录 一.书写代码 二.使用webpack打包编译 三.解析 CommonJS 是 Node 中的一种模块化规范,其是一种运行在 Node 环境下的代码,这种代码是不能直接运行到浏览器环境中的.但是在日常使用 webpack 的项目中不用做额外的处理,我们也能使用 CommonJS 来书写代码,那么 webpack 在这背后做了什么呢? 我们这里不看编译时,只看运行时 一.书写代码 使用yarn init -y命令初始化一个package.json文件. 接着yarn add webpack安装

  • 浅谈webpack打包之后的文件过大的解决方法

    以前一直使用 create-react-app 这个脚手架进行 react 开发,后面因为一些自定义的配置,转而使用 webpack 搭建一套自己的脚手架.但是在使用 webpack 打包之后发现,纳尼?怎么文件这么大??? 于是研究了一下如何处理 webpack 打包之后文件太大的情况,简单记录下来. 首先配置全局变量 首先,通过指定环境,告诉 webpack 我们当前处于 production 环境中,要按照 production 的方式去打包. //指定环境,将process.env.NO

  • 浅谈PHP性能优化之php.ini配置

    内存 默认设置 memory_limit = 128M 单个进程可使用的内存最大值,这个值的设定可以从以下几点考虑: 应用的类型.如果是内存集中型应用,可增加该值: 单个 PHP 进程平均消耗的内存,该值可通过多次运行同一个脚本来计算平均值: 能负担多少个 php-fpm 进程:该值等于分配的总内存除以单个 PHP 进程平均消耗的内存: 文件上传 默认设置 file_uploads = On max_file_uploads = 20 upload_max_filesize = 2M max_e

  • 浅谈Android性能优化之内存优化

    1.Android内存管理机制 1.1 Java内存分配模型 先上一张JVM将内存划分区域的图 程序计数器:存储当前线程执行目标方法执行到第几行. 栈内存:Java栈中存放的是一个个栈帧,每个栈帧对应一个被调用的方法.栈帧包括局部标量表, 操作数栈. 本地方法栈:本地方法栈主要是为执行本地方法服务的.而Java栈是为执行Java方法服务的. 方法区:该区域被线程共享.主要存储每个类的信息(类名,方法信息,字段信息等).静态变量,常量,以及编译器编译后的代码等. 堆:Java中的堆是被线程共享的,

  • 浅谈android性能优化之启动过程(冷启动和热启动)

    本文介绍了浅谈android性能优化之启动过程(冷启动和热启动) ,分享给大家,具体如下: 一.应用的启动方式 通常来说,启动方式分为两种:冷启动和热启动. 1.冷启动:当启动应用时,后台没有该应用的进程,这时系统会重新创建一个新的进程分配给该应用,这个启动方式就是冷启动. 2.热启动:当启动应用时,后台已有该应用的进程(例:按back键.home键,应用虽然会退出,但是该应用的进程是依然会保留在后台,可进入任务列表查看),所以在已有进程的情况下,这种启动会从已有的进程中来启动应用,这个方式叫热

  • 浅谈webpack打包生成的bundle.js文件过大的问题

    问题 使用webpack进行打包时,发现bundle.js竟然有2M多. 解决办法 网上有去除插件.提取第三方库.压缩代码等方法. 还有一个比较容易忽略的原因就是开了sourcemap 在生产环境中,应使用devtool: false 关闭sourcemap后bundle.js的大小从2.46M降到302k 以上这篇浅谈webpack打包生成的bundle.js文件过大的问题就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持我们. 您可能感兴趣的文章: 彻底解决 webpa

  • 浅谈webpack打包过程中因为图片的路径导致的问题

    最近在制作一个自己的个人博客的时候遇到这么一个问题, 在CSS中使用了相对路径来充当背景图片, 如下所示: 然后将整个工程使用webpack打包之后, 在浏览器上运行却报错了, 报错如下: 也就是说, 打包之后这个图片文件找不到了, 那么原因出在哪里呢? 先来看一下我在webpack.config.js文件中的配置: 在这里其实我的loader并没有使用错误的, 图片对应的就是使用url-loader来处理. 那么再来看一下通过webpack打包之后的目录: 发现dist文件夹中出现了我们想要打

  • 浅谈vue首屏加载优化

    本文介绍了浅谈vue首屏加载优化,分享给大家,具体如下: 库使用情况 vue vue-router axios muse-ui material-icons vue-baidu-map 未优化前 首先我们在正常情况下build 优化 1. 按需加载 当前流行的UI框架如iview,muse-ui,Element UI都支持按需加载,只需稍微改动一下代码. 修改前: import MuseUI from 'muse-ui' import 'muse-ui/dist/muse-ui.css' imp

随机推荐