前端代码打包优化

前端资源打包在每个项目中都会有涉及,每位开发者都希望打包是用最少的时间构建出最小的代码,这不仅能提高团队中的效率,也能提高页面的访问性能,以下会从如何优化构建速度和优化构建输出代码来说明一些方法。

图片来自webpack官网log

1. 速度优化

日常开发打包配置大家都是习惯用脚手架等的默认配置,没问题,没毛病,跑的好好的,就没这么在意。对于一些强迫症的患者,还是会有点不爽的, 比如速度,比如最终打包出来的资源大小等等。

1.1 本地构建或者服务端构建

1.1.1 本地构建

开发完后本地构建,然后通过push到cnd同步资源。可能是传统大家喜欢做的思路,没毛病,也挺好用的。

不足点:加重了仓库的体积,对于仓库中的语义化的npm包,本地构建不能实时享受到包的更新。

优点: 适合于多人项目合作初期,或者依赖的一个三方包也处于一个不断迭代的过程,每个人开发的过程中仅仅打包自己的页面,互相不干扰

1.1.2 服务端构建

服务端构建,大致就是当资源push的时候,会在一台构建机器上面跑类似ci的服务,同时也会有打包的服务

优缺点基本就是本地的相反,但是还是比较推荐这样的方案

1.2 如何来优化

1.2.1 配置差异化

粗暴点其实大家可能希望这个配置可以自动化生成,而且可以仅有一份来做,思路是没错,但是其实应该做一些区分


功能

本地开发

线上发布

压缩代码
 
需要

babel-polyfill

一般不需要

看业务需求

分离样式
 
需要

删除console.log
 
需要

css Prefix
 
需要

OccurrenceOrderPlugin
 
需要

DedupePlugin
 
需要

Babel present转码
 
需要

其实比较合理的方式应该是用环境变量来区分进行不同环境下不同的配置,ps:设置环境变量为了在window兼容,可以使用cross-env 来设置

以上的对比没有进行测试,感兴趣的同学可以试试看,在老的基础上修改会有多少的优化。

总结起来就是本地开发只求速度快,能少处理一点是一点

1.2.2 常见方式

可以在社区中看到很多相关类似的文章来做webpack的优化,各种各样的提速,可能都知道,但是懒得做,但其实一旦完成后,带来的受益是巨大的。

externals

这可能是最暴力最提速的方法之一,把其中的一些库从中忽略掉,如果extern react了,需要注意的是最好把相关的一些react-addons-transition-group也给extern掉,否则有可能会出现依然打入多份react的问题,因为react-addons-transition-group这样的包里面代码是类似如下方式,externals并不能排除

module.exports = require(‘react/lib/ReactTransitionGroup‘);

Dll

将一些可预见性的库从中抽离,预打包,可以极大的提速,当时还是有蛮多需要注意的,比如同样的包最好全局只有一份,预打包后不能享受到语义化版本的资源跟新,需要结合实际问题来看是否需要。

HappyPack

常用套路加速

const os = require(‘os‘);

HappyPack.ThreadPool({size: os.cpus().length })

一些配置

设置一些alias,同时可以适当设置一些loaders中的exclude等

设置css-loader版本号

提速特别明显

"css-loader": "^0.14.5",

相关Issue

替换scss-loader 为fast-sass-loader

相比起来比scss-loader速度更快

不用webpack自带的uglfiyJS

用自带的uglfiyJS来做压缩速度比较慢,这边有俩思路,但原理应该是一样的

  1. webpack-uglify-parallel
  2. 造个新轮子多核并行去压缩js和css

这个方案优化一般来说可以提速一半左右

js和scss的分离

这个可以优化本地开发过程中的rebuild速度,尽量让scss文件和js文件分离,如果使用了一些ui库,可以引用UI库的css文件,而不是scss文件,省去每次的scss build过程

1.3 其他

  1. 对于打包webpack可能是一个功能大而全的工具,除此之外还有很多类似于rollup或者是browserify,要看具体场景来使用,杀鸡可能选个更合适的刀会更好,不要盲目选择都是用一把刀。后续待尝试后详细再补相关的一些其他打包方案。
  2. 优化永无止境

2. 代码优化

2.1 精简node_modules

现在开发基本都是使用npm或者yarns进行依赖管理,随便引入几个依赖就会使得最终打包的结构臃肿,再加上开发者可能对依赖的包并没有特别统一管理,需要什么就引入什么,不会去关心互相之间的关系。

