前端性能優化(21種優化+7種定位方式)

1.重要性：

關注前端可以很好地提高性能，如果我們可以將后端回應時間縮短一半，整體回應時間只能減少5%~10%，而如果關注前端性能，同樣是將其回應時間減少一半，則整體回應時間可以減少40%~45%，

改進前端通常只需要較少的時間和資源，減少后端延遲會帶來很大的改動，

只有10%~20%的最終用戶回應時間花在了下載HTML檔案上，其余的80%~90%時間花在了下載頁面中的所有組件上，

2.定位：

2.1 技術上的選擇

在前端日常開發中，技術上的選擇是非常重要的，為什么要講這個呢？因為現象頻發，

前端工程化嚴重的當下，輕量化的框架慢慢被遺忘掉了，并不是所有的業務場景都適合使用工程化框架，react/vue 并不輕量，

復雜的框架是為了解決復雜的業務

如果研發h5、PC展示等場景簡單的業務時候，javascript原生 配合一些輕量化插件更適合，

多頁面應用也并不都是缺點，根據業務不同而選擇不一樣的技術是非常重要的，是每個前端都應該反思的事情，

這方面是導致卡頓的關鍵問題，

2.2 NetWork

我們的老朋友NetWork想必前端同學都很熟悉，我們先來看一下network面板

從面板上我們可以看出一些資訊：

• 請求資源size
• 請求資源時長
• 請求資源數量
• 介面回應時長
• 介面發起數量
• 介面報文size
• 介面回應狀態
• 瀑布圖

瀑布圖是什么呢？

瀑布圖就是上方圖片后面的waterfall縱列

瀑布圖是一個級聯圖, 展示了瀏覽器如何加載資源并渲染成網頁. 圖中的每一行都是一次單獨的瀏覽器請求. 這個圖越長, 說明加載網頁程序中所發的請求越多. 每一行的寬度, 代表瀏覽器發出請求并下載該資源的程序中所耗費的時間，它的側重點在于分析網路鏈路

瀑布圖顏色說明：

• DNS Lookup [深綠色] - 在瀏覽器和服務器進行通信之前, 必須經過DNS查詢, 將域名轉換成IP地址. 在這個階段, 你可以處理的東西很少. 但幸運的是, 并非所有的請求都需要經過這一階段.

• Initial Connection [橙色] - 在瀏覽器發送請求之前, 必須建立TCP連接. 這個程序僅僅發生在瀑布圖中的開頭幾行, 否則這就是個性能問題(后邊細說).

• SSL/TLS Negotiation [紫色] - 如果你的頁面是通過SSL/TLS這類安全協議加載資源, 這段時間就是瀏覽器建立安全連接的程序. 目前Google將HTTPS作為其 搜索排名因素 之一, SSL/TLS 協商的使用變得越來越普遍了.

• Time To First Byte (TTFB) [綠色] - TTFB 是瀏覽器請求發送到服務器的時間+服務器處理請求時間+回應報文的第一位元組到達瀏覽器的時間. 我們用這個指標來判斷你的web服務器是否性能不夠, 或者說你是否需要使用CDN.

• Downloading (藍色) - 這是瀏覽器用來下載資源所用的時間. 這段時間越長, 說明資源越大. 理想情況下, 你可以通過控制資源的大小來控制這段時間的長度.

那么除了瀑布圖的長度外，我們如何才能判斷一個瀑布圖的狀態是健康的呢？

• 首先, 減少所有資源的加載時間. 亦即減小瀑布圖的寬度. 瀑布圖越窄, 網站的訪問速度越快.

• 其次, 減少請求數量 也就是降低瀑布圖的高度. 瀑布圖越矮越好.

• 最后, 通過優化資源請求順序來加快渲染時間. 從圖上看, 就是將綠色的"開始渲染"線向左移. 這條線向左移動的越遠越好.

這樣，我們就可以從network的角度去排查“慢”的問題，

2.3 webpack-bundle-analyzer

專案構建后生成的bundle包是壓縮后的，webpack-bundle-analyzer是一款包分析工具，

我們先來看一下它能帶來的效果，如下圖：

從上圖來看，我們的bundle包被決議的一覽無余，其中模塊面積占的越大說明在bundle包中size越大，就值得注意了，重點優化一下，

它能夠排查出來的資訊有

• 顯示包中所有打入的模塊
• 顯示模塊size 及 gzip后的size

排查包中的模塊情形是非常有必要的，通過webpack-bundle-analyzer來排查出一些無用的模塊，過大的模塊，然后進行優化，以減少我們的bundle包size，減少加載時長，

安裝

