作者：ChenJing

性能优化始终是前端钻研的次要课题之一，因为不仅间接影响用户体验，对于商业性公司，网页性能的优劣更关乎流量变现效率的高下。例如 DoubleClick by Google 发现：

• 如果页面加载工夫超过 3 秒，53% 的用户会抉择终止以后操作并来到
• 网站加载工夫在 5 秒内的公布商比 19 秒内的广告支出至多多出一倍

同时，性能优化学习的不断深入，也同样是一个业余前端工程师的进阶之路。不过，随着 HTTP/2 和 SSR（服务端渲染）的一直遍及，晚期雅虎 35 条中的很多内容仿佛曾经显得有些过期，不少纯前端的细节优化计划也逐步被认为微不足道。

然而，明天，咱们仍然想谈几个容易被很多前端工程师漠视，但却行之有效的纯前端优化细节（技术框架以 Vue 为主）。

一、self

这里想说的 self 并不是  WindowOrWorkerGlobalScope 下的 self，或者说 window 的替身，而是 const self = this  中的 self，或者说对象缓存。

在简直所有数据类型皆对象的 JavaScript 中，能无效升高属性拜访深度的对象缓存是前端优化最根底的课程，即便在浏览器曾经进化到即便没有明确地申明缓存对象，内核解析时也会主动缓存以减少解析效率的明天。

良好的对象缓存不仅仅只是为了防止写出上面的代码：

const obj = {
        human: {man: {}
        }
}
 
obj.human.man.age = 18
obj.human.man.name = 'Chen'
obj.human.man.career = 'programmer'

还有一个更加重要的起因：无效缩小工程上线时压缩后的代码量！

首先，看一下下面代码压缩后的后果：

var ho={human:{man:{}}};ho.human.man.age=18,ho.human.man.name="Chen",ho.human.man.career="programmer";

而后，对属性对象 man 做一次变量缓存：

const obj = {
        human: {man: {}
        }
}
const man = obj.human.man
 
man.age = 18
man.name = 'Chen'
man.career = 'programmer'

再次压缩代码后的后果：

var ho={human:{man:{}}},yo=ho.human.man;yo.age=18,yo.name="Chen",yo.career="programmer";

能够看到，对象缓存使得代码容量有了显著的缩小。

那么，对于理论的我的项目，变量缓存对总体代码又会带来多大容量的缩减呢？回到大节探讨的开始，咱们一起感受一下不缓存的 this 对象带来的直观震撼吧。

vivo 某个我的项目的一个 js 文件：

整个文件存在 3836 个 this，保留到本地大略 375 KB。如果缓存 this，代码压缩时 4 个字符的 this 会被压缩成单字符变量。

整个文件的存储大小升高到 364 KB，一个 this 对象缓存即可让压缩后的代码容量降落超过 10 KB，留神，仅仅只是一个 this 对象！

二、Object.freeze()

咱们晓得，在 Vue 组件或者 Vuex 的 state 中定义的数据是响应式的，当这些数据产生扭转时，会告诉 View 层更新界面。

首先，简略回顾一下 Vue 响应式数据的原理，如下图。

其中：

每一个组件 component 都领有一个本人的观察者 watcher，外部封装了 Vue.prototype._render() 函数

每一个响应式数据属性都领有一个本人的依赖 dep 收集器，用以收集依赖该数据的组件的 watcher

响应式数据的三个根本步骤：

（1）组件数据的响应化流程：component(options) -> observe(data) -> Reactive Data

• component 的数据局部，所有的 options.data 属性通过 observe() 中的 Object.defineProperty() 函数转换成拜访器属性
• 在每一个数据属性被 Object.defineProperty() 转换时的函数闭包空间中，存在一个本人的 dep 收集器

（2）响应式数据的依赖收集流程：component(template) -> watcher(vm._render())(get) -> Reactive Data

