前端性能優(yōu)化的目的在于讓頁面加載的更快，為用戶帶來更好的用戶體驗(yàn)。那么前端性能要如何優(yōu)化？具體要怎么做？下面本篇文章就來帶大家了解一些關(guān)于前端性能優(yōu)化的知識點(diǎn)。

反復(fù)看下以下三個(gè)問題。

• 有木有不同的人問過你：什么是前端性能優(yōu)化？
• 有木有不同的面試官問過你：你為前端性能優(yōu)化做過什么？
• 有木有哪一次，你問過自己：別人問我前端性能優(yōu)化到底應(yīng)該如何答復(fù)？
• 你有木有一套自己的關(guān)于性能優(yōu)化的答案，能讓技術(shù)大牛和你一起探討，也能讓小白點(diǎn)頭稱是。

假如你有，那你的答案在哪。

我們先來探討一件事情，一個(gè)前端項(xiàng)目如何從構(gòu)思到落地

例如整個(gè)天貓首頁。答案有很多種，你看看有木有你想的那種。

• create-react-app 初始化一個(gè)項(xiàng)目吧。 首頁寫好一些組件，例如豆腐塊、Header、Bar、長滾動ScrollView。然后項(xiàng)目編譯、打包上線。

• webpack手搭一個(gè)項(xiàng)目。

  • 路由按需加載弄上，可無痕瀏覽的帶loadmore的高性能ScrollList。

  • 因?yàn)槭鞘醉摚黠@會牽扯到首屏幕加載的問題。那骨架屏給安排上吧。

  • 再搞一套webpack的最佳實(shí)踐，目的是能最終得到體積盡量小的打包文件。

  • SSR來一套吧。因?yàn)槭醉揇OM結(jié)構(gòu)太復(fù)雜了，如果走Virtual DOM那一套，等到GPU渲染UI就太慢了。

以上，有命中你的某個(gè)點(diǎn)嗎？ 不管有木有道理，這是你想到的點(diǎn)嗎？是不是總感覺好像少了點(diǎn)什么？

本篇文章不細(xì)講其它內(nèi)容。 但到這了就得提一嘴，留個(gè)印象。

• 系統(tǒng)層設(shè)計(jì)
  • 一個(gè)新系統(tǒng)留20%來滿足當(dāng)前已有業(yè)務(wù)。 剩下80% 用來系統(tǒng)演進(jìn)?？梢运伎枷拢熵埵醉撘恢弊?，卻依然能保證性能達(dá)標(biāo)。
• 業(yè)務(wù)層設(shè)計(jì)
  • 已有業(yè)務(wù)是否與其它業(yè)務(wù)產(chǎn)生了耦合，是否存在前置業(yè)務(wù)，如果有那前置業(yè)務(wù)的權(quán)限又在哪里。已有業(yè)務(wù)是否能根據(jù)系統(tǒng)演進(jìn)程度不斷兼容新業(yè)務(wù)？
• 應(yīng)用層設(shè)計(jì)
  • 例如微前端，例如組件庫，例如npm install
  • webpack優(yōu)化
  • 骨架屏
  • 路有動態(tài)按需加載
• 代碼層設(shè)計(jì)
  • 寫好高性能React 代碼？如何利用好Vue3 時(shí)間切片？
  • 不說了。太初級的浪費(fèi)慢慢積累就好。

所以，你應(yīng)該發(fā)現(xiàn)了“總感覺好像少了點(diǎn)什么” 是少在哪里了。對，前端性能優(yōu)化不僅僅是應(yīng)用層面、代碼層的優(yōu)化，更重要的是系統(tǒng)層、業(yè)務(wù)層的優(yōu)化。

看了以上的心理預(yù)設(shè)，那接下來就進(jìn)入正式進(jìn)入主題吧。

性能優(yōu)化流程

嘗試著走完下面這個(gè)流程：

• 性能指標(biāo)設(shè)定（FPS、頁面秒開率、報(bào)錯(cuò)率、請求數(shù)等）

  • 如何讓老板了解你的優(yōu)化方案？假如你的老板不懂技術(shù)。
  • 告訴老板，頁面白屏?xí)r間減少了0.4s。
  • 告訴老板，弱網(wǎng)情況下首頁秒開。
  • 告訴老板，以前http請求量大導(dǎo)致服務(wù)器壓力太大了，現(xiàn)在每個(gè)頁面最多只有不到5個(gè)請求是向服務(wù)器要資源的。
  • 告訴老板……

