这篇文章的背景就是在公司的一个项目，使用的技术栈是vue + vuecli3 + antdesign，由于早期的API接口有坑，antdesign的upload组件上传满足不了业务需求就用了iview的组件，所以当时是ant是全量引入，iview是按需引入了一个upload模块，当我们的打包出来的时候发现chunkjs很大，足足有近8m多，导致首屏加载时间很长，所以针对这一个问题通过几个方面来分析和优化。

分析模块

分析模块使用的是webpack-bundle-analyzer这个插件，按照说明的配置在plugins中即可，由于插件使用过于简单，我推荐的参考文章是
打包分析插件webpack-bundle-analyzer简介

像我所说的antdesign和iview技术栈混用这样的方式，本身就是不提倡的，所以大家在使用这个分析插件的时候，看看js文件的大小哪个是最大的，比如chunk vendors很大那就要看我们下面的配置说明来进行一步一步优化了

webpack4的splitchunks和runtimechunks (剖析被引用的js次数来缓存js)

我在看这方面的知识的时候，仅仅凭着以前一点点笔记来实践，总知踩了不少坑的;
首先来了解一下splitchunks的默认配置，这些配置讲真话不会用到全部的，很多的配置还存在着一知半解的状态下

optimization: {
    splitChunks: { // 如果这是一个空对象，那么分割的代码则是按照默认配置进行
    chunks: "all", // 只对异步或者同步或者全部的模块引入方式进行分割，all / async / initial
    minSize: 30000, // 引入的模块最小体积如果在值之类进行分割，否则不分割，这个是字节，计算/1000是kb
    // 同理还有maxSize，如果代码超出，将再次分割
    minChunks: 1, // 模块最小引入数量
    maxAsyncRequests: 5, // 最大异步并行最大请求数量，用途：控制分割的代码数量（默认是5）轻易不要更改
    maxInitialRequests: 3, // 入口并行最大请求数量，轻易不要更改
    automaticNameDelimiter: '~', // 分割代码连接字符串
    name: true, // 开启分割代码的文件名可定义（filename）
    cacheGroups: { // 缓存分组，此分组配置和chunks配置项必须是搭配，在判断引入的模块是异步还是同步之后需要走这个配置项进行分组，可以配置vendors为false
// 缓存组：顾名思义，将分割的代码暂时缓存起来，把所有匹配成功的分割代码进行整合打包在一个文件中
vendors: {
    test: /[\\/]node_modules[\\/]/,
    priority: -10, // 优先级：越小优先级越高，如果模块分别匹配条件和default成功，将通过此参数决定具体分配到哪个模块
    filename: "ventor.js" // 分割代码分组之后一起打包到哪个文件，这里设置文件名
},
default: { // 如果满足不了上面的缓存组，将执行下面的配置
    minChunks: 2, // 模块引入数量
    priority: -20,
    reuseExistingChunk: true // 如果开启了此配置，将分割代码中引入的模块（分割过的）直接引入分割后的地址，不再进行分割
    }
}
}
}

我们可以将工程中的vue，lodash，moment等等js（分析出来的比较大的js）进行分割
在缓存组可以这样写

vue: {
    test: /vue/,
    chunks: "initial",
    name: "vuw",
    enforce: true,
}

依次类推，我们的lodash和moment将会被提炼出来；

那么从分割文件之后，我们的chunks vendors肯定会小，我们也可以加入runtimechunks来进行小文件的优化，将webpack的运行时文件进行打包，那么多个js文件将会共享这个运行时文件 runtimechunks文档

图片压缩

这一块图片压缩算是一个小小的技巧，也是通过tinypng进行的，这一节我们只讨论压缩，不讨论CDN之类的
首先tinypng有一个官网，它可以提供在线压缩免费服务的，一天也是50张压缩图片的额度且单张图片不能超过5m，一般来讲开发过程中也够用了，如果要在web服务中加入tingpng，那么需要获取key，再去npm安装相关tingpng依赖

我们来看一下无损压缩图片的压缩率和质量

另外说一句tinypng是提供ps插件的，价格也还算便宜，60刀，另外也有额外热心网友提供的tinypng无限制的API和压缩服务破解版tinypng

gzip服务

作为一个靠谱的前端从业者，gzip压缩技术一定要知晓并且最好会用，我们都知道在前端工程中js，css等资源在webpack的生产环境下会压缩，那么gzip技术会在这个的基础上再压缩至少百分之50以上，对webpack进行一些配置，就可以打包出来如下图的js