# NPM 
npm install --save-dev webpack-bundle-analyzer
# Yarn 
yarn add -D webpack-bundle-analyzer
復制代碼

使用(as a Webpack-Plugin)

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
 
module.exports = {
  plugins: [
    new BundleAnalyzerPlugin()
  ]
}
復制代碼

然后構建包完畢后會自動彈出一個視窗展示上圖資訊，

2.4 Performance

chrome自帶的performance模塊，先附上一個官網檔案傳送門：Performance

可以檢測很多方面的資料，多數情況的性能排查上用的比較多，如果想要深入了解的同學建議去看一下官方檔案，

接下來我們來說一下在performance面板中如何排差“慢”的問題，它給我們提供了哪些資訊呢，先附上一張performance的面板圖片，

從上圖中可以分析出一些指標

• FCP/LCP 時間是否過長？
• 請求并發情況 是否并發頻繁？
• 請求發起順序 請求發起順序是否不對？
• javascript執行情況 javascript執行是否過慢？

這些指標就是我們需要重點關注的，當然performance的功能并不止于此，

先記住如何獲取到這些指標，后面來一一進行決議優化，

2.5 PerformanceNavigationTiming

獲取各個階段的回應時間，我們所要用到的介面是PerformanceNavigationTiming介面，

PerformanceNavigationTiming 提供了用于存盤和檢索有關瀏覽器檔案事件的指標的方法和屬性， 例如，此介面可用于確定加載或卸載檔案需要多少時間，

function showNavigationDetails() {
  const [entry] = performance.getEntriesByType("navigation");
  console.table(entry.toJSON());
}

使用這個函式，我們就可以獲取各個階段的回應時間，如圖：

引數說明

navigationStart 加載起始時間
redirectStart 重定向開始時間（如果發生了HTTP重定向，每次重定向都和當前檔案同域的話，就回傳開始重定向的fetchStart的值，其他情況，則回傳0）
redirectEnd 重定向結束時間（如果發生了HTTP重定向，每次重定向都和當前檔案同域的話，就回傳最后一次重定向接受完資料的時間，其他情況則回傳0）
fetchStart 瀏覽器發起資源請求時，如果有快取，則回傳讀取快取的開始時間
domainLookupStart 查詢DNS的開始時間，如果請求沒有發起DNS請求，如keep-alive，快取等，則回傳fetchStart
domainLookupEnd 查詢DNS的結束時間，如果沒有發起DNS請求，同上
connectStart 開始建立TCP請求的時間，如果請求是keep-alive，快取等，則回傳domainLookupEnd
(secureConnectionStart) 如果在進行TLS或SSL，則回傳握手時間
connectEnd 完成TCP鏈接的時間，如果是keep-alive，快取等，同connectStart
requestStart 發起請求的時間
responseStart 服務器開始回應的時間
domLoading 從圖中看是開始渲染dom的時間，具體未知
domInteractive 未知
domContentLoadedEventStart 開始觸發DomContentLoadedEvent事件的時間
domContentLoadedEventEnd DomContentLoadedEvent事件結束的時間
domComplete 從圖中看是dom渲染完成時間，具體未知
loadEventStart 觸發load的時間，如沒有則回傳0
loadEventEnd load事件執行完的時間，如沒有則回傳0
unloadEventStart unload事件觸發的時間
unloadEventEnd unload事件執行完的時間

關于我們的Web性能，我們會用到的時間引數：

DNS決議時間： domainLookupEnd - domainLookupStart
TCP建立連接時間： connectEnd - connectStart
白屏時間： responseStart - navigationStart
dom渲染完成時間： domContentLoadedEventEnd - navigationStart
頁面onload時間： loadEventEnd - navigationStart

根據這些時間引數，我們就可以判斷哪一階段對性能有影響，

2.6 抓包

有一些業務狀況是沒有上述的一些除錯工具該怎么辦呢？我們可以利用抓包工具進行對頁面資訊對抓取，上述我們通過chrome工具排查出來的指標，也可以通過抓包工具進行抓取，

這里我推薦一款抓包工具charles，

2.7 性能測驗工具

2.7.1 Pingdom

2.7.2 Load Impact

2.7.3 WebPage Test

2.7.4 Octa Gate Site Timer

2.7.5 Free Speed Test

3.優化：

前端的優化種類繁多，主要包含三個方面的優化：網路優化（對加載時所消耗的網路資源優化），代碼優化（資源加載完后，腳本解釋執行的速度），框架優化（選擇性能較好的框架，比如benchmark），

3.1 tree shaking

中文（搖樹），webpack構建優化中重要一環，搖樹用于清除我們專案中的一些無用代碼，它依賴于ES中的模塊語法，

