前端感官性能的衡量和優化實踐

咱們爲何須要關注站點的性能，性能爲何如此重要呢？現在任何互聯網產品首先重要的都是流量，流量最終會轉換爲商業價值。因此在互聯網產品中，流量、轉化率和留存率基本上是產品經理或者業務很是關注的幾個因素，而性能則會直接影響到用戶的轉化和留存（在必定階段以後影響較大，產品初期功能的因素佔比更大）。因此換言之性能，實際上是錢，咱們關注和監測性能並不是是爲了數據而數據。產品的使用體驗我認爲包含三大要素：產品功能、交互視覺、前端性能，而咱們作性能優化的最終目的是提高前端性能，從而提高產品體驗。

傳統性能優化

值得慶幸的是，前端的性能優化有諸多有跡可循的理論和方法，好比 Yahoo！性能軍規（Best Practices for Speeding Up Your Web Site）、Google PageSpeed Insights Rules（developers.google.com/speed/docs/… Browser Processing Model 的不一樣階段。

圖 1 瀏覽器的加載和處理過程

根據圖 1 的 Processing Model，咱們能夠統計獲得如下性能指標：

redirect: timing.fetchStart - timing.navigationStart
dns: timing.domainLookupEnd - timing.domainLookupStart
connect: timing.connectEnd - timing.connectStart
network: timing.connectEnd - timing.navigationStart
load: timing.loadEventEnd - timing.navigationStart
domReady: timing.domContentLoadedEventStart - timing.navigationStart
interactive: timing.domInteractive - timing.navigationStart
ttf: timing.fetchStart - timing.navigationStart
ttr: timing.requestStart - timing.navigationStart
ttdns: timing.domainLookupStart - timing.navigationStart
ttconnect: timing.connectStart - timing.navigationStart
ttfb: timing.responseStart - timing.navigationStart
firstPaint: timing.msFirstPaint - timing.navigationStart

這些指標對於前端而言都司空見慣，基本上核心關注的無外乎是：首字節時間（用於衡量網絡鏈路和服務器響應性能）、白屏時間（firstPaint）、可交互時間（interactive）、徹底加載時間（load）。咱們在很長一段時間裏都是根據這些指標來量化分析咱們的站點性能，彷佛未曾認真想過這些指標是否可以真正的反映用戶的感官性能。

顯然，這些指標絕大部分都屬於非視覺指標（Non-Visual Metrics），是體驗優化的常規指標，更是體驗和性能優化中逃不開的關鍵因素，但卻並不是感官指標，也並不能徹底衡量出用戶的感官性能（Perceptual Performance）。

感官性能優化

所謂感官性能，即用戶直觀感知到的性能，用戶感覺是一種很是主觀的判斷，那麼如何衡量和統計感知性能？一般咱們針對用戶感知會經過用研分析的方式（眼動儀、用戶溝通、用戶反饋、調研問卷、專家評估）來評估和衡量。但感官性能不一樣於用戶感覺，是否有方式能夠量化和衡量呢？筆者通過一些調研和了解後，發現感官性能是能夠經過必定方式進行衡量、分析和對標的，由於對性能的感覺更多反映在視覺的變化上，所以咱們能夠經過一些視覺指標來衡量感官性能：

First Paint Time
First Contentful Paint Time
First Meaningful Paint Time
First Interactive Time
Consistently Interactive Time
Fisrt Visual Change
Last Visual Change
Speed Index
Perceptual Speed Index

First Paint 又稱之爲 First Non-Blank Paint，表示文檔中任一元素首次渲染的時間。First Contentful Paint 表明文檔中內容元素（文本、圖像、Canvas，或者 SVG）首次渲染的時間。它一般狀況下是無心義的渲染，好比頭部和導航條。First Meaningful Paint Time 表明首次有意義的渲染時間（它的統計在重大的佈局變化以後，每每表明了用戶所關心的首次渲染時間），First Interactive Time、Consistently Interactive Time 分別表示首次可交互時間和持續可交互時間。

如圖 2 的流程圖展現了 Blink 內核中 Time-to-first-X-paint 的分析原理和上報路徑（其餘 first-X-paint 的指標相似）。

圖 2 Blink 內核中 Time-to-first-X-paint 的分析原理和上報路徑

Fisrt Visual Change、Last Visual Change 分別表示首次和最後一次視覺發生變化的時間點，Speed Index、Perceptual Speed Index 均爲視覺速度，二者的區別在於背後所用到的算法不一樣，前者採用了 Mean Pixel-Histogram Difference 算法，後者則採用了 Structural Similarity Image Metric 算法，其中 Perceptual Speed Index 的統計結果更貼近用戶的真實感覺。Speed Index 的算法以下，它表明了咱們頁面在加載過程當中視覺上的變化速度，其值越小表明感官性能越好：

公式 1

經過 FCP（First Contentful Paint）、FMP（First Meaningful Paint）、PSI（Perceptual Speed Index），咱們能夠實現跨平臺的感官性能分析和對標（好比能夠實現 HTML5 和 Hybrid 對比，HTML5 和原生應用的對比等），如圖 3 所示爲咱們項目中某列表頁的 SI 和 PSI 柱狀圖。

圖 3 業務項目中某列表頁的 SI 和 PSI 柱狀圖示意

性能優化分析工具

