前端優化 10s 到(dào) 100ms 是(shì)如何做到(dào)的(de)？
發表時(shí)間：2021-1-5
發布人(rén)：融晨科技
浏覽次數：53
Open signal 官方提供了(le／liǎo)2019年2月份統計的(de)全世界4G網絡覆蓋率和(hé / huò)通信速率的(de)統計分布圖如下，在(zài)目前移動互聯網的(de)浪潮下，我們要(yào / yāo)利用好用戶終端設備的(de)每個(gè)字節的(de)流量。
頁面性能和(hé / huò)體驗優化并不(bù)是(shì)一蹴而(ér)就(jiù)的(de)，需要(yào / yāo)不(bù)斷的(de)研究、跟蹤，發現問題，解決問題。但是(shì)我們可以(yǐ)在(zài)一開始編寫業務代碼的(de)時(shí)候就(jiù)做的(de)更好，做到(dào)極緻。
加載渲染鏈路優化之(zhī)道(dào)
從訪問 URL 到(dào)頁面呈現，整個(gè)鏈路可以(yǐ)做優化的(de)思路。
幸運的(de)是(shì)，W3C推薦的(de)Navigation Timing标準中所定義的(de)核心的(de)頁面性能數據，它包含了(le／liǎo)從上(shàng)個(gè)頁面銷毀到(dào)跳轉到(dào)當前頁面加載完成每個(gè)階段所消耗的(de)時(shí)間。在(zài)canIuse上(shàng)查到(dào)的(de)兼容性也(yě)很好：
利用這(zhè)個(gè)接口可以(yǐ)很方便的(de)幫助我們排查鏈路問題。在(zài)Navigation Timing标準中介紹到(dào)這(zhè)個(gè)API主要(yào / yāo)包含兩個(gè)接口：PerformanceTiming和(hé / huò)PerformanceNavigation，這(zhè)兩個(gè)接口由浏覽器進行實現和(hé / huò)維護，當浏覽器創建頁面的(de)時(shí)候就(jiù)會把接口定義的(de)相關數據挂載到(dào)window.performance.timing和(hé / huò)window.performance.navigation這(zhè)兩個(gè)屬性上(shàng)。我們可以(yǐ)打開一個(gè)網頁看一下：
我們把這(zhè)兩個(gè)圖對比一下，就(jiù)可以(yǐ)很容易的(de)排查出(chū)頁面的(de)加載鏈路問題。
靜态資源鏈路
打開頁面的(de)第一步是(shì)請求頁面的(de)html，這(zhè)裏面涉及TTFB這(zhè)個(gè)綜合指标。同時(shí)如果有必要(yào / yāo)我們也(yě)可以(yǐ)統計DNS時(shí)間和(hé / huò)TCP時(shí)間。DNS時(shí)間：主要(yào / yāo)是(shì)根據請求域名查詢到(dào)對應主機IP的(de)時(shí)間。這(zhè)個(gè)和(hé / huò)DNS服務器有關系，也(yě)可能和(hé / huò)本地(dì / de)緩存有關，如果這(zhè)個(gè)很慢，可以(yǐ)找服務商排查下問題。TCP時(shí)間：TCP 是(shì)承接 HTTP 協議的(de)下層協議。主要(yào / yāo)是(shì)路由到(dào)主機 IP，并建立 TCP 鏈接的(de)時(shí)間。這(zhè)個(gè)時(shí)間反應了(le／liǎo)服務器到(dào)用戶客戶端之(zhī)間鏈路是(shì)否通暢，網絡是(shì)否通暢。
請求完HTML之(zhī)後，就(jiù)開始解析
HTML 代碼，按照從上(shàng)至下、自然順序解析，解析内聯 CSS代碼或者加載外鏈CSS腳本，解析内聯 Javascript 腳本，或者加載外鏈
Javascript 腳本。由于(yú)浏覽器是(shì)單線程的(de)，這(zhè)些 CSS 和(hé / huò) Javascript 腳本很可能就(jiù)會造成頁面卡頓。
加載
CDN是(shì)内容分發網絡，主要(yào / yāo)用于(yú)緩存靜态資源。CDN服務商一般會在(zài)全國(guó)各地(dì / de)部署服務，而(ér)且帶寬很大(dà)，這(zhè)樣訪問CDN的(de)資源時(shí)就(jiù)可以(yǐ)有較短的(de)路由路徑，而(ér)且帶寬也(yě)比較大(dà)，訪問比較快。
解析渲染
加載完JS和(hé / huò)CSS之(zhī)後，浏覽器開始解析執行。Chrome的(de)渲染流程是(shì)這(zhè)樣的(de)：
爲(wéi / wèi)了(le／liǎo)讓浏覽器更快的(de)解析渲染，我們需要(yào / yāo)考慮這(zhè)幾點：
CSS 嵌套層級不(bù)要(yào / yāo)太深，不(bù)超過3級，避免在(zài)最内層使用通配選擇器。
JS 腳本不(bù)要(yào / yāo)太複雜，考慮輕量化架構，降低 JS 複雜性，減少解析時(shí)間，盡量不(bù)要(yào / yāo)引用複雜的(de)第三方腳本。
按需加載模塊，按需打包，首頁僅僅加載和(hé / huò)執行和(hé / huò)首屏相關的(de)腳本。其他(tā)腳本延遲加載執行。
考慮依賴的(de)第三方模塊是(shì)不(bù)是(shì)必須，需不(bù)需要(yào / yāo)精簡。
打包優化，code split 和(hé / huò) tree shaken。常用webpack和(hé / huò)rollup的(de)優化。
用戶交互相關事件綁定（比如頁面scroll，用戶左右滑動等），添加參數{passive:true}，減少浏覽器事件等待。因爲(wéi / wèi)這(zhè)些事件屬于(yú)可阻止事件，浏覽器不(bù)知道(dào)用戶會不(bù)會阻止，所以(yǐ)需要(yào / yāo)等待js執行，然後再做響應。添加passive參數，就(jiù)告訴浏覽器不(bù)用等待了(le／liǎo)。
iOS8 以(yǐ)後的(de) iOS 支持wkwebview，但是(shì)很多 App 之(zhī)前用的(de)還是(shì) uiwebview，建議轉換成wkwebview，獲得性能的(de)提升（UIwebview在(zài)執行 JS 時(shí)會阻塞 UI渲染進程，WKwebview不(bù)會）。
數據埋點
上(shàng)面我們梳理了(le／liǎo)加載到(dào)解析渲染過程應該做的(de)事情，那麽如果你這(zhè)些都做好了(le／liǎo)，發現網頁表現依然不(bù)盡人(rén)意，那麽你就(jiù)要(yào / yāo)考慮做一下數據埋點。其實數據埋點在(zài)企業項目中也(yě)是(shì)必不(bù)可少的(de)，和(hé / huò)性能體驗優化構成閉環。通過數據來(lái)發現頁面性能和(hé / huò)體驗的(de)問題，更有針對的(de)進行解決。
事實上(shàng)數據埋點分爲(wéi / wèi)三類：
業務埋點，統計諸如 PV、UV、點擊率、流失率、轉化率等
大(dà)數據埋點，統計與用戶行爲(wéi / wèi)相關信息，比如那個(gè)用戶點擊了(le／liǎo)那個(gè)商品，上(shàng)報用戶 ID 和(hé / huò)商品 ID，方便後台分析用戶和(hé / huò)商品的(de)關系，可以(yǐ)用做大(dà)數據分析，推薦算法來(lái)爲(wéi / wèi)用戶推薦商品。
工程埋點，統計工程上(shàng)的(de)數據信息，比如頁面秒開率，DNS 時(shí)間等。
當然，實際的(de)操作上(shàng)不(bù)止這(zhè)些，還有一些關于(yú)資源緩存的(de)五種方案選擇與緩存優化的(de)五種方案。