比如日常使用lodash的時候

import _ from 'lodash'
復制代碼

如果如上參考lodash庫，在構建包的時候是會把整個lodash包打入到我們的bundle包中的，

import _isEmpty from 'lodash/isEmpty';
復制代碼

如果如上參考lodash庫，在構建包的時候只會把isEmpty這個方法抽離出來再打入到我們的bundle包中，

這樣的化就會大大減少我們包的size，所以在日常參考第三方庫的時候，需要注意匯入的方式，

如何開啟搖樹

在webpack4.x 中默認對tree-shaking進行了支持， 在webpack2.x 中使用tree-shaking：傳送門

3.2 split chunks

中文（分包）

在沒配置任何東西的情況下，webpack 4 就智能的幫你做了代碼分包，入口檔案依賴的檔案都被打包進了main.js，那些大于 30kb 的第三方包，如：echarts、xlsx、dropzone等都被單獨打包成了一個個獨立 bundle，

其它被我們設定了異步加載的頁面或者組件變成了一個個chunk，也就是被打包成獨立的bundle，

它內置的代碼分割策略是這樣的：

• 新的 chunk 是否被共享或者是來自 node_modules 的模塊
• 新的 chunk 體積在壓縮之前是否大于 30kb
• 按需加載 chunk 的并發請求數量小于等于 5 個
• 頁面初始加載時的并發請求數量小于等于 3 個

大家可以根據自己的專案環境來更改配置，配置代碼如下：

splitChunks({
  cacheGroups: {
    vendors: {
      name: `chunk-vendors`,
      test: /[\\/]node_modules[\\/]/,
      priority: -10,
      chunks: 'initial',
    },
    dll: {
      name: `chunk-dll`,
      test: /[\\/]bizcharts|[\\/]\@antv[\\/]data-set/,
      priority: 15,
      chunks: 'all',
      reuseExistingChunk: true
    },
    common: {
      name: `chunk-common`,
      minChunks: 2,
      priority: -20,
      chunks: 'all',
      reuseExistingChunk: true
    },
  }
})
復制代碼

沒有使用webpack4.x版本的專案，依然可以通過按需加載的形式進行分包，使得我們的包分散開，提升加載性能，

按需加載也是以前分包的重要手段之一

這里推薦一篇非常好的文章：webpack如何使用按需加載

3.3 拆包

與3.2的分包不同，大家可能沒發現，上面2.3的bundle包決議中有個有趣的現象，上面專案的技術堆疊是react，但是bundle包中并沒有react、react-dom、react-router等，

因為把這些插件“拆”開了，并沒有一起打在bundle中，而是放在了CDN上，下面我舉一個例子來解釋一下，

假設：原本bundle包為2M，一次請求拉取，拆分為 bundle（1M） + react桶（CDN）（1M） 兩次請求并發拉取，

從這個角度來看，1+1的模式拉取資源更快，

換一個角度來說，全量部署專案的情況，每次部署bundle包都將重新拉取，比較浪費資源，react桶的方式可以命中強快取，這樣的化，就算全量部署也只需要重新拉取左側1M的bundle包即可，節省了服務器資源，優化了加載速度，

注意：在本地開發程序中，react等資源建議不要引入CDN，開發程序中重繪頻繁，會增加CDN服務其壓力，走本地就好，

3.4 gzip

服務端配置gzip壓縮后可大大縮減資源大小，

Nginx配置方式

http {
  gzip on;
  gzip_buffers 32 4K;
  gzip_comp_level 6;
  gzip_min_length 100;
  gzip_types application/javascript text/css text/xml;
  gzip_disable "MSIE [1-6]\.";
  gzip_vary on;
}
復制代碼

配置完成后在response header中可以查看，

3.5 圖片壓縮

開發中比較重要的一個環節，我司自己的圖床工具是自帶壓縮功能的，壓縮后直接上傳到CDN上，

如果公司沒有圖床工具，我們該如何壓縮圖片呢？我推薦幾種我常用的方式

• 智圖壓縮 (百度很難搜到官網了，免費、批量、好用)
• tinypng(免費、批量、速度塊)
• fireworks工具壓縮像素點和尺寸 (自己動手，掌握尺度)
• 找UI壓縮后發給你

圖片壓縮是常用的手法，因為設備像素點的關系，UI給予的圖片一般都是 x2，x4的，所以壓縮就非常有必要，

3.6 圖片分割

如果頁面中有一張效果圖，比如真機渲染圖，UI手拿著刀不讓你壓縮，這時候不妨考慮一下分割圖片，