并不是每个浏览器都支持gzip的，所以服务端会根据浏览器的请求头

Accept-Encoding: gzip, deflate；
这个是谷歌浏览器的支持程度，如果服务端解析请求体收到了gzip的兼容请求后会返回对应的gzip文件，反之如果不支持将会返回普通的js资源

npm i compression-webpack-plugin -d

vue.config.js配置代码:
plugins: [
  new CompressionWebpackPlugin({
    algorithm: 'gzip',
    test: /\.js$|\.html$|\.json$|\.css/,
    threshold: 10240,
    minRatio: 0.8
   })
]

后端nginx只需要简单的配置即可开启，开启方法

这里有一个小坑，vuecli2是可以支持productionGzip只需要配置true或者false即可，不需要在脚手架配置额外其他内容，但是vuecli3是需要配置的

vue路由懒加载

曾经在做路由懒加载的时候有一段时间疑惑，既然是懒加载，为什么在打包出全部js后，浏览器还需要加载全部的js呢，如图:

那么懒加载是不是就失去了它存在的意义，当我细细研究的时候，发现在加载第一次的时候，那些原本懒加载的js都打不开

那么继续往下研究，通过和群友的探讨，他找到了关键性的代码（真心惭愧）

1. 首先他找到的是一句追加script的代码

2. 我这边找到的是每一句js都会把当前路由写入到webpackJsonp这个数组中

   (window["webpackJsonp"] = window["webpackJsonp"] || []).push([[12]) //这里的12代表模块ID
   然后在控制台中打印webpackJsonp这个全局变量会发现

对应的数组中不仅仅有模块ID还有对应需要加载的模块，那么如果细细看每个被懒加载的js文件就会发现其中的require函数内部其实都做了一层优化，当第二次访问此模块就从这个数组拿取上次的缓存；

__webpack_require__.e和webpackJsonp

那么对代码分割的内部异步加载模块的源码解读可以看这篇文章，这也是我在总结这篇文章的时候给我很大帮助的资料

这篇文章中出现的CommonsChunkPlugin等等概念是webpack老版本出现，新版本则是spiltchunks

IgnorePlugin忽略指定的打包模块

使用IgnorePlugin插件可以帮助我们讲不必要的内容不进行打包

let webpack = require('webpack');
plugins: [
  // 忽略解析三方包里插件
  new webpack.IgnorePlugin(/\.\/locale/, /moment/)
]

场景： moment中只引入了中文的包，可以通过这个配置进行把非中文的包去掉

OSS对象存储

这里说一下，OSS也是我近两年知道的，几年前在搭建这个博客的时候，阿里云有一些类似的活动套餐才让我了解这个东西，但是今年做开发的时候却第一次实际用到了OSS作为文件的存储服务，目前我的博客也采用了OSS作为附件资源的存储，价格也非常便宜，一年40G只需要9元

因为OSS经过了淘宝双十一的多年考验，同时OSS采用了高可用的架构设计，OSS的多重冗余架构设计，为数据持久存储提供可靠保障。
对比自建服务器存储，原始的存储方式基于硬件的影响，可能会出现各种突发问题，且人工数据的恢复有成本

安全方面oss为企业提供了很多的基础建设，加密相关

在我们这篇博客的主题，从10s到1s有很大一部分的功劳都是归于OSS

HTTP2

HTTP2在这次实践没有使用到，这块也和大家一起复习，因为在筹备这次的资料的时候，也补充了相关很多东西，在以前的HTTP1时代，前端如果被问到优化相关内容时候，一般通常会说雪碧图，内联样式，合并代码之类的，通过这些手端来达到HTTP的优化

HTTP1的一个概念叫做线头阻塞，会同时发起多个TCP请求，而这些请求都是线性流程的，一个资源下载完毕之后才能下载下一个资源，所以我们之前的优化手端“合并代码”才会非常流行，把所有的资源放在一个连接下去请求，但是在HTTP2看来，这些做法都不推荐。

那么HTTP2主要有以下几个特性关乎到我们的优化

1. 多路复用
   HTTP2允许我们将多个HTTP请求放在一个TCP连接中，避免了HTTP1中的建立多个TCP连接的开销，HTTP将会并行这些HTTP请求
2. 头部压缩
   HTTP2减少了多个HTTP请求的开销，因为每一次的http2的请求都少于没压缩的http1的请求
3. 流的优先级
   HTTP2可以浏览器指定接受资源的顺序，我们可以将较为重要的文件优先安排在前面
4. 服务端推送
   服务端也可以主动推送额外的资源到客户端

那么HTTP1的优化观念是需要我们转变的呢？

【1】 不需要合并文件
不需要合并文件了，通常我们会把css放在一个文件中，js也是如此，webpack打包出来的chunk.js，合并过的css，多个图片合成的雪碧图，这样的作法太老套，如果现在这个时代还有人热衷于雪碧图，我会对此前端开发者的技术打一个大大的问号，必经这个玩意流行的时间是我入行之前都流行的（狗头）

HTTP2中，合并文件虽然能压缩更多的文件体积，但是却增加了缓存的开销，一个被合并过的js，其中的内容被改变，那么浏览器承担的确是重新缓存整个合并的js，这样代价很大，而http2提倡的是【颗粒化】的传输，将多个文件的缓存利用到极致，这就是比http1好处的地方，还有一个关键的点就是在http1中你的网站可能没有全部使用合并的css和js，这样也无所谓，但是http2中加载这些没有使用过的资源，字节，是会缓慢首次加载的。

我们可以将经常改动的内容js和不经常改动内容的js做一个区分，比如nodemodules打出来的chunk则是不经常改动的js，我们可以把这一块的资源进行CDN。

【2】不需要样式内联

在http1中，样式内联比如

<body style="color: red"></body>

这样单个的css不会产出新的css，浏览器不会去重新请求一个css，而是直接读取html，这样做的确可以达到优化目的在http1

如图，多个HTML引入了同样的css内联，那么样式发生变化时，还需要请求多个html从服务端，这导致了用户在访问每一个页面都要额外的传输更多的东西。内联同样也会破坏优先级，因为我们在上面提到了http2是可以浏览器指定处理的优先级的，如果内联在html中，那么意味着这些css会和html同样的优先级，会导致http2的【流的优先级】没用，也就是说没按照偏好加载资源，但是在我查到的资料中，提到了

可以使用http2的服务端推送，告诉浏览器 “稍等，你刚请求的HTML页面过会渲染时会用到这些图像和CSS文件”，这样其实是和内联一样，还不会被破坏流的优先级，可以单独利用CDN缓存它们

【3】不需要细分域名
浏览器规定，单个域开通的tcp数量优先，原先为了浏览器能够并行的下载更多的资源，那么就开通多个域名，让浏览器有“并行”效果，但是http2出现了，多个域反而会造成多余的DNS查询和tcp连接，因为http2本来可以共享tcp进行多个http请求，同样的它也会破坏流的优先级，因为浏览器不会通过域不同比较其谁更优先

关于域名细分更多的内容都在参考文章中

还有很多http1和http2公用的优化手端

比如CDN，浏览器缓存

那么更重要的一点就是，http2的性能提升还是得看自己的业务，要是http请求很少，那我个人觉得没有必要

关于http2的服务端推送这个知识点我没有听说过和使用过，所以大家可以查询更多相关资料了解并且实践它们

结语

在以后的面试中，webpack，gulp等打包工具，浏览器性能，CDN，优化手端已经成为了高级前端的必考点，所以雪碧图，合并文件等等这些手端就尽量别说了，这篇文章从vue技术栈出发，讲解了企业实战的优化指南，从发现性能问题到解决性能问题提供了一系列的思路，那么这不是最终版，优化的方案远远不止这么多，希望大家一起学习，还有一些手写的图，字很丑多见谅

参考文章

关于入门了解splitchunks
webpack输出文件分析源码
oss相关优势-阿里云官网
http2性能优化指南

此blog不是恰饭，主要是放美照的，嘻嘻

地点： 陕西商洛的金丝峡
票价： 成人是100￥/人
总体感觉：有峡谷也有山，完美，爬完山之后走峡谷乘凉，非常划算
注意事项：来这里一定要爬山，走峡谷就爬不了山，但是下山之后可以走峡谷

美中不足的一件事情

在上山之后的当天早上就收到了外爷的死讯，几个月的煎熬安详地走了，第二天我就马不停蹄的回老家去参加外爷的丧事，这也是我第一次参加丧事，小时候有印象的参加了外婆的丧事，当时还很小就被妈妈抱上床，这边当地的习俗 “转香”也没有转，但是这次连续好几个晚上我都为外爷完成了祈祷，在入土的前一天我也见到了外爷，满足了我的心愿，愿他在天堂可以过得很好，愿他一直有好酒喝，愿他永远保持一个老小孩的心态

基于NPM的包或者库，项目中的package.json是对项目的描述，这个json对象中的script标签就是npm运行脚本，vue.js在这里配置了如下的内容

"build": "node build/build.js",
"build:ssr": "npm run build -- web-runtime-cjs,web-server-renderer", （**注意这一块是用逗号分割的**）
"build:weex": "npm run build -- weex"

vue当然有很多script命令，但是仅仅只有这几种是build的，build:ssr和build:weex其实和build一样，只不过提供了不同的运行参数

查找build的入口文件，vue是如何做build源码的？

打开对应的build/build.js

let builds = require('./config').getAllBuilds()
// filter builds via command line arg
if (process.argv[2]) {
  const filters = process.argv[2].split(',') （**分割出来的数组是["web-runtime-cjs"，"web-server-renderer"]** ）
 // 通过getAllBuild函数返回的config对象对其打包模式进行了rollup的配置，包括output等设置
 // 而下面这一段代码的b则是返回的config对象，filters这个参数数组使用some来判断builds中output中的file(被resolve函数定义了，这个resolve函数下面会具体讨论)
  builds = builds.filter(b => {
    return filters.some(f => b.output.file.indexOf(f) > -1 || b._name.indexOf(f) > -1)
  })
} else {
  // filter out weex builds by default
  builds = builds.filter(b => {
    return b.output.file.indexOf('weex') === -1
  })
}

这一段代码其实非常简单，作者也在源码中写了注释解释了这段代码的作用

通过命令行arg构建过滤器

其中引入的config 文件调用了getAllBuilds这个方法，在config.js可以看出

 exports.getAllBuilds = () => Object.keys(builds).map(genConfig)

这一句代码是导出config的关键代码，builds是预定义的一些对象

 // runtime-only build (Browser)
  'web-runtime-dev': {
    entry: resolve('web/entry-runtime.js'),
    dest: resolve('dist/vue.runtime.js'),
    format: 'umd',
    env: 'development',
    banner
  },

entry: 入口文件
dest: 输出目标文件
format: 构建的格式 umd为umd格式 cjs遵循commonJS规范 es遵循esmodule规范
env：开发模式/生产模式
banner指的是每个js的页头，比如作者，信息，开源协议等信息
还有其他的一些关于rollup（很像webpack的一些设计）别名诸如此类的配置，这边就不阐述了，因为我也忘记的差不多了，文档都很好查，想知道具体的意思也很容易

resolve函数的定义

这里的resolve函数比较简短，很容易理清

//假定一个config中使用resolve这个函数，它传递的字符串是这样的
'web-runtime-cjs': {
    entry: resolve('web/entry-runtime.js')
  }

const resolve = p => {
  const base = p.split('/')[0]
  if (aliases[base]) {
    return path.resolve(aliases[base], p.slice(base.length + 1))
  } else {
    return path.resolve(__dirname, '../', p)
  }
}

首先base则是 “web”这个字符串，
这个base并不是真实的路径，而这个web则指向了aliases的配置

module.exports = {
  web: resolve('src/platforms/web'),
}

这里的web指向的路径就是src/platforms/web
那么resolve函数返return的就是path.resolve，其中第一个参数就是web，第二个参数则是entry-runtime
所以由此得知，通过这样的一个过程找到了build的入口文件然后经过rollup的打包就会在dist目录下生成web/entry-runtime.js

拓展阅读

Runtime Only VS Runtime + Compiler 推荐阅读

在初级和中级前端面试笔试中，函数的防抖和节流要求候选人有能力去精通或者熟悉里面的机制，不仅仅要知道基本版的防抖和节流，还要知道更完美进阶的节流防抖，比如一些lodash中的实现等等，所以这个系列也是从基础版开始，我会和大家一起补充这方面的知识

配套代码地址在线调试和编辑
参考文章

防抖

【背景故事】
某商业楼每天早上上班高峰期的电梯非常堵，通常生活来讲，一个电梯肯定是要进去很多人的直到人满为止，这对于自身和电梯都是一种节约资源的表现，不可能出现每个人一人一个电梯的情况，所以对于电梯和我们，这是一种防抖函数的表现。

电梯每当停到一个楼层，会等我们进去，人没有塞满或者没有人它才会到达指定楼层。
在web端最容易遇到的就是input搜索，用户输入一个字符，会在指定的时间中监听是否还有字符进入，如果没有，那么就执行对应的函数，这样就解决了用户频繁输入字符而前端发起请求给服务器造成压力的问题

// 防抖函数
function debounce(fn, time = 300) {
  let timer = null;
  return function() {
    clearTimeout(timer);
    timer = setTimeout(() => {
      fn.apply(this, arguments);
    }, time);
  };
}

基础版的代码梳理，通过这个函数将fn传递，就能实现防抖的效果，当用户输入的第一个字符，会把timer函数赋予一个延时器，这个延时器执行了对应的fn，this是为了绑定执行的this指向，arguments则是这个函数的参数类数组对象，当用户在延时还未触发的时候再次输入字符，那么clearTimeout把上一个timer清除掉了，因为闭包的作用，timer不会被销毁，这样的一个函数就表示了，只要在延时间隔中（此时timer被赋值了），如果谁再调用此函数，会把上一个timer清空掉，重新延时，依次类推...

节流

【背景故事】
在0几年的时候包括可能现在都有，很多家庭知道水管把阀门开到最小，让水一滴一滴的掉下，是不会走水表的（不计费的），所以在我很小的时候就知道这个事情，虽然现在没有了，但是还是觉得很羞愧,节流函数就是起到的作用就是，把原本频繁的调用变得有秩序有间隔；

以监听scroll滚动为例：

// 节流函数
function throttle(fn, time = 300) {
  let canRun = true;
  return function() {
    if (!canRun) return;
    canRun = false;
    setTimeout(() => {
      fn.apply(this, arguments);
      canRun = true;
    }, time);
  };
}

$(window).on(
  "scroll",
  throttle(() => {
    console.log("触发了scroll");
  }, 300)
);

在这个函数中，canRun这个变量变化了3次，判断了一次如果为false就return掉

1. 初始化时设置为true
2. 判断canRun是否为false后设置了canRun为false
3. 最终事件执行完毕之后设置canRun为true，否则就进入不了下一次的节流

其实这个函数从开始到结束的canRun形成了一次循环，这个循环唯一保证的就是只有事件结束才可以开始下一个事件

总结

节流：保证回调能在指定的时间间隔中依次有规律的执行
防抖：保证回调能在指定的时间间隔中等待是否有再次执行回调，如果没有则执行，如果有则重置继续等待；

我说我过年期间更新了3篇关于uniapp的文章，然后发布莫名消失，你们会信么？

其实是真的，家里的网络非常不稳定，我连续发了2次文章，结果预览出来的效果仅仅只有一个自然段，剩余全部丢失，所以渐渐的我心态崩掉了，然后转眼就来到了4月，我仍然会每周坚持更新笔记/感悟，分享给大家。

这是一个全新的计划，关于分析vue的源码，那么我需要一个课程带着我学习，因为讲真，它有些门槛，像我第一次看底层源码，不知道从何看起，网上有太多的关于vue的实现，比如methods，computed实现，但是都太单一，所以我在youtube上找到课程，也是慕课网的金牌讲师ustbhuangyi

所以我会把这个课程参考的资料放到这个文章的顶部
他的博客，vue源码资料
正版课程，请大家看完一定要去购买支持正版，虽然我没购买
youtube免费课程，高清，可以翻墙免费看全集

这边配套的源码截止于目前文章发表的日期,版本是2.6.11，大家在学习vue源码的核心内容的时候，只要是2.0版本的最新的内容，基本上不会影响学习vue.js的灵魂。

首先来了解一下看到这个标题，这篇文章就简单的看一下vue的src源码中的目录分工，我们在写一般的vue工程时，也会分很多很多的文件进行模块化开发，这是大势所趋，比如api;common;util;components;assets;static;pages等等，那么在框架开发中，一般像我一样的初学者就很懵逼，所以我们一起来看看；

compiler

这是vue.js编译相关的代码，它包括把vue模板编译成AST抽象语法树，一般情况下，编译会在构建时进行，因为是很耗费时长的，像webpack或者vue-loader这样的插件；

core

这里的目录是vue.js的核心之处，我们所见到的2.0新特性的vdom，监听，状态，初始化，render等等都在这里

platforms

我们一般常用的vue.js是在web端，那么vue.js也支持编译成供weex这样的运行在native上的框架
这个目录就是vue.js针对不同的平台而编译的入口

server

vue.js支持服务端渲染内容，即这里的目录是在node中进行运行的，服务端运行将返回html字符串进行渲染，这里是在服务端的vue.js而不是web端的vue.js

sfc

这里的parser.js会把编写的.vue文件转换成js对象

shared

vue.js用到的公共的方法，它将是所有的目录公共可访问的内容

这两天会根据计划更新其他的内容，这个部分会一直进行下去，不定时更新