上图仅仅是说明node_modules管理的时候出现的包的量一个图,可以说是非常的形象。图片来自文章What’s really wrong with node_modules and why this is your fault,文章推荐一看

注:npm包开发者应该保证包里面仅只有需要的代码,比如测试等等的资源最好都忽略掉,这样也可以省去不少开支,细节后续会整理一篇新的文章。

2.1.1 方法1:同样功能使用同样的包

多人开发常会遇到使用三方库,部分人使用deep-extend,但是后面可能又有人用lodash,这样一来一回,会出现同样功能的包会引用多个的问题。对于这个情况不会导致bug,但是会造成node_modules增多且package.json依赖混乱,当然代码大小也会有相应的损失。

解决方式

查看仓库的package.json,比如

{
    "deep-extend": "^0.4.1",
    "lodash.clonedeep": "^4.5.0",
}

如上俩个库都是想做深拷贝,可以选择只使用其一即可,推荐

2.1.2 方法2:同一个包尽量不存在多个版本

大部分情况这样仅只会加重代码的体积等,但是在少数的场景下,比如使用了前端组件库;

举个例子,项目中依赖了俩组件A和B,A依赖了某UI库C的1.0.0的input,而B依赖了C中的2.0.0的input,最终页面上会同时存在俩版本的input,这里存在一个隐患(如果俩组件有Dom节点结构调整发生样式变化,这个时候无论是使用1.0.0或者是2.0.0的样式其实都不合适),所以这个问题也需要多关注的,特别是前端的UI库,最好习惯性的排查下较为好。必须最好做下

解决方式

打开chrome调试工具,查看node_modules,对于UI的库,仔细翻翻,不能有多版本的库,对于其他库则可以佛系排查;如果发现某个库A出现了多次,可以使用npm ls A来查看是在什么地方多次引用到了,然后再定位到具体细节的包查看

2.1.3 方法3:分析代码依赖

使用webpack的使用BundleAnalyzerPlugin或者是用自带的功能输出json,进行分析,排查为什么最后输出的资源这么大的原因

2.2 抽离公用资源

比较适合那些整站的开发,将各个页面公用的资源抽离出来,这样在页面的访问过程中浏览器可以很好的将这些通用资源缓存,类似使用dll存在本地工程中,还可以使得打包加速,下面以dll为例

做法

  1. 配置好项目所要打的dll资源,一般选择的是一些三方的库,具体看项目的需求
  2. 预先打好dll的资源放到项目的某个自定目录中(甚至可以直接打成生产环境的版本省去后续的压缩)
  3. 本地构建或者服务端构建任务结束后,将打好的dll资源拷贝到build目录下面

注意点

  1. 如果使用服务端构建请务必保持本地的npm版本和服务端构建上面的版本一致,不同的npm的版本可能会导致manifest.json的里面内容不一致,因为dll存的是路径
  2. 最好解决下同一个库多版本的问题,否则dll中就会打进去多版本的库,因为dll存路径不同的版本的版本号是不一致的

2.3 其他

2.3.1 使用babel-preset-env

官方也是推荐使用它来代替babel-preset-2015,根据业务所需要适配的浏览器去选择合适的,否则使用多余的转码会是的代码转码后更大,同时对于browsers的设置,也可以跟postCss进行统一

2.3.2 区分好大包小包的问题

一些组件库或者是lodash

import { isEmpty } from ‘lodash‘;

import isEmpty from ‘lodash/isEmpty‘;

所产生的结果是不一样的。除非使用一个转码的工具来支持;vscode用户建议装一个Import Cost

2.3.3 升级打包工具webpack

升级到webpack3,有tree shaking、Scope Hoisting都对代码有着不错的优化

2.3.4 优化样式

  1. prefix这类的工作交给postCss来完成,同样是根据业务的需求去做相关的prefix的处理,不多不少
  2. 精简样式,去除没必要的样式

原文地址:https://www.cnblogs.com/winyh/p/9183263.html

时间: 2024-10-09 21:43:39

前端代码打包优化的相关文章

关于前端代码性能优化问题

以下观点纯属个人看法: 对于一个刚接触前端不久的人来说,前端的代码质量是很重要的一部分,毕竟关系到性能问题.个人认为关于代码性能优化主要由这几方面:HTML.CSS.Javascript和HTTP,所以对这四个方面的优化能提高浏览器的性能.个人知识面有限,只有学到以下的知识,另外的还没涉及,不足之处还请体谅. 一. HTML 1.首先是对HTML5的充分熟悉和理解,理解标签的语义化,减少对标签的重定义. 2.命名的规范化,对id.class.name的规范命名有助于整体代码的构建,方便他人的理解

