性能優(yōu)化經(jīng)驗(yàn)分享
背景
近期，開發(fā) C 端 h5 頁面時(shí)，發(fā)現(xiàn)首頁白屏?xí)r間比較長(zhǎng)，并且用戶也多次反映了這個(gè)問題，優(yōu)化這個(gè)首屏加載時(shí)間是遲早的事，所以在開始優(yōu)化前先做一些必要的知識(shí)儲(chǔ)備～
性能指標(biāo)
還在看那些老掉牙的性能優(yōu)化文章么？這些最新性能指標(biāo)了解下 [1]
FP & FCP
首次繪制，F(xiàn)P（First Paint），這個(gè)指標(biāo)用于記錄頁面第一次繪制像素的時(shí)間。
首次內(nèi)容繪制，F(xiàn)CP（First Contentful Paint），這個(gè)指標(biāo)用于記錄頁面首次繪制文本、圖片、非空白 Canvas 或 SVG 的時(shí)間。
FP 指的是繪制像素，比如說頁面的背景色是灰色的，那么在顯示灰色背景時(shí)就記錄下了 FP 指標(biāo)。但是此時(shí) DOM 內(nèi)容還沒開始繪制，可能需要文件下載、解析等過程，只有當(dāng) DOM 內(nèi)容發(fā)生變化才會(huì)觸發(fā)，比如說渲染出了一段文字，此時(shí)就會(huì)記錄下 FCP 指標(biāo)。因此說我們可以把這兩個(gè)指標(biāo)認(rèn)為是和白屏?xí)r間相關(guān)的指標(biāo)，所以肯定是最快越好。
LCP
最大內(nèi)容繪制，LCP（Largest Contentful Paint），用于記錄視窗內(nèi)最大的元素繪制的時(shí)間，該時(shí)間會(huì)隨著頁面渲染變化而變化，因?yàn)轫撁嬷械淖畲笤卦阡秩具^程中可能會(huì)發(fā)生改變，另外該指標(biāo)會(huì)在用戶第一次交互后停止記錄。指標(biāo)變化如下圖：
TTI
介紹 TTI 之前，首先要介紹一下長(zhǎng)任務(wù)，一個(gè)任務(wù)的耗時(shí)超過 50ms，這個(gè)任務(wù)就可以被認(rèn)為是長(zhǎng)任務(wù)，用戶的交互操作也是在主線程執(zhí)行的，所以當(dāng)發(fā)生 Long Task 時(shí)，用戶的交互操作很可能無法及時(shí)執(zhí)行，這時(shí)用戶就會(huì)體驗(yàn)到卡頓（當(dāng)頁面響應(yīng)時(shí)間超過 100ms 時(shí)，用戶可以體驗(yàn)到卡頓）。
首次可交互時(shí)間，TTI（Time to Interactive），測(cè)量頁面所有資源加載成功并能夠可靠地快速響應(yīng)用戶輸入的時(shí)間。通常是發(fā)生在頁面依賴的資源已經(jīng)加載完成，此時(shí)瀏覽器可以快速響應(yīng)用戶交互的時(shí)間。指標(biāo)的計(jì)算過程，需要滿足以下幾個(gè)條件：
- 從 FCP 指標(biāo)后開始計(jì)算；
- 持續(xù) 5 秒內(nèi)無長(zhǎng)任務(wù)（執(zhí)行時(shí)間超過 50 ms）且無兩個(gè)以上正在進(jìn)行中的 GET 請(qǐng)求；
- 往前回溯至 5 秒前的最后一個(gè)長(zhǎng)任務(wù)結(jié)束的時(shí)間。
FID
首次輸入延遲，F(xiàn)ID（First Input Delay），記錄在 FCP 和 TTI 之間用戶首次與頁面交互時(shí)響應(yīng)的延遲。記錄第一次與頁面交互到瀏覽器真正能夠處理響應(yīng)該交互的時(shí)間，這個(gè)延遲出現(xiàn)的原因是瀏覽器的主線程可能在忙于其他工作，比如解析 JS 文件等，所以無法及時(shí)響應(yīng)用戶。
TBT
阻塞總時(shí)間，TBT（Total Blocking Time），記錄在 FCP 到 TTI 之間所有長(zhǎng)任務(wù)的阻塞時(shí)間總和。主線程執(zhí)行的任務(wù)分為長(zhǎng)任務(wù)和短任務(wù)。規(guī)定持續(xù)時(shí)間超過 50ms 的任務(wù)為長(zhǎng)任務(wù)，低于 50ms 的任務(wù)為短任務(wù)。長(zhǎng)任務(wù)中超過 50ms 的時(shí)間被認(rèn)為是“阻塞”的，因此，TBT 是所有長(zhǎng)任務(wù)中阻塞時(shí)間的總和。TBT = FCP 和 TTI 之間發(fā)生的每個(gè)長(zhǎng)任務(wù)的「阻塞時(shí)間」總和。例：
上圖，有三個(gè)長(zhǎng)任務(wù)，兩個(gè)短任務(wù)。
而 TBT 時(shí)長(zhǎng)為 200+40+105=345ms。
CLS
累計(jì)位移偏移，CLS（Cumulative Layout Shift），記錄了頁面上非預(yù)期的位移波動(dòng)。比如：頁面渲染過程中突然插入一張巨大的圖片或者說點(diǎn)擊了某個(gè)按鈕突然動(dòng)態(tài)插入了一塊內(nèi)容等等相當(dāng)影響用戶體驗(yàn)的網(wǎng)站。這個(gè)指標(biāo)就是為這種情況而生的，計(jì)算方式為：位移影響的面積 * 位移距離。
以上圖為例，文本移動(dòng)了 25% 的屏幕高度距離（位移距離），位移前后影響了 75% 的屏幕高度面積（位移影響的面積），那么 CLS 為 0.25 * 0.75 = 0.1875。CLS 推薦值為低于 0.1，越低說明頁面跳來跳去的情況就越少，用戶體驗(yàn)越好。畢竟很少有人喜歡閱讀或者交互過程中網(wǎng)頁突然動(dòng)態(tài)插入 DOM 的情況，比如說插入廣告。
關(guān)鍵指標(biāo)
- LCP 代表了頁面的速度指標(biāo)，雖然還存在其他的一些體現(xiàn)速度的指標(biāo)，但是上文也說過 LCP 能體現(xiàn)的東西更多一些。一是指標(biāo)實(shí)時(shí)更新，數(shù)據(jù)更精確，二是代表著頁面最大元素的渲染時(shí)間，通常來說頁面中最大元素的快速載入能讓用戶感覺性能還挺好。
- FID 代表了頁面的交互體驗(yàn)指標(biāo)，畢竟沒有一個(gè)用戶希望觸發(fā)交互以后頁面的反饋很遲緩，交互響應(yīng)的快會(huì)讓用戶覺得網(wǎng)頁挺流暢。
- CLS 代表了頁面的穩(wěn)定指標(biāo)，尤其在手機(jī)上這個(gè)指標(biāo)更為重要。因?yàn)槭謾C(jī)屏幕挺小，CLS 值一大的話會(huì)讓用戶覺得頁面體驗(yàn)做的很差。
優(yōu)化手段
網(wǎng)絡(luò)層面
開啟 gzip 壓縮
Vue 項(xiàng)目性能優(yōu)化 — 實(shí)踐指南（網(wǎng)上最全 / 詳細(xì)） [2]
gzip 是 GNUzip 的縮寫，最早用于 UNIX 系統(tǒng)的文件壓縮。HTTP 協(xié)議上的 gzip 編碼是一種用來改進(jìn) web 應(yīng)用程序性能的技術(shù)，web 服務(wù)器和客戶端（瀏覽器）必須共同支持 gzip。目前主流的瀏覽器，Chrome，firefox，IE 等都支持該協(xié)議。常見的服務(wù)器如 Apache，Nginx，IIS 同樣支持，gzip 壓縮效率非常高，通常可以達(dá)到 70% 的壓縮率。
使用 http2
HTTP2.0 新特性 [3]
HTTP2.0 大幅度的提高了 web 性能，在 HTTP1.1 完全語義兼容的基礎(chǔ)上，進(jìn)一步減少了網(wǎng)絡(luò)的延遲。實(shí)現(xiàn)低延遲高吞吐量。對(duì)于前端開發(fā)者而言，減少了優(yōu)化工作。Http2 提供了以下一些新特性，對(duì)性能優(yōu)化有一定幫助。
- 二進(jìn)制分 幀：將所有傳輸信息分割為更小的消息和幀，并對(duì)它們采用二進(jìn)制格式的編碼將其封裝。二進(jìn)制分幀主要是為下文中的各種特性提供了基礎(chǔ)。它能把一個(gè)數(shù)據(jù)劃分封裝為更小更便捷的數(shù)據(jù)。首先是在單鏈接多資源方式中，減少了服務(wù)端的鏈接壓力，內(nèi)存占用更少，鏈接吞吐量更大。這一點(diǎn)可以結(jié)合下文中的多路復(fù)用來體會(huì)。另一方面，由于 TCP 鏈接的減少而使網(wǎng)絡(luò)擁塞狀態(tài)得以改善，同時(shí)慢啟動(dòng)時(shí)間的減少。使擁塞和丟包恢復(fù)的速度更快。
- 多路復(fù)用：基于二進(jìn)制分幀層，HTTP2.0 可以在共享 TCP 鏈接的基礎(chǔ)上同時(shí)發(fā)送請(qǐng)求和響應(yīng)。HTTP 消息被分解為獨(dú)立的幀，而不破壞消息本身的語義，交錯(cuò)發(fā)出去，在另一端根據(jù)流標(biāo)識(shí)符和首部將他們重新組裝起來?？梢圆⑿薪诲e(cuò)的發(fā)送請(qǐng)求和響應(yīng)，這些請(qǐng)求和響應(yīng)之間互不影響，消除不必要的延遲，減少頁面加載時(shí)間。
- 首部壓縮：對(duì)于相同的數(shù)據(jù)，不再重新通過每次請(qǐng)求和響應(yīng)發(fā)送。每個(gè)新的首部鍵值對(duì)要么追加到當(dāng)前表的末尾，要么替換表中之前的值。首部壓縮可以使報(bào)頭更緊湊，更快速傳輸，有利于移動(dòng)網(wǎng)絡(luò)環(huán)境。減少每次通訊的數(shù)據(jù)量，使網(wǎng)絡(luò)擁塞狀態(tài)得以改善。
- 優(yōu)先級(jí)：客戶端明確指定優(yōu)先級(jí)，服務(wù)端可以根據(jù)這個(gè)優(yōu)先級(jí)作為交互數(shù)據(jù)的依據(jù)，優(yōu)先將最高優(yōu)先級(jí)的幀發(fā)送給客戶端。
- 流量控制：由于一個(gè) TCP 連接流量帶寬（根據(jù)客戶端到服務(wù)器的網(wǎng)絡(luò)帶寬而定）是固定的，當(dāng)有多個(gè)請(qǐng)求并發(fā)時(shí)，一個(gè)請(qǐng)求占的流量多，另一個(gè)請(qǐng)求占的流量就會(huì)少。流量控制可以對(duì)不同的流的流量進(jìn)行精確控制。
- 服務(wù)器推送：服務(wù)端根據(jù)客戶端的請(qǐng)求，提前返回多個(gè)響應(yīng)，推送額外的資源給客戶端。服務(wù)端推送是一種在客戶端請(qǐng)求之前發(fā)送數(shù)據(jù)的機(jī)制。在 HTTP2.0 中，服務(wù)器可以對(duì)一個(gè)客戶端的請(qǐng)求發(fā)送多個(gè)響應(yīng)。如果一個(gè)請(qǐng)求是由你的主頁發(fā)送的，服務(wù)器可能會(huì)響應(yīng)主頁內(nèi)容、logo 以及樣式表，因?yàn)樗揽蛻舳藭?huì)用到這些東西。這樣不但減輕了數(shù)據(jù)傳送冗余步驟，也加快了頁面響應(yīng)的速度，提高了用戶體驗(yàn)。
iconfont 代替圖片圖標(biāo)
字體圖標(biāo)就是將圖標(biāo)制作成一個(gè)字體，使用時(shí)就跟字體一樣，可以設(shè)置屬性，例如 font-size、color 等，非常方便，并且字體圖標(biāo)是矢量圖，不會(huì)失真。還有一個(gè)優(yōu)點(diǎn)是生成的文件特別小，無論是加載還是打包所消耗的資源都相對(duì)較小一些。
圖片優(yōu)化
WebP 相對(duì)于 PNG、JPG 有什么優(yōu)勢(shì)？ [4]
圖片往往是一個(gè) h5 頁面的重要組成部分，然而圖片占用的資源往往也是很大的，因此圖片優(yōu)化在性能優(yōu)化中占據(jù)很重要的地位。下面來看幾種優(yōu)化圖片的方式。
- 圖片 懶加載：當(dāng)圖片出現(xiàn)在可視區(qū)域或者即將出現(xiàn)在可視區(qū)域時(shí)再加載圖片，避免一次性加載全部圖片，會(huì)對(duì)用戶體驗(yàn)造成很大影響。
-
降低圖片質(zhì)量：一些圖片適當(dāng)降低圖片質(zhì)量時(shí)，通常是看不出來區(qū)別的，尤其是作為背景圖片時(shí)，可以使用
image-webpack-loader進(jìn)行圖片壓縮。 - 盡量使用 CSS 代替圖片：一些簡(jiǎn)單的圖片效果如果可以通過 CSS 效果實(shí)現(xiàn)則進(jìn)行用 CSS 來實(shí)現(xiàn)，可以減小請(qǐng)求次數(shù)或者打包體積大小。
- 使用 webp 圖片：WebP 的優(yōu)勢(shì)體現(xiàn)在它具有更優(yōu)的圖像數(shù)據(jù)壓縮算法，能帶來更小的圖片體積，而且擁有肉眼識(shí)別無差異的圖像質(zhì)量；同時(shí)具備了無損和有損的壓縮模式、Alpha 透明以及動(dòng)畫的特性，在 JPEG 和 PNG 上的轉(zhuǎn)化效果都相當(dāng)優(yōu)秀、穩(wěn)定和統(tǒng)一。
按需加載
懶加載或者按需加載，是一種很好的優(yōu)化網(wǎng)頁或應(yīng)用的方式。這種方式實(shí)際上是先把你的代碼在一些邏輯斷點(diǎn)處分離開，然后在一些代碼塊中完成某些操作后，立即引用或即將引用另外一些新的代碼塊。這樣加快了應(yīng)用的初始加載速度，減輕了它的總體體積，因?yàn)槟承┐a塊可能永遠(yuǎn)不會(huì)被加載。
代碼層面
location.herf
在教師端項(xiàng)目中登錄重定向部分，由于歷史代碼邏輯問題，無法使用 react router 中的跳轉(zhuǎn)方式，所以選擇了使用location.herf進(jìn)行跳轉(zhuǎn)。雖然，功能上沒有問題，但是由于頁面在登錄過程中頻繁地重新加載，導(dǎo)致登錄重定向的過程十分緩慢，極大影響了用戶體驗(yàn)，所以考慮將登錄重定向部分代碼進(jìn)行重構(gòu)，避免使用location.herf。
CSS 策略
CSS 性能優(yōu)化的幾個(gè)技巧 [5]
想要優(yōu)化 CSS 的性能，我們首先需要了解 CSS 的渲染規(guī)則，CSS 選擇器是從右向左進(jìn)行匹配的。 CSS 中更多的選擇器是不會(huì)匹配的，所以在考慮性能問題時(shí)，需要考慮的是如何在選擇器不匹配時(shí)提升效率。從右向左匹配就是為了達(dá)成這一目的的，通過這一策略能夠使得 CSS 選擇器在不匹配的時(shí)候效率更高。這樣想來，在匹配時(shí)多耗費(fèi)一些性能也能夠想的通了。
- 避免出現(xiàn)超過三層的嵌套規(guī)則：元素的嵌套層級(jí)不能超過 3 級(jí)，過度的嵌套會(huì)導(dǎo)致代碼變得臃腫，沉余，復(fù)雜。導(dǎo)致 css 文件體積變大，造成性能浪費(fèi)，影響渲染的速度！而且過于依賴 HTML 文檔結(jié)構(gòu)。這樣的 css 樣式，維護(hù)起來，極度麻煩。
- 避免為 ID 選擇器添加多余選擇器：在 ID 選擇器前面嵌套其它選擇器純粹是多余的。
- 避免使用通配選擇器，只對(duì)目標(biāo)節(jié)點(diǎn)聲明規(guī)則。
- 避免重復(fù)匹配重復(fù)定義，關(guān)注可繼承屬性。
Dom 離線化
所謂的 Dom 離線化就是將要操作的元素從文檔流中脫離，然后再恢復(fù)它。離線的 DOM 不屬于當(dāng)前 DOM 樹中的任何一部分，這也就意味著我們對(duì)離線 DOM 處理就不會(huì)引起頁面的回流與重繪?？梢允褂?*display: none，上面我們說到了 (display: none) 將元素從渲染樹中完全移除，元素既不可見，也不是布局的組成部分，之后在該 DOM 上的操作不會(huì)觸發(fā)回流與重繪，操作完之后再將display**屬性改為顯示，只會(huì)觸發(fā)這一次回流與重繪。
SSR
【長(zhǎng)文慎入】一文吃透 React SSR 服務(wù)端渲染和同構(gòu)原理 [6]
在 SPA 模式下，所有的數(shù)據(jù)請(qǐng)求和 Dom 渲染都在瀏覽器端完成，所以當(dāng)我們第一次訪問頁面的時(shí)候很可能會(huì)存在“白屏”等待，而服務(wù)端渲染所有數(shù)據(jù)請(qǐng)求和 html 內(nèi)容已在服務(wù)端處理完成，瀏覽器收到的是完整的 html 內(nèi)容，可以更快的看到渲染內(nèi)容，在服務(wù)端完成數(shù)據(jù)請(qǐng)求肯定是要比在瀏覽器端效率要高的多。
SSR 對(duì) SEO 是相對(duì)友好的，有些網(wǎng)站的流量來源主要還是靠搜索引擎，所以網(wǎng)站的 SEO 還是很重要的，而 SPA 模式對(duì)搜索引擎不夠友好，要想徹底解決這個(gè)問題只能采用服務(wù)端直出。
當(dāng)然，SSR 也會(huì)帶了很多額外的工作量，而且會(huì)很大程度上增加項(xiàng)目的復(fù)雜度，這里需要做一個(gè)工作量與優(yōu)化之間的權(quán)衡～
防抖 & 截流
理解 JS 的節(jié)流、防抖及使用場(chǎng)景 [7]
防抖：防止抖動(dòng)，單位時(shí)間內(nèi)事件觸發(fā)會(huì)被重置，避免事件被誤傷觸發(fā)多次。代碼實(shí)現(xiàn)重在清零 clearTimeout。防抖可以比作等電梯，只要有一個(gè)人進(jìn)來，就需要再等一會(huì)兒。業(yè)務(wù)場(chǎng)景有避免登錄按鈕多次點(diǎn)擊的重復(fù)提交。
節(jié)流：控制流量，單位時(shí)間內(nèi)事件只能觸發(fā)一次，與服務(wù)器端的限流 (Rate Limit) 類似。代碼實(shí)現(xiàn)重在開鎖關(guān)鎖 timer=timeout; timer=null。節(jié)流可以比作過紅綠燈，每等一個(gè)紅燈時(shí)間就可以過一批。
Web Worker
淺談 HTML5 Web Worker [8]
Web Worker 是 HTML5 標(biāo)準(zhǔn)的一部分，這一規(guī)范定義了一套 API，它允許一段 JavaScript 程序運(yùn)行在主線程之外的另外一個(gè)線程中?？梢约虞d一個(gè) JS 進(jìn)行大量的復(fù)雜計(jì)算而不掛起主進(jìn)程，并通過 postMessage，onmessage 進(jìn)行通信，解決了大量計(jì)算對(duì) UI 渲染的阻塞問題。
打包層面
圖片使用 CDN
圖片資源是每個(gè)項(xiàng)目無法繞開的，在項(xiàng)目中，圖片資源往往是占打包體積比例較大的，并且圖片資源的壓縮效率也不是特別理想，所以為減少項(xiàng)目最后的打包體積，可以將圖片上傳至 CDN ，通過動(dòng)態(tài)加載的方式引入圖片，這樣就可以避免圖片增加打包體積了。
優(yōu)化 SourceMap
SourceMap 的可選值如下（+ 號(hào)越多，代表速度越快，- 號(hào)越多，代表速度越慢, o 代表中等速度 ）
開發(fā)環(huán)境推薦：cheap-module-eval-source-map
生產(chǎn)環(huán)境推薦：cheap-module-source-map
原因如下：
- cheap：源代碼中的列信息是沒有任何作用，因此我們打包后的文件不希望包含列相關(guān)信息，只有行信息能建立打包前后的依賴關(guān)系。因此不管是開發(fā)環(huán)境或生產(chǎn)環(huán)境，我們都希望添加 cheap 的基本類型來忽略打包前后的列信息；
- module ：不管是開發(fā)環(huán)境還是正式環(huán)境，我們都希望能定位到 bug 的源代碼具體的位置，比如說某個(gè) Vue 文件報(bào)錯(cuò)了，我們希望能定位到具體的 Vue 文件，因此我們也需要 module 配置；
- soure-map ：source-map 會(huì)為每一個(gè)打包后的模塊生成獨(dú)立的 soucemap 文件 ，因此我們需要增加 source-map 屬性；
- eval-source-map：eval 打包代碼的速度非常快，因?yàn)樗簧?map 文件，但是可以對(duì) eval 組合使用 eval-source-map 使用會(huì)將 map 文件以 DataURL 的形式存在打包后的 js 文件中。在正式環(huán)境中不要使用 eval-source-map, 因?yàn)樗鼤?huì)增加文件的大小，但是在開發(fā)環(huán)境中，可以試用下，因?yàn)樗麄兇虬乃俣群芸臁?/li>
壓縮 JS 和 CSS
如果你使用的是 webpack v5 或更高版本，是開箱機(jī)帶的功能，但是你的 webpack 是 v5 以下或者希望自定義配置，那么需要安裝 terser-webpack-plugin。如果使用 webpack v4，則必須安裝 terser-webpack-plugin v4 的版本。
第三方插件、庫的按需引入
我們?cè)陧?xiàng)目中經(jīng)常會(huì)需要引入第三方插件，如果我們直接引入整個(gè)插件，會(huì)導(dǎo)致項(xiàng)目的體積太大，我們可以借助 babel-plugin-component ，然后可以只引入需要的組件，以達(dá)到減小項(xiàng)目體積的目的，如 import lodash -> import lodash/get。還可以使用一些支持 Tree Shaking 的庫，如 import lodash -> import lodash/get。
總結(jié)
上述列出的只是有關(guān)于前端性能優(yōu)化的冰山一角，比較適合對(duì)優(yōu)化手段了解較少的同學(xué)用于知識(shí)儲(chǔ)備，有興趣的同學(xué)可以繼續(xù)閱讀其他性能優(yōu)化相關(guān)的文章。
下面分享幾篇我閱讀過的一些較全的文章，可以幫助你更深層次了解：
- 瀏覽器工作原理與實(shí)踐\_瀏覽器\_V8 原理-極客時(shí)間[9] - 強(qiáng)烈推薦 ??
- 前端性能優(yōu)化 24 條建議(2020) - 掘金 [10]
- 前端性能優(yōu)化三部曲(加載篇) [11]
- 全鏈路前端性能優(yōu)化(歡迎收藏) [12]
點(diǎn)擊上方關(guān)注 · 我們下期再見
參考資料
[1]還在看那些老掉牙的性能優(yōu)化文章么？這些最新性能指標(biāo)了解下: https://juejin.cn/post/6850037270729359367#heading-0
[2]Vue 項(xiàng)目性能優(yōu)化 — 實(shí)踐指南（網(wǎng)上最全 / 詳細(xì)）: https://juejin.cn/post/6844903913410314247#heading-22
[3]HTTP2.0 新特性: https://juejin.cn/post/6844903545532071943
[4]WebP 相對(duì)于 PNG、JPG 有什么優(yōu)勢(shì)？: https://www.zhihu.com/question/27201061
[5]CSS 性能優(yōu)化的幾個(gè)技巧: https://juejin.cn/post/7077347573740077069#heading-1
[6]【長(zhǎng)文慎入】一文吃透 React SSR 服務(wù)端渲染和同構(gòu)原理: https://juejin.cn/post/6844903943902855176
[7]理解 JS 的節(jié)流、防抖及使用場(chǎng)景: https://juejin.cn/post/6844903669389885453
[8]淺談 HTML5 Web Worker: https://juejin.cn/post/6844903496550989837
[9]瀏覽器工作原理與實(shí)踐_瀏覽器_V8 原理-極客時(shí)間: https://time.geekbang.org/column/intro/100033601
[10]前端性能優(yōu)化 24 條建議(2020) - 掘金: https://juejin.cn/post/6892994632968306702#heading-29
[11]前端性能優(yōu)化三部曲(加載篇): https://juejin.cn/post/6844903863963631623#heading-16
[12]全鏈路前端性能優(yōu)化(歡迎收藏): https://juejin.cn/post/6911512163249029134#heading-38