• 性能標(biāo)準(zhǔn)確定

  • 確認(rèn)要哪些指標(biāo)

• 收益評估

  • 面向老板滿意編程。 /捂臉.png （手動狗頭）

• 診斷清單

  • 清單上會告訴你各項(xiàng)指標(biāo)的數(shù)據(jù)。

• 優(yōu)化手段

  • Hybrid APP 性能優(yōu)化

    • App 啟動階段的優(yōu)化方案
    • 頁面白屏階段的優(yōu)化方案
    • 首屏渲染階段的優(yōu)化方案

  • 首評秒開的X種方法？

    • 懶加載
    • 緩存
    • 離線化
      • 保證首次加載為秒開的離線包設(shè)計(jì)
    • 并行化

  • 骨架屏

    • 組件骨架屏
    • 圖片骨架屏

  • NSR

  • SSR

  • webView層及代碼架構(gòu)層面優(yōu)化

    • WebView 性能優(yōu)化
    • 并行初始化
    • 資源預(yù)加載
    • 數(shù)據(jù)接口請求優(yōu)化
    • 前端架構(gòu)性能調(diào)優(yōu)
      • 長列表性能優(yōu)化
      • 打包優(yōu)化

• 性能立項(xiàng)

  • 確定了就去搞起來吧。

• 性能實(shí)踐

  • 做好準(zhǔn)備，盡情的在各種惡劣環(huán)境下把頁面快速的折騰出來吧！

小結(jié)

現(xiàn)在，你對前端性能優(yōu)化有了一個(gè)完整的認(rèn)知了嗎？很多時(shí)候談?wù)摰叫阅軆?yōu)化首先需要談到如何對性能進(jìn)行“確診”。雖然大部分情況，你不會被人問到是如何對性能進(jìn)行監(jiān)控的。（說話聲音越來越小。。。）

接下來就細(xì)談優(yōu)化手段

首屏秒開的多種優(yōu)化手段

1. 懶加載

最常見的優(yōu)化手段之一。

懶加載是指在長頁面加載過程時(shí)，先加載關(guān)鍵內(nèi)容，延遲加載非關(guān)鍵內(nèi)容。比如當(dāng)我們打開一個(gè)頁面，它的內(nèi)容超過了瀏覽器的可視區(qū)口大小，我們可以先加載前端的可視區(qū)域內(nèi)容，剩下的內(nèi)容等它進(jìn)入可視區(qū)域后再按需加載。

舉個(gè)栗子。天貓首頁精選。上圖。

正好是天貓618活動。這個(gè)IOS版的天貓首頁精選。如果你經(jīng)常訪問天貓首頁精選，你會發(fā)現(xiàn)它已經(jīng)幾乎做到了無痕瀏覽。懶加載在這就被運(yùn)用的很好，當(dāng)然，這里不僅僅是做了懶加載才達(dá)到這樣的效果。

那只說懶加載，天貓首頁精選做了什么呢？ 猜猜看。

懶加載

• 圖片懶加載
  • 圖片是native做過緩存的。
  • 在可視區(qū)域出現(xiàn)才會加載
• 卡片預(yù)先加載（懶加載的時(shí)機(jī)改變）
  • 并不是進(jìn)入可視區(qū)域才加載卡片的。而是當(dāng)上一張卡片進(jìn)入可視區(qū)域就預(yù)先加載下一張卡片。 因?yàn)橄鄬τ趫D片，加載卡片UI會快得多。 這也是無痕瀏覽的保障之一。
• 動畫懶加載
  • 假如你快速的進(jìn)行劃屏滾動，List滾動高度發(fā)生很大變化，那請求數(shù)據(jù)最終還是會敵不過你的高速滑動。也就是說，在沒有新的數(shù)據(jù)之前你看不到下一張卡片了，這是你必須等待了。這時(shí)候就會有一個(gè)loading的動畫顯示，接著等拿到了新數(shù)據(jù)，新卡片就會出現(xiàn)并且自動完全滑入可視區(qū)域。
  • 這里會有人說了，IOS的阻尼本來就會使得動畫、滾動效果更加順暢。在這里為想說的是，Android也一樣可以。

2. 緩存

如果說懶加載本質(zhì)是提供首屏后請求非關(guān)鍵內(nèi)容的能力，那么緩存則是賦予二次訪問不需要重復(fù)請求的能力。在首屏優(yōu)化方案中，接口緩存和靜態(tài)資源緩存起到中流砥柱的作用。

