「非主流」的純前端性能優化

時間  2020-09-24
標籤 主流 前端 性能 優化 欄目 系統性能 简体版
原文   原文鏈接
做者：ChenJing

性能優化一直是前端研究的主要課題之一，由於不只直接影響用戶體驗，對於商業性公司，網頁性能的優劣更關乎流量變現效率的高低。例如 DoubleClick by Google 發現：javascript

  • 若是頁面加載時間超過 3 秒，53% 的用戶會選擇終止當前操做並離開
  • 網站加載時間在 5 秒內的發佈商比 19 秒內的廣告收入至少多出一倍

同時，性能優化學習的不斷深刻，也一樣是一個專業前端工程師的進階之路。不過，隨着 HTTP/2 和 SSR（服務端渲染）的不斷普及，早期雅虎 35 條中的不少內容彷佛已經顯得有些過期，很多純前端的細節優化方案也逐漸被認爲微不足道。css

可是，今天，咱們依然想談幾個容易被不少前端工程師忽視，但卻卓有成效的純前端優化細節（技術框架以 Vue 爲主）。html

1、self

這裏想說的 self 並非  WindowOrWorkerGlobalScope 下的 self，或者說 window 的替身，而是 const self = this  中的 self，或者說對象緩存。前端

在幾乎全部數據類型皆對象的 JavaScript 中，能有效下降屬性訪問深度的對象緩存是前端優化最基礎的課程，即便在瀏覽器已經進化到即便沒有明確地聲明緩存對象，內核解析時也會自動緩存以增長解析效率的今天。vue

良好的對象緩存不只僅只是爲了不寫出下面的代碼：java

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

還有一個更加劇要的緣由：有效減小工程上線時壓縮後的代碼量！node

首先，看一下上面代碼壓縮後的結果：react

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

而後，對屬性對象 man 作一次變量緩存：git

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

再次壓縮代碼後的結果：github

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 對象！

2、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 倍。

3、Pre 機制

瀏覽器的 pre（預）機制。

因爲可動態修改 DOM 的自然屬性，JavaScript 不只自己的執行是單線程的，並且其加載/解析執行時 HTML 的解析也是中止的，甚至在早期的瀏覽器中，其它資源的加載線程也會被同時阻止。

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

其餘資源的加載、解析、執行不能和 JavaScript 的加載執行並行，這致使了頁面的加載時間很長。爲了提升網絡利用率，後來的主流瀏覽器都實現了預加載機制，即解析 HTML 頁面的同時，啓動一個輕量級解析器優先掃描 HTML 中的全部標記，尋找樣式表、腳本、圖像等靜態資源，儘量地並行加載它們。

IE8 中的頁面瀑布流：

能夠很明顯地看到，靜態資源被儘量的並行加載了，即便在腳本加載解析的時候。

不過，隨着 Web 應用的越加複雜化，CSS 和 JavaScript 資源容量也愈來愈大，不少資源並非一開始就出如今 HTML 中，而是後期被 CSS 和 JavaScript 動態引入的。爲了儘量提早解析/加載這些資源，瀏覽器開始提供豐富的 pre 機制。

一、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">

二、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 依然頗有必要。

三、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。

4、並行加載

隨着 Web 應用的複雜化大型化，使用 MV* 類框架（ Vue、React、Angular 等）進行快捷開發已經成爲前端開發的主流模式。可是，這些框架都存在基礎框架包較大，解析時間較長的問題。

首先，咱們看一個標準的 Vue 項目 - vivo 遊戲大會員 Chrome 開發者工具中的瀑布流：

能夠看出資源的加載存在明顯的層級結構：

  • 第1級：獲取頁面 HTML 文檔並解析
  • 第2級：獲取頁面 CSS 和 JavaScript 文件並解析
  • 第3級：請求接口獲取服務端數據
  • 第4級：頁面渲染加載主頁圖片等資源

同時，能夠發現因爲 JavaScript 文件較大，解析時間較長，第 2 級與第 3 級，以及第 3 級和第 4 級之間的時間間隔較大。若是這種串行的逐級解析加載模式可以改變爲並行的加載模式，勢必將顯著下降頁面的加載時長。

注意，若是項目未開啓 HTTP/2，可能須要增長資源域名以突破瀏覽器對單個域名並行下載數量的限制。固然，在下面實現並行加載的過程當中，咱們也使用了很明顯的反模式 - 經過 window 全局變量傳遞數據。不過，在沒有更好的實現方案前，經過有限可控的反模式實現更好的頁面體驗仍是值得的。

下面，咱們討論如何將串行加載的資源變成並行加載。

一、接口

大多數時候，接口的請求並不須要等待 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 直接白屏。

二、圖片

一般，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 更好的可讀性。

三、字體

有的時候，爲了實現更好的視覺效果，並能應對動態變化的接口數據，咱們會引入一些系統不支持的字體，好比數字字體 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;
}

5、應用

咱們將上面有關的討論應用到實際的項目 vivo 遊戲大會員中。

首先，看一下並行加載優化後的資源瀑布流，本來處於第 二、第 3 和第 4 級的資源並行加載了。

經過視頻能夠更直觀地感覺優化帶來的改善：

優化前：

優化後：

能夠看到，頁面的打開速度不只更快，並且並行加載使得圖片的呈現也再也不帶有「節奏」了。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程