• component 的模板字符串，通过 Vue compiler 后生成渲染函数 vm._render()
• 每一个 component 领有一个本人的观察者 watcher，watcher 中封装了 vm._render()，组件首次渲染时：

  （a）watcher 实例暂存在 Dep.target 属性上

  （b）watcher 执行 vm._render() 函数，并进一步触发 vm._render() 所依赖数据属性的 getter

  （c）watcher 实例被收集到其所有依赖数据属性的 dep 收集器中

（3）响应式数据扭转时的从新渲染流程：Reactive Data(set) -> dep 收集器 -> watcher(vm._render()) -> 异步队列

• 当响应式数据被批改时，触发数据属性的 setter 函数
• 数据属性的 setter 函数会促使 dep 收集器将其收集的所有 watcher 实例推入异步队列 queueWatcher
• 异步队列会被整体放入 nextTick() 中，即在下一个 tick 时被一次性全副执行；其实在 watcher() 中，渲染函数 vm._render() 是被封装到 vm._update() 中的，它在执行时，会首先通过 vnode 的 diff 算法比对找到批改的起码步骤，而后将最小的差异化渲染到页面

Vue.prototype._update = function (vnode: VNode, hydrating?: boolean) {
...
    // 如果没有旧的虚构节点 prevVnode，示意是首次渲染，间接渲染到页面
    if (!prevVnode) {
        // initial render
        vm.$el = vm.__patch__(
            vm.$el, vnode, hydrating, false /* removeOnly */,
            vm.$options._parentElm,
            vm.$options._refElm
        )
         
    // 非首次渲染，数据批改导致须要更新页面时，进行 vnode diff 后将最小的差异化渲染到页面
    } else {
        // updates
        vm.$el = vm.__patch__(prevVnode, vnode)
    }
...
}

每一个响应式数据对象属性都肯定会经验三个根本步骤中的 1 和 2，不过，很多属性在利用的整个生命周期中可能都不会经验步骤 3，因为它们始终没有扭转。

然而，须要留神的是：之所以 Vue 会进行步骤 1 和 2 的操作，其实次要就是为了步骤 3 做筹备，如果步骤 3 得不到执行，那么前两步的操作就是无意义的，或者说节约。是否有形式防止这种节约呢？有，就是 Object.freeze()。

在将一般数据转变成响应式数据的外围函数 defineReactive（Vue 2.6.x src/core/observer

/index.js）中，有一个判断，如果属性自身不是 configurable 的，则不会被转化成响应式数据，即不会执行下面的流程 1，与此同时，非响应式的数据也天然不会执行流程 2。

/**
 * Define a reactive property on an Object.
 */
export function defineReactive (
  obj: Object,
  key: string,
  val: any,
  customSetter?: ?Function,
  shallow?: boolean
) {const dep = new Dep()
 
  const property = Object.getOwnPropertyDescriptor(obj, key)
  if (property && property.configurable === false) {return}
   
  ...
}

对于整个利用生命周期中，不会扭转的数据，能够应用 Object.freeze() 将其 configurable 属性置为 false；或者，将整个数据对象都 freeze 掉：

/**
 * 深度解冻对象
 */
function deepFreeze(obj) {Object.keys(obj).forEach(key => {const prop = obj[key]
 
    typeof prop === 'object' && prop !== null && deepFreeze(prop)
  })
 
  return Object.freeze(obj)
}

而后，“冻结”局部须要扭转的数据，并将其转换成响应式数据。

留神，如果冻结的属性值是对象，不能通过简略地赋值“冻结”该对象，因为对象的援用传递个性导致其 configurable 仍然是 false。能够应用上面的简略深复制办法，让源对象失落 configurable 属性：

/**
 * 简略对象深复制
 * -- 子对象援用关系失落
 * -- 不适宜循环援用数据
 */
function deepClone(obj) {return JSON.parse(JSON.stringify(obj))
}

对于 Object.freeze() 带来的性能晋升，Vue 官网的一个 big table benchmark 里，做了一个 1000 x 10 的表格渲染对照试验，应用 Object.freeze() 的渲染速度比不应用时快了 4 倍。