app前端代码打包步骤

一.搭建项目环境 1.安装node.js 在网上找到nodejs压缩包,下载解压后安装node-v8.9.3-x64.msi文件. 安装完毕后,在windows的cmd控制台输入node -v或node --version命令,测试是否安装成功,如图1.1,出现版本号就是成功了. 或 图1.1 测试nodejs图 2.安装npm npm(Node Package Manager)的安装,其实新版本的node已经集成了npm,所以安装成功node,就不用管这步了,为了保险,我们也测试下是否安装成功

前端代码性能优化工具

转自:http://segmentfault.com/a/1190000002585760 Google Closure Compiler 官网:https://developers.google.com/closure/compiler/ Closure Compiler的使用方法有如下3种: 在命令行下使用一个google编译好的java程序 使用google提供的在线服务 使用google提供的RESTful API 首先需要下载compiler-latest.zip,由于可能有的用户没法

前端代码性能优化

1.display:none;优于visibility:hidden;前者隐藏不占用物理空间,后者会占用.2.合并margin,padding,border的-top,-left,-right,-bottom的设置,简短简洁.3.选择器在满足效果的基础上,尽量简单,减少嵌套,查询的消耗.4.如若值为0,则去掉单位,如border-right:0px;可以写为border-right:0;5.没有边框,用border:none;优于border;0;6.在保持代码解耦的前提下,尽量合并重复的代码.

Electron打包前端代码

本文主要介绍如何利用Electron将前端代码打包成exe文件. 其实如何通过Electron将前端代码打包成exe文件,其入门教程讲的挺详细的,但是浏览一遍下来还是不太清楚到底该怎么操作,这里只是将其细化分解. 首先,我们需要确保我们的电脑上已经配置好了Node.js环境,如果没有的话,请到Node.js下载并安装配置. 其次,我们需要有一个写好的Electron应用,如果你不嫌麻烦的话,可以按照入门教程中的打造你第一个Electron应用一步一步自己手动创建,但是我会从他的GitHub仓库里

【转载】【grunt整合版】30分钟学会使用grunt打包前端代码

[grunt整合版]30分钟学会使用grunt打包前端代码 grunt 是一套前端自动化工具,一个基于nodeJs的命令行工具,一般用于:① 压缩文件② 合并文件③ 简单语法检查 对于其他用法,我还不太清楚,我们这里简单介绍下grunt的压缩.合并文件,初学,有误请包涵 准备阶段 1.nodeJs环境 因为grunt是基于nodeJs的,所以首先各位需要安装nodeJS环境,这块我们便不管了http://www.cnblogs.com/yexiaochai/p/3527418.html 2.安装

细说前端自动化打包工具--webpack

背景 记得2004年的时候,互联网开发就是做网页,那时也没有前端和后端的区分,有时一个网站就是一些纯静态的html,通过链接组织在一起.做网页就和用world编辑一个文档一样,只不过那个工具叫Dreamweaver.一个html页面,夹杂着css,javascript是再常见不过的事了. 随着前端的不断发展,特别是单页应用的兴起,这种所见即所得的IDE工具,就渐渐地退出了前端的主流.一个应用,通常只有一个静态页面(index.html),甚至这个页面的body只有一个或少数几个div组成.这时有

小型Web页打包优化(下)

之前我们推送了一篇小型Web项目打包优化文章,(链接),我们使用了一段时间, 在这过程中我们也一直在思考, 怎么能把结构做的更好.于是我们改造了一版, 把可以改进的地方和可能会出现的问题, 在这一版中进行了优化.小伙伴们, 有没有迫不及待? 那好, 我们废话少说, 进入正题^_^ 一.背景 之前, 转转App端内有些Hybrid页面和一些端外的落地页, 一般是单个的一两个小页面, 不是所谓的大型的前端应用, 比较零散, 交互也比较简单.如果用vue或react, 有点杀鸡焉用宰牛刀的意思, 没有

前端代码规范1.0

意义:该规范旨在统一前端代码书写,规范前端代码标准,为共同协作打下良好基础,提高工作效率. 文件夹/文件命名 图片文件夹:image,images,img Js代码文件夹:js Css文件夹:css 首页:index. 其他页面根据具体情况来定,可以是中文名,英文名,拼音等,以方面认识为主. 页面框架布局 样式名称 样式名称的规则为根据对应位置的英文来命名.如: 头部:header 导航:nav 页尾:footer 消息:news,message 分页:page, 下拉:select 复选框:c