回到剛才懶加載提到的那個(gè)問題，為什么你要快速劃屏一段時(shí)間才會遇見沒有新數(shù)據(jù)的情況？原因就是緩存的數(shù)據(jù)已經(jīng)用完了，所以只能讓服務(wù)器給予最新的數(shù)據(jù)。

• 接口緩存接口緩存的實(shí)現(xiàn)，如果是端內(nèi)的話，所有請求都走 Native 請求，以此來實(shí)現(xiàn)接口緩存。為什么要這么做呢？

  App 中的頁面展現(xiàn)有兩種形式，使用 Native 開發(fā)的頁面展現(xiàn)和使用 H5 開發(fā)的頁面展現(xiàn)。如果統(tǒng)一使用 Native 做請求的話，已經(jīng)請求過的數(shù)據(jù)接口，就不用請求了。而如果使用 H5 請求數(shù)據(jù)，必須等 WebView 初始化之后才能請求（也就是串行請求），而 Native 請求時(shí)，可以在 WebView 初始化之前就開始請求數(shù)據(jù)（也就是并行請求），這樣能有效節(jié)省時(shí)間。

  那么，如何通過 Native 進(jìn)行接口緩存呢？我們可以借助 SDK 封裝來實(shí)現(xiàn)，即修改原來的數(shù)據(jù)接口請求方法，實(shí)現(xiàn)類似 Axios 的請求方法。具體來說就是，把包括 post、Get 和 Request 功能的接口，封裝進(jìn) SDK 中。

  這樣，客戶端發(fā)起請求時(shí)，程序會調(diào)用 SDK.axios 方法，WebView 會攔截這個(gè)請求，去查看 App 本地是否有數(shù)據(jù)緩存，如果有的話，就走接口緩存，如果沒有的話，先向服務(wù)端請求數(shù)據(jù)接口，獲取接口數(shù)據(jù)后存放到 App 緩存中。

• 靜態(tài)資源緩存先看圖。

91 requests，113 kB transferred, 2.2 MB resources,Finish: 2.93 s,DOMContentLoaded: 177 ms.2.2M的資源，達(dá)到秒開?？纯碨ize那一列，你就應(yīng)該好像領(lǐng)悟到什么了。

沒錯(cuò)。HTTP緩存。 數(shù)據(jù)接口的請求一般來說較少，只有幾個(gè)，而靜態(tài)資源（如 JS、CSS、圖片和字體等）的請求就太多了。以天貓首頁為例，91 個(gè)請求中除了少數(shù)script外，其余都是靜態(tài)資源請求。

那么，如何做靜態(tài)緩存方案呢？這里有兩種情況，一種是靜態(tài)資源長期不需要修改，還有一種是靜態(tài)資源修改頻繁的。你可以嘗試多刷新幾次頁面看看。

資源長期不變的話，比如 1 年都不怎么變化，我們可以使用強(qiáng)緩存，如 Cache-Control 來實(shí)現(xiàn)。具體來說可以通過設(shè)置 Cache-Control:max-age=31536000，來讓瀏覽器在一年內(nèi)直接使用本地緩存文件，而不是向服務(wù)端發(fā)出請求。

至于第二種，如果資源本身隨時(shí)會發(fā)生改動的，可以通過設(shè)置 Etag 實(shí)現(xiàn)協(xié)商緩存。具體來說，在初次請求資源時(shí)，設(shè)置 Etag（比如使用資源的 md5 作為 Etag），并且返回 200 的狀態(tài)碼，之后請求時(shí)帶上 If-none-match 字段，來詢問服務(wù)器當(dāng)前版本是否可用。如果服務(wù)端數(shù)據(jù)沒有變化，會返回一個(gè) 304 的狀態(tài)碼給客戶端，告訴客戶端不需要請求數(shù)據(jù)，直接使用之前緩存的數(shù)據(jù)即可。當(dāng)然，這里還涉及 WebView相關(guān)的東西，先不細(xì)講。。。

3. 離線化處理

離線化是指線上實(shí)時(shí)變動的資源數(shù)據(jù)靜態(tài)化到本地，訪問時(shí)走的是本地文件的方案。

離線包就是一是離線化的一種方案，是將靜態(tài)資源存儲到 App 本地的方案，這里先不細(xì)講。

但更復(fù)雜的另一種離線化方案：把頁面內(nèi)容靜態(tài)化到本地。離線化一般適合首頁或者列表頁等不需要登錄頁面的場景，同時(shí)能夠支持 SEO 功能。