三、Pre 机制

浏览器的 pre（预）机制。

因为可动静批改 DOM 的人造属性，JavaScript 不仅自身的执行是单线程的，而且其加载 / 解析执行时 HTML 的解析也是进行的，甚至在晚期的浏览器中，其它资源的加载线程也会被同时阻止。

例如，在 IE7 中，页面的瀑布流：

其余资源的加载、解析、执行不能和 JavaScript 的加载执行并行，这导致了页面的加载工夫很长。为了进步网络利用率，起初的支流浏览器都实现了预加载机制，即解析 HTML 页面的同时，启动一个轻量级解析器优先扫描 HTML 中的所有标记，寻找样式表、脚本、图像等动态资源，尽可能地并行加载它们。

IE8 中的页面瀑布流：

能够很显著地看到，动态资源被尽可能的并行加载了，即便在脚本加载解析的时候。

不过，随着 Web 利用的越加复杂化，CSS 和 JavaScript 资源容量也越来越大，很多资源并不是一开始就呈现在 HTML 中，而是前期被 CSS 和 JavaScript 动静引入的。为了尽可能提前解析 / 加载这些资源，浏览器开始提供丰盛的 pre 机制。

1、Preload

浏览器内核的预加载机制只实用于在 HTML 中显式申明的资源，对于 CSS 和 JavaScript 中定义的资源可能并不起作用。preload 很好地克服了这个问题，能够通过 preload 标识须要浏览器提前加载的重要资源，例如样式表、脚本、图片、字体甚至文档。

# 预加载 css
<link rel="preload" as="style" href="/assets/css/app.css">
 
# 预加载 js
<link rel="preload" as="script" href="/assets/js/app.js">
 
# 预加载图片
<link rel="preload" as="image" href="/assets/images/man.png">
 
# 预加载字体
<link rel="preload" as="font" href="/assets/font/rom9.ttf">

2、Prefetch

Prefetch 是一个低优先级的资源提醒，容许浏览器在后盾（闲暇时）获取未来可能用失去的资源，并且将他们存储在浏览器的缓存中。有三种不同的 prefetch 类型：

（1）Link Prefetching： 容许浏览器获取资源并将他们存储在缓存中。

• HTML

<link rel="prefetch" href="/uploads/images/pic.png">

• HTTP Header

Link: </uploads/images/pic.png>; rel=prefetch

（2）DNS Prefetching： 容许浏览器在用户浏览页面时在后盾运行 DNS 解析。

能够在一个 link 标签的属性中增加 rel=”dns-prefetch’ 来对指定进行 DNS prefetching 的 URL：

<!-- 域名 dns-prefetch -->
<link rel="dns-prefetch" href="//sthf.vivo.com.cn">
<link rel="dns-prefetch" href="//apph5wsdl.vivo.com.cn">
<link rel="dns-prefetch" href="//cfg-stsdk.vivo.com.cn">
<link rel="dns-prefetch" href="//trace-h5sdk.vivo.com.cn">
<link rel="dns-prefetch" href="//topicstatic.vivo.com.cn">

DNS 申请在带宽方面流量十分小，可是提早会很高，尤其是在挪动设施上。

（3）Prerendering： 和 prefetching 十分类似，优化可能资源的加载，区别是 prerendering 在后盾渲染整个将来可能加载的页面。

<link rel="prerender" href="https://www.vivo.com.cn">

这三种类型中，Link Prefetching 和前文的 preload 比拟类似，然而优先级较低，而且更加专一于下一个页面；Prerendering 会预渲染一个用户不肯定拜访的残缺页面，这会导致较高的带宽节约和资源占用，利用的机会可能并不多；而 DNS Prefetching 是以后咱们利用最多的。