說起性能優化分析工具，在開發階段咱們擁有衆多的選擇（好比 Chrome 自帶的 Dev Tools、老牌的 YSlow、以及 Google 推出的 PageSpeed Insights），這裏筆者強烈推薦的是 Lighthouse。Lighthouse 是一個開源的自動化工具，運行 Lighthouse 的方式有兩種：一種是做爲 Chrome 擴展程序運行；另外一種做爲命令行工具運行。 Chrome 擴展程序提供了一個對用戶更友好的界面，方便讀取報告。經過命令行工具能夠將 Lighthouse 集成到持續集成系統。

經過 Lighthouse 咱們能夠對頁面從 PWA、性能、可訪問性、最佳實踐幾個方面進行多維度的分析，並給出結果和建議，上文中提到的 FMP（First Meaningful Paint）、FI（First Interactive），CI（Consistently Interactive），PSI（Perceptual Speed Index）均可以從其中的性能報告中分析獲得。

因爲篇幅所限，對於 Lighthouse 的細節說明、原理及使用在此再也不贅述，基本上在開發階段經過 Chrome Dev Tools、Lighthouse 徹底能夠進行全面的性能體驗和分析，已經可以爲咱們的優化提供足夠多的指導建議。

感官性能的跨平臺對標

僅僅在開發階段擁有可用的分析檢測工具還遠遠不夠，一般狀況下，咱們更但願在產品上線後，和競對的產品進行感官性能的對標分析，而這裏每每會涉及到跨平臺（由於競對的產品實現多是經過 HTML5 實現，也多是諸如 Weex、React Native 的混合開發形式，固然還有很大一部分多是原生的實現）。

如何進行跨平臺的感官性能對標，在筆者看來很是重要，如今行業內你們廣泛採用的對標方式是視頻對比，經過兩個視頻的時間軸對比來講明感官性能的提高。我的認爲這種方式沒法作到量化和自動化，所以可能會出現不一樣的人對比得出的結果並不可以對齊，同時效率較低。

咱們須要作的僅僅是更進一步，將視頻對比的過程量化和自動化。所以筆者在充分調研了現有社區的一些實現後，和同事封裝了一個簡單易用的小工具（Twilight）用於感官性能的跨平臺對標。咱們須要作的僅僅是錄製視頻，而後點選關鍵幀，以後便可以自動的將 SI（Speed Index）、PSI（Perceptual Speed Index）、FVC（First Visual Change）、FCP（FirstContentful Paint）、FMP（First Meaningful Paint）、LVC（Last Visual Change）等指標可視化的呈現出來。

圖 4 使用 Twilight 分析工具獲取感官性能指標的流程

業務應用優化實踐

在業務項目上咱們也針對國際機票進行了一系列的摸索和實踐。國際機票在客戶端內以及純瀏覽器中均可能被訪問，採用了 Vue 2.0 做爲基礎框架，並經過純靜態化的方式開發並部署至 CDN。起初國際機票的頁面加載白屏明顯（首次內容渲染時間長），用戶體驗較差。所以咱們經過上述提到的一些工具進行了分析，發現網絡請求、應用啓動、接口請求是影響列表頁性能加載的三大因素。

針對上述問題，咱們採用瞭如下關鍵的優化策略：

純前端離線化（在瀏覽器中經過純前端的手段進行資源文件的離線化）；
客戶端離線化（在客戶端容器內經過離線包的方式實現資源文件及頁面的離線化）；
頁面組件化並按需加載（經過組件化方式對頁面細粒度拆分並按需加載）；
預渲染提高感官性能（在框架啓動以前，經過預渲染的方式確保頁面框架最快呈現）。

經過上述優化策略優化後，效果顯著，純前端離線化上線後可交互和徹底加載時間提高 50%，客戶端離線化上線後，首字節時間基本爲 0（下降 500 毫秒），可交互和徹底加載時間相較純前端離線化進一步提高 30%至 50%，按需加載和預渲染上線後頁面的 FMP（First Meaningful Paint）提高 80%。

如圖 5 所示爲列表頁在 Chrome 瀏覽器中模擬 4G 並將 CPU 模擬 4 倍降速（CPU Throttling 4x slowdown）的表現（不包含客戶端離線化的效果）。

圖 5 國際機票項目性能優化先後的加載效果對比

性能分析及優化小結

總結一下，前端的性能分析和優化方式，不管是傳統性能仍是感官性能徹底有跡可循。開發階段可使用 Dev Tools、Lighthouse，藉助非視覺指標（Non-Visual Metrics）和視覺指標（Visual Metrics）進行分析，遵循傳統性能優化軍規以及 Google PRPL Pattern 進行性能優化。經過咱們提供的工具 Twilight 能夠便捷的實現感官性能的跨平臺對標分析。雖然咱們在業務項目中的實踐取得了必定的效果，但優化之路漫漫，還有不少空間的可能性。歡迎對性能優化感興趣的同行一同交流，Do Better Web。

做者簡介

郭凱，美團點評酒旅前端高級技術專家、高級技術經理，目前負責美團點評酒旅事業羣境內度假終端研發團隊，致力於終端技術體系的完善和基礎設施的建設，培養人才精進團隊，服務業務創造科技價值，譯做有《編寫可維護的 JavaScript》、《第三方 JavaScript 編程》等。

• 本文轉自美團點評技術學院，未經做者許可，不容許私自轉載！
• 加入美團雲技術交流羣（QQ羣：469243579），每日分享更多精彩技術文章。