那么，如何實(shí)現(xiàn)離線化呢？在打包構(gòu)建時(shí)預(yù)渲染頁面，前端請求落到 index.html 上時(shí)，已經(jīng)是渲染過的內(nèi)容。此時(shí)，可以通過 Webpack 的 prerender-spa-plugin 來實(shí)現(xiàn)預(yù)渲染，進(jìn)而實(shí)現(xiàn)離線化。

Webpack 實(shí)現(xiàn)預(yù)渲染的代碼示例如下：

// webpack.conf.js var path = require('path') var PrerenderSpaPlugin = require('prerender-spa-plugin') module.exports = {   // ...   plugins: [     new PrerenderSpaPlugin(       // 編譯后的html需要存放的路徑       path.join(__dirname, '../dist'),       // 列出哪些路由需要預(yù)渲染       [ '/', '/about', '/contact' ]     )   ] } // 面試的時(shí)候離線化能講到這，往往就是做死現(xiàn)場，但風(fēng)險(xiǎn)和收益成正比，值得冒險(xiǎn)。那就是，你有木有自己的預(yù)渲染方案。

4. 并行化

如果說懶加載、緩存和離線化都是在請求本身搞事情，想盡辦法減少請求或者推遲請求，那并行化則是在請求通道上優(yōu)化問題，解決請求阻塞問題，進(jìn)而減少首屏?xí)r間。

例如廣州打疫苗排隊(duì)，新聞上報(bào)道是如何如何阻塞。 那除了讓群眾錯(cuò)開打疫苗的時(shí)間，還可以增加打疫苗的醫(yī)生數(shù)量。我們在處理請求阻塞時(shí)，也可以加大請求通道數(shù)量——借助于HTTP 2.0 的多路復(fù)用方案來解決。

HTTP 1.1 時(shí)代，有兩個(gè)性能瓶頸點(diǎn)，串行的文件傳輸和同域名的連接數(shù)限制（6個(gè)）。到了HTTP 2.0 時(shí)代，因?yàn)樘峁┝硕嗦窂?fù)用的功能，傳輸數(shù)據(jù)不再使用文本傳輸（文本傳輸必須按順序傳輸，否則接收端不知道字符的順序），而是采用二進(jìn)制數(shù)據(jù)幀和流的方式進(jìn)行傳輸。

其中，幀是數(shù)據(jù)接收的最小單位，流是連接中的一個(gè)虛擬通道，它可以承載雙向信息。每個(gè)流都會有一個(gè)唯一的整數(shù) ID 對數(shù)據(jù)順序進(jìn)行標(biāo)識，這樣接收端收到數(shù)據(jù)后，可以按照順序?qū)?shù)據(jù)進(jìn)行合并，不會出現(xiàn)順序出錯(cuò)的情況。所以，在使用流的情況下，不論多少個(gè)資源請求，只要建立一個(gè)連接即可。

文件傳輸環(huán)節(jié)問題解決后，同域名連接數(shù)限制問題怎么解決呢？以 Nginx 服務(wù)器為例，原先因?yàn)槊總€(gè)域名有6個(gè)連接數(shù)限制，最大并發(fā)就是 100 個(gè)請求，采用 HTTP 2.0 之后，現(xiàn)在則可以做到 600，提升了 6倍。

你一定會問，這不是運(yùn)維側(cè)要做的事情嗎，我們前端開發(fā)需要做什么？我們要改變靜態(tài)文件合并（JS、CSS、圖片文件）和靜態(tài)資源服務(wù)器做域名散列這兩種開發(fā)方式。

具體來說，使用 HTTP 2.0 多路復(fù)用之后，單個(gè)文件可以單獨(dú)上線，不需要再做 JS 文件合并了。這里提一個(gè)保留問題，用過阿里系的Antd組件庫吧？庫每次更新都不是全部更新，可能這次只更新一個(gè)Button組件，再次只更新一個(gè)Card組件。那是如何做到單獨(dú)組件單獨(dú)發(fā)版的呢？

為了解決靜態(tài)域名阻塞（這是個(gè)性能瓶頸點(diǎn)），需要將靜態(tài)域名分為 pic0-pic5，這樣能提升請求并行能力。 雖然通過靜態(tài)資源域名散列的辦法解決了問題，但DNS 解析時(shí)間會變長很多，同時(shí)還需要額外的服務(wù)器來滿足。HTTP 2.0 多路復(fù)用解決了這個(gè)問題。