建議單張土圖片的大小不要超過100k，我們在分割完圖片后，通過布局再拼接在一起，可以圖片加載效率，

這里注意一點，分割后的每張圖片一定要給height，否則網速慢的情況下樣式會塌陷，

3.7 sprite

南方叫精靈圖，北方叫雪碧圖，這個現象就很有趣，

在網站中有很多小圖片的時候，一定要把這些小圖片合并為一張大的圖片，然后通過background分割到需要展示的圖片，

這樣的好處是什么呢？先來普及一個規則

瀏覽器請求資源的時候，同源域名請求資源的時候有最大并發限制，chrome為6個，就比如你的頁面上有10個相同CDN域名小圖片，那么需要發起10次請求去拉取，分兩次并發，第一次并發請求回來后，發起第二次并發，

如果你把10個小圖片合并為一張大圖片的畫，那么只用一次請求即可拉取下來10個小圖片的資源，減少服務器壓力，減少并發，減少請求次數，

附上一個sprite的例子，

3.8 CDN

中文（內容分發網路），服務器是中心化的，CDN是“去中心化的”，

在專案中有很多東西都是放在CDN上的，比如：靜態檔案，音頻，視頻，js資源，圖片，那么為什么用CDN會讓資源加載變快呢？

舉個簡單的例子：

以前買火車票大家都只能去火車站買，后來我們買火車票就可以在樓下的火車票代售點買了，

你細品，

所以靜態資源度建議放在CDN上，可以加快資源加載的速度，

3.9 懶加載

懶加載也叫延遲加載，指的是在長網頁中延遲加載影像，是一種非常好的優化網頁性能的方式，

當可視區域沒有滾到資源需要加載的地方時候，可視區域外的資源就不會加載，

可以減少服務器負載，常適用于圖片很多，頁面較長的業務場景中，

如何使用懶加載呢？

• 圖片懶加載
• layzr.js

3.10 iconfont

中文（字體圖表），現在比較流行的一種用法，使用字體圖表有幾種好處

• 矢量
• 輕量
• 易修改
• 不占用圖片資源請求，

就像上面說的雪碧圖，如果都用字體圖示來替換的畫，一次請求都免了，可以直接打到bundle包中，

使用前提是UI給點力，設計趨向于字體圖示，提前給好資源，建立好字體圖示庫，

3.11 邏輯后移

邏輯后移是一種比較常見的優化手段，用一個打開文章網站的操作來舉個例子，

沒有邏輯后移處理的請求順序是這個樣子的

頁面的展示主體是文章展示，如果文章展示的請求靠后了，那么渲染文章出來的時間必然靠后，因為有可能因為請求阻塞等情況，影響請求回應情況，如果超過一次并發的情況的話，會更加的慢，如圖的這種情況也是在我們專案中發生過的，

很明顯我們應該把主體“請求文章”介面前移，把一些非主體的請求邏輯后移，這樣的話可以盡快的把主體渲染出來，就會快很多，

優化后的順序是這個樣子的，

在平常的開發中建議時常注意邏輯后移的情況，突出主體邏輯，可以極大的提升用戶體驗，

3.12 演算法復雜度

在資料量大的應用場景中，需要著重注意演算法復雜度問題，

在這個方面可以參考Javascript演算法之復雜度分析這篇文章，

如上面Performance決議出的Javascript執行指標上，可以推測出來你的code執行效率如何，如果執行時間過長就要考慮一下是否要優化一下復雜度了，

在時間換空間，空間換時間的選擇上，要根據業務場景來進行取舍，

3.13 組件渲染

拿react舉例，組件分割方面不要太深，需要控制組件的渲染，尤其是深層組件的render，

老生常談的話題，我們可以一些方式來優化組件渲染

• 宣告周期控制 - 比如react的shouldComponentUpdate來控制組件渲染，
• 官網提供的api- PureComponent
• 控制注入組件的引數
• 分配組件唯一key

沒有必要的渲染是對性能的極大浪費，

3.14 node middleware

中文（node 中間件）

中間件主要是指封裝所有Http請求細節處理的方法，一次Http請求通常包含很多作業，如記錄日志、ip過濾、查詢字串、請求體決議、Cookie處理、權限驗證、引數驗證、例外處理等，但對于Web應用而言，并不希望接觸到這么多細節性的處理，因此引入中間件來簡化和隔離這些基礎設施與業務邏輯之間的細節，讓我們能夠關注在業務的開發上，以達到提升開發效率的目的，

使用node middleware合并請求，減少請求次數，這種方式也是非常實用的，

3.15 web worker

Web Worker 的作用，就是為 JavaScript 創造多執行緒環境，允許主執行緒創建 Worker 執行緒，將一些任務分配給后者運行，在主執行緒運行的同時，Worker 執行緒在后臺運行，兩者互不干擾，等到 Worker 執行緒完成計算任務，再把結果回傳給主執行緒，這樣的好處是，一些計算密集型或高延遲的任務，被 Worker 執行緒負擔了，主執行緒（通常負責 UI 互動）就會很流暢，不會被阻塞或拖慢，

合理實用web worker可以優化復雜計算任務，這里直接拋阮一峰的入門文章：傳送門

3.16 快取

快取的原理就是更快讀寫的存盤介質+減少IO+減少CPU計算=性能優化，而性能優化的第一定律就是：優先考慮使用快取，

快取的主要手段有：瀏覽器快取、CDN、反向代理、本地快取、分布式快取、資料庫快取，

3.17 GPU渲染

每個網頁或多或少都涉及到一些CSS影片，通常簡單的影片對于性能的影響微乎其微，然而如果涉及到稍顯復雜的影片，不當的處理方式會使性能問題變得十分突出，

像Chrome, FireFox, Safari, IE9+和最新版本的Opera都支持GPU加速，當它們檢測到頁面中某個DOM元素應用了某些CSS規則時就會開啟，

雖然我們可能不想對元素應用3D變換，可我們一樣可以開啟3D引擎，例如我們可以用transform: translateZ(0) 來開啟GPU加速 ，

只對我們需要實作影片效果的元素應用以上方法，如果僅僅為了開啟硬體加速而隨便亂用，那是不合理的，

3.18 Ajax可快取

Ajax在發送的資料成功后，為了提高頁面的回應速度和用戶體驗，會把請求的URL和回傳的回應結果保存在快取內，當下一次呼叫Ajax發送相同的請求（URL和引數完全相同）時，它就會直接從快取中拿資料，

在進行Ajax請求的時候，可以選擇盡量使用get方法，這樣可以使用客戶端的快取，提高請求速度，

3.19 Resource Hints

Resource Hints(資源預加載)是非常好的一種性能優化方法，可以大大降低頁面加載時間，給用戶更加流暢的用戶體驗，

現代瀏覽器使用大量預測優化技術來預測用戶行為和意圖，這些技術有預連接、資源與獲取、資源預渲染等，

Resource Hints 的思路有如下兩個：

• 當前將要獲取資源的串列
• 通過當前頁面或應用的狀態、用戶歷史行為或 session 預測用戶行為及必需的資源

實作Resource Hints的方法有很多種，可分為基于 link 標簽的 DNS-prefetch、subresource、preload、 prefetch、preconnect、prerender，和本地存盤 localStorage，

3.20 SSR

渲染程序在服務器端完成，最終的渲染結果 HTML 頁面通過 HTTP 協議發送給客戶端，又被認為是‘同構'或‘通用'，如果你的專案有大量的detail頁面，相互特別頻繁，建議選擇服務端渲染，

服務端渲染(SSR)除了SEO還有很多時候用作首屏優化，加快首屏速度，提高用戶體驗，但是對服務器有要求，網路傳輸資料量大，占用部分服務器運算資源，

Vue的Nuxt.js和React的next.js都是服務端渲染的方法，

3.21 UNPKG

UNPKG是一個提供npm包進行CDN加速的站點，因此，可以將一些比較固定了依賴寫入html模版中，從而提高網頁的性能，首先，需要將這些依賴宣告為external，以便webpack打包時不從node_modules中加載這些資源，配置如下：

externals: { 'react': 'React' }

其次，你需要將所依賴的資源寫在html模版中，這一步需要用到html-webpack-plugin，下面是一段示例：

<% if (htmlWebpackPlugin.options.node_env === 'development') { %>
  <script src="https://unpkg.com/react@16.7.0/umd/react.development.js"></script>
<% } else { %>
  <script src="https://unpkg.com/react@16.7.0/umd/react.production.min.js"></script>
<% } %>

這段代碼需要注入node_env，以便在開發的時候能夠獲得更友好的錯誤提示，也可以選擇一些比較自動的庫，來幫助我們完成這個程序，比如webpack-cdn-plugin，或者dynamic-cdn-webpack-plugin，

4.總結：

還有一些比較常用的優化方法我沒有列舉出來，例如將樣式表放在頂部，將腳本放在底部，減少重繪，按需加載，模塊化等，方法很多，對癥下藥才是關鍵，

借鑒了很多大佬最后總結出來的文章，希望自己和同為菜鳥的小伙伴可以永遠懷著一顆學徒的心，