在浏览一个网页时，DNS 解析总是产生在一个新域名首次被解析的时候，如果域名解析是独立串行的（如页面主域的解析），解析工夫的长短（如下图中的 vivo 游戏大会员 supermember.vivo.com.cn）将间接影响页面的关上速度。得益于古代浏览器的预加载机制，除页面主域以外的其余资源域名的解析工夫，肯定水平上很好地掩蔽在了资源的并行加载过程中。

然而，dns 的解析并不一定是稳固牢靠的，时间跨度从几十 ms 至过千 ms 都有可能，如果页面次要资源的 dns 解析工夫过长，就会间接影响用户的应用体验，所以，失当的 DNS Prefetching 仍然很有必要。

3、Preconnect

相比于 DNS Prefetching，Preconnect 除了提前完成域名的 DNS 解析，还更近一步地实现 http 连贯通道的建设，这包含 TCP 握手，TLS 协商等。

应用办法：

<!-- 域名 preconnect -->
<link rel="preconnect" href="//sthf.vivo.com.cn">
<link rel="preconnect" href="//apph5wsdl.vivo.com.cn">
<link rel="preconnect" href="//cfg-stsdk.vivo.com.cn">
<link rel="preconnect" href="//trace-h5sdk.vivo.com.cn">
<link rel="preconnect" href="//topicstatic.vivo.com.cn">

能够同时设置 Preconnect 和 DNS Prefetching，让浏览器优先进行 Preconnect，在不反对的前提下，优雅回退至 DNS Prefetching。

四、并行加载

随着 Web 利用的复杂化大型化，应用 MV* 类框架（Vue、React、Angular 等）进行快捷开发曾经成为前端开发的支流模式。然而，这些框架都存在根底框架包较大，解析工夫较长的问题。

首先，咱们看一个规范的 Vue 我的项目 – vivo 游戏大会员 Chrome 开发者工具中的瀑布流：

能够看出资源的加载存在显著的层级构造：

• 第 1 级：获取页面 HTML 文档并解析
• 第 2 级：获取页面 CSS 和 JavaScript 文件并解析
• 第 3 级：申请接口获取服务端数据
• 第 4 级：页面渲染加载主页图片等资源

同时，能够发现因为 JavaScript 文件较大，解析工夫较长，第 2 级与第 3 级，以及第 3 级和第 4 级之间的工夫距离较大。如果这种串行的逐级解析加载模式可能扭转为并行的加载模式，势必将显著升高页面的加载时长。

留神，如果我的项目未开启 HTTP/2，可能须要减少资源域名以冲破浏览器对单个域名并行下载数量的限度。当然，在上面实现并行加载的过程中，咱们也应用了很显著的反模式 – 通过 window 全局变量传递数据。不过，在没有更好的实现计划前，通过无限可控的反模式实现更好的页面体验还是值得的。

上面，咱们探讨如何将串行加载的资源变成并行加载。

1、接口

大多数时候，接口的申请并不需要期待 Vue.js 加载解析实现，齐全能够在 HTML 中通过几行简略的 JavaScript 代码提前进行 Ajax 申请。

/**
 * 主接口申请前置
 */
var win = window
var xhr = new XMLHttpRequest()
 
xhr.open('get', '/api/member/masterpage?t=' + Date.now(), true)
xhr.onerror = function () { win._mainPageData = { msg: '申请出错', code: 10000} }
xhr.timeout = 10000
xhr.ontimeout = function () { win._mainPageData = { msg: '申请超时', code: 10001} }
xhr.onreadystatechange = function () {
  try {
    var status = xhr.status
 
    if (xhr.readyState == 4) {win._mainPageData = (status >= 200 && status < 300) || status == 304
      ? JSON.parse(xhr.responseText)
      : {
          msg: '',
          code: 10002
        }
    }
  } catch (e) {/* 申请超时时 readyState 可能也是 4，然而拜访 status 可能出错 */}
}
xhr.send(null)

须要留神的是，直接插入到 HTML 中的 JavaScript 可能不会通过 babel 的编译，所以不要应用 ES6 语法，因为很可能一个简略的 const 就会让 Android 5/4.4.4 间接白屏。

2、图片

通常，Web 利用主页首屏会有几张装饰性且容量较大的图片，将图片写在 Vue 组件中，图片的加载会推延到组件解析实现，咱们同样能够在 HTML 中提前加载这些图片。

一种形式是应用前文 Pre 机制中提到的 Preload：

<link rel="preload" as="image" href="/assets/images/00.png">
<link rel="preload" as="image" href="/assets/images/01.png">
<link rel="preload" as="image" href="/assets/images/02.png">

只管 Preload 领有更简洁且不阻塞页面渲染的长处，然而这种形式以后仍然存在两个显著的问题：

（1）低版本 Android 不反对 Preload

（2）如果我的项目须要判断环境是否反对 webp 格局，以便有辨别地加载图片的 webp 格局和一般格局，Preload 就不好办了，除非你两种格局都加载，但很显著这样会造成重大的流量节约。

所以，咱们能够应用 JavaScript 代码在判断环境是否反对 webp 格局后，加载须要格局的图片：

/**
 * webp 探测
 */
var win = window
var doc = document
 
win._supportsWebP = (function () {
    var mime = 'image/webp'
  var canvas = typeof doc === 'object' ? doc.createElement('canvas') : {}
  canvas.width = canvas.height = 1
  return canvas.toDataURL ? canvas.toDataURL(mime).indexOf(mime) === 5 : false
}())
 
/**
 * 图片预加载
 */
var body = doc.body
var parentNode = document.createDocumentFragment()
var imgPostfix = '.png' + (win._supportsWebP ? '.webp' : '')
var linkPrefix = '//topicstatic.vivo.com.cn/f5ZUD0HxhQMn3J32/wukong/img/'
var imgPreLoad = win._imgPreLoad = [
  linkPrefix + '5f88483c-4d76-42d4-912d-35c8c92be8e6' + imgPostfix,
  linkPrefix + '5ee4c220-cd98-4d8c-9cdc-5fca3e103227' + imgPostfix,
  linkPrefix + '131008e1-9230-480c-934a-30f9f83e17ae' + imgPostfix,
  linkPrefix + 'cee41d4d-853d-4677-9a20-b9b5e1c4ffbenwebp' + imgPostfix,
  linkPrefix + 'ddf2cad0-d334-437a-8923-7b36a65544d1nwebp' + imgPostfix
]
 
imgPreLoad.forEach(function (link) {var img = doc.createElement('img')
 
  img.src = link
  img.style.left = '-9999px'
  img.style.position = 'absolute'
 
  parentNode.appendChild(img)
})
 
body.insertBefore(parentNode, body.firstChild)

此外，在适合的时候，能够尝试应用 svg 图片，除了永不失真的图片品质，更重要的是，svg 能够很好地打包到代码中，并始终保持比 base64 更好的可读性。

3、字体

有的时候，为了实现更好的视觉效果，并能应答动态变化的接口数据，咱们会引入一些零碎不反对的字体，比方数字字体 Rom9。

不过，咱们可能只是用到字体中的某一部分，比方数字，此时除了应用字体编辑软件删除不须要的字符外，咱们还能够将字体 base64 化后整合到 CSS 中以便更好地并行加载：

@font-face{src: url(data:font/truetype;charset=utf-8;base64,AA... 省略...AK) format("truetype");
    font-style: normal;
    font-weight: normal;
    font-family: "Rom9";
    font-display: swap;
}

五、利用

咱们将下面无关的探讨利用到理论的我的项目 vivo 游戏大会员中。

首先，看一下并行加载优化后的资源瀑布流，本来处于第 2、第 3 和第 4 级的资源并行加载了。

通过视频能够更直观地感触优化带来的改善：

优化前：

优化后：

能够看到，页面的关上速度不仅更快，而且并行加载使得图片的出现也不再带有“节奏”了。