高性能極致用戶體驗前端開發實戰

時間 2019-11-29

標籤高性能極致用戶體驗前端開發實戰简体版

原文原文鏈接

課程介紹

高性能極致用戶體驗前端開發實戰課程適合全部前端開發學習或者從業者，結合目前前端開發的最佳實踐，提供前端網頁性能分析優化知識，結合實際項目經驗分析能夠採用的優化思路，並給出開發高性能極致體驗網頁的通用方法和技巧。課程官方博客：前端學堂 javascript

在開始學習本課程以前，先提2個基本要求：php

瞭解業務

做爲一名合格的前端開發，咱們的開發工做不是盲目的，咱們的優化目標須要明確，因此首先要了解你所作的業務。不只要知道整個業務背景，還須要瞭解業務需求，業務目的，最後最好能拿到業務結果。html

瞭解業務的目的是能讓你更好的分配開發的權重，合理安排開發的重點。好比開發的是視頻類網站，那麼開發的重點天然在於播放器加載和流暢播放以及降級方案。若是是天氣類業務，那麼核心業務是要保障穩定快速的展現出天氣相關數據，而後是加載展現其餘內容。若是是博文類網站，那麼重點在於首屏的信息加載和展現。前端

瞭解用戶

瞭解用戶也是相當重要，若是連本身所作業務的受衆都不知道，那麼何談用戶體驗，何談極致性能？這一部分至少你要知道如今作的業務主要是面向PC用戶仍是移動web用戶，PC用戶所用的瀏覽器都是什麼版本，比例分佈是怎樣？移動端用戶android和ios比例多少，各自平臺版本分佈狀況如何？這是最基本的要求，由於咱們開發的代碼是在這些平臺運行的。若是不知道怎麼辦？不要緊，從今天開始統計起來，作個埋點日誌服務，前端寫個腳本上報下useragent就能夠了。vue

navigator.userAgent
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36"

課程大綱

評判標準
- RAIL評估模型
- 性能指標
- 體驗指標
- 指標數據採集
優化實戰
- 鏈路優化
- 編程優化
鏈路優化
- 鏈路階段分析
- 階段指標數據
- 各階段優化手段
- 案例分析和經常使用工具
編程優化
- 首屏渲染
- 懶加載功能組件
- 滾動加載分頁組件
- web worker計算
- Task切分
- 代碼分割與打包
- 前端開發架構優化

前端開發架構優化
- ES6 module+template
- web component
- 輕react或vue
- 微前端架構

課程官方博客：前端學堂 html5

視頻教程：雲課堂視頻課程java

評判標準

無規矩不成方圓，因此這裏先說說評判標準。評判標準主要指的是用戶打開網頁、瀏覽網頁的體驗和感覺。咱們須要一種客觀的評估模型來統一量化用戶體驗的各個環節，這樣才能找到須要優化的方向，找到開發極致用戶體驗網頁的捷徑。react

RAIL評估模型

RAIL 是一種以用戶爲中心的性能模型。每一個網絡應用均具備與其生命週期有關的四個不一樣方面，且這些方面以不一樣的方式影響着性能。以用戶爲中心；最終目標不只是讓您的網站在任何特定設備上都能運行很快，而是使用戶滿意。android

Response，當即響應用戶；在 100 毫秒之內確認用戶輸入，超過100ms建議加上動效或者loading，經過視覺衝擊減小用戶等待的焦慮。
Animation，設置動畫或滾動時，在 10 毫秒之內生成幀。
Idle，最大程度增長主線程的空閒時間。主線程空閒才能隨時均可以及時響應。
Load，持續吸引用戶；在 1000 毫秒之內呈現交互內容。

讓用戶成爲您的性能工做的中心。用戶花在網站上的大多數時間不是等待加載，而是在使用時等待響應。瞭解用戶如何評價性能延遲：webpack

延遲與用戶反應
0 – 16 毫秒	流暢；人們特別擅長跟蹤運動，若是動畫不流暢，他們就會對運動心生反感。用戶能夠感知每秒渲染 60 幀的平滑動畫轉場。也就是每幀 16 毫秒（包括瀏覽器將新幀繪製到屏幕上所需的時間），留給應用大約 10 毫秒的時間來生成一幀。
0 – 100 毫秒	快，在此時間窗口內響應用戶操做，他們會以爲能夠當即得到結果。時間再長，操做與反應之間的鏈接就會中斷。
100 – 300 毫秒	可感受慢，須要loading，用戶會遇到輕微可覺察的延遲。
300 – 1000 毫秒	慢，須要作loading和佔位。在此窗口內，延遲感受像是任務天然和持續發展的一部分。對於網絡上的大多數用戶，加載頁面或更改視圖表明着一個任務。
1000+ 毫秒	很慢，超過 1 秒，用戶的注意力將離開他們正在執行的任務。
10,000+ 毫秒	放棄，用戶感到失望，可能會放棄任務；以後他們或許不會再回來。

響應：在 100 毫秒之內響應

在用戶注意到滯後以前您有 100 毫秒的時間能夠響應用戶輸入。這適用於大多數輸入，無論他們是在點擊按鈕、切換表單控件仍是啓動動畫。但不適用於觸摸拖動或滾動。若是您未響應，操做與反應之間的鏈接就會中斷。用戶會注意到。儘管很明顯應當即響應用戶的操做，但這並不老是正確的作法。使用此 100 毫秒窗口執行其餘開銷大的工做，但須要謹慎，以避免妨礙用戶。若是可能，請在後臺執行工做。對於須要超過 500 毫秒才能完成的操做，請始終提供反饋機制，好比loading，進度條等。

動畫：在 10 毫秒內生成一幀

動畫不僅是奇特的 UI 效果。例如，滾動和觸摸拖動就是動畫類型。若是動畫幀率發生變化，您的用戶確實會注意到。您的目標就是每秒生成 60 幀，每一幀必須完成如下全部步驟：

從純粹的數學角度而言，每幀的預算約爲 16 毫秒（1000 毫秒 / 60 幀 = 16.66 毫秒/幀）。但由於瀏覽器須要花費時間將新幀繪製到屏幕上，只有 10 毫秒來執行代碼。在像動畫同樣的高壓點中，關鍵是不論能不能作，什麼都不要作，作最少的工做。若是可能，請利用 100 毫秒響應預先計算開銷大的工做，這樣您就能夠儘量增長實現 60fps 的可能性。如需瞭解詳細信息，請參閱渲染性能。

空閒：最大程度增長空閒時間

利用空閒時間完成推遲的工做。例如，儘量減小預加載數據，以便您的應用快速加載，並利用空閒時間加載剩餘數據。推遲的工做應分紅每一個耗時約 50 毫秒的多個塊。若是用戶開始交互，優先級最高的事項是響應用戶。

要實現小於 100 毫秒的響應，應用必須在每 50 毫秒內將控制權返回給主線程，這樣應用就能夠執行其像素管道、對用戶輸入做出反應，等等。以 50 毫秒塊工做既能夠完成任務，又能確保及時的響應。

加載：在 1000 毫秒之內呈現內容

在 1 秒鐘內加載您的網站。不然，用戶的注意力會分散，他們處理任務的感受會中斷。側重於優化關鍵渲染路徑以取消阻止渲染。實際操做中，咱們無需在 1 秒內加載全部內容以產生完整加載的感受，而是啓用漸進式渲染和在後臺執行一些工做，默認只加載和渲染首屏內容，將非首屏、非必需的加載推遲到空閒時間段處理。

關鍵 RAIL 指標彙總

要根據 RAIL 指標評估您的網站，請使用 Chrome DevTools Timeline 工具記錄用戶操做。而後根據這些關鍵 RAIL 指標檢查 Timeline 中的記錄時間。

RAIL 步驟	關鍵指標	用戶操做
響應	輸入延遲時間（從點按到繪製）小於 100 毫秒。	用戶點按按鈕（例如打開導航）。
動畫	每一個幀的工做（從 JS 到繪製）完成時間小於 16 毫秒。	用戶滾動頁面，拖動手指（例如，打開菜單）或看到動畫。拖動時，應用的響應與手指位置有關（例如，拉動刷新、滑動輪播）。此指標僅適用於拖動的持續階段，不適用於開始階段。
空閒	主線程 JS 工做分紅不大於 50 毫秒的塊。	用戶沒有與頁面交互，但主線程應足夠用於處理下一個用戶輸入。
加載	頁面能夠在 1000 毫秒內就緒。	用戶加載頁面並看到關鍵路徑內容。

這是Google工程師提出來的RAIL優化模型，在實際前端業務監控中，咱們能夠拆分紅更多的數據指標進行統計分析。

性能和體驗數據指標

數據驅動業務開發，咱們的目標是高性能和極致用戶體驗，那麼咱們首先須要制定符合咱們目標的性能數據指標和體驗數據指標。在制定數據指標以前，咱們分析下頁面加載過程，咱們分爲這四個部分：

用戶體驗	描述
它在發生嗎？happening	網頁瀏覽順利開始了嗎？服務端有響應嗎？
它是否有用？useful	用戶是否能看到足夠的內容？
它是否可用？usable	用戶是否能夠和頁面交互，仍是頁面仍在忙於加載？
它是否使人愉快的？idle	交互是否流程和天然，沒有卡段或閃爍？

性能指標：加載呈現又快又穩。加載到展示的性能指標和穩定性指標。

體驗指標：操做反應靈敏。點擊，滑動等交互響應及時，操做流暢，動畫運行流暢。

加載性能指標：

秒開率：頁面首屏加載時間小於1s的比例，也就是頁面加載到onload事件觸發時所消耗的時間。
FP（first paint）和 FCP（first content paint）分別是指頁面首次繪製和首次內容繪製。FP（首次繪製）包括了任何用戶自定義的背景繪製，它是首先將像素繪製到屏幕的時刻。FCP（首次內容繪製）是瀏覽器將第一個 DOM 渲染到屏幕的時間。該指標報告了瀏覽器首次呈現任何文本、圖像、畫布或者 SVG 的時間。這兩個指標其實指示了咱們一般所說的白屏時間。
FMP(first meaningful paint)首次有意義繪製, 是頁面可用性的度量標準。由於很難有一個通用標準來指示全部的頁面當前時刻的渲染達是否到了有用的程度，因此當前並無制定標準。對於開發者，咱們能夠根據本身的頁面來肯定那一部分是最重要的，而後度量這部分渲染出的時間做爲FMP。
TTFB(time to first byte, 首字節時間)，是指從瀏覽器發起第一個請求到數據返回第一個字節所消耗的時間，這個時間包含了網絡時間，後端處理時間等等，能夠做爲一個鏈路數據綜合參考指標。

穩定性指標

資源錯誤：靜態資源加載錯誤，常見的就是404，資源地址不正確或者遠程服務有問題。
JS報錯：頁面運行時拋出來的異常信息。好比變量未定義，函數報錯等等。
Crash：頁面白屏不展現內容，極可能是頁面某個模塊報錯致使整個頁面不展現。
內存堆棧：監控頁面內存和堆棧使用狀況，常見如頁面內存泄露等緣由會直接致使APP閃退。
接口報錯：接口掛了，請求超時。或者接口返回了錯誤信息。或者接口返回數據錯誤，好比空數據，不符合預期。

操做體驗指標：

交互延遲：用戶點擊後頁面沒有響應或者響應時間超過100ms，用戶感受此次點擊操做是延遲的（可稱爲無效點擊）。經過EventTiming API咱們能夠統計用戶交互操做後的瀏覽器響應時間。
卡頓：統計瀏覽器中執行時間超過 50 ms 的任務，都是 long task（Long tasks API ），可能會形成頁面卡頓。
滾動流暢性：滾動過程是否流暢，監測用戶開始操做到頁面開始滾動的時間差，按照前面的標準，小於100ms纔會體驗流暢。
動畫流暢性：監測動畫開始到動畫結束，計算幀率FPS。按照前面的標準，每幀計算時間小於10ms纔會體驗流暢。
TTI（time to interactive, 可交互時間)：指頁面已渲染出內容，同時能夠響應用戶的輸入的時間。
FID（First Input Delay），首次輸入延遲，從用戶看到頁面到第一次輸入的延遲，通常都是由於主線程阻塞，會致使響應慢。這個指標反映用戶對當前頁面的第一感受，若是用戶好久沒有交互，說明首屏內容比較吸引人，或者用戶很快就切走了，說明對用戶沒有吸引力。

性能指標數據採集

介紹上面咱們總結的性能和體驗指標如何準確有效的採集。

優化實戰

咱們已經全面分析總結了評估頁面性能和用戶體驗的各個指標參數。那麼怎麼來優化呢？open signal官方提供了2018年2月份統計的全世界4G網絡覆蓋率和通訊速率的統計分佈圖以下，在目前移動互聯網的浪潮下，咱們要利用好用戶終端設備的每一個字節的流量。

固然頁面性能和體驗優化並非一蹴而就的，須要不斷的研究、跟蹤，發現問題，解決問題。可是咱們能夠在一開始編寫業務代碼的時候就作的更好，作到極致。因此，關於優化實戰咱們主要分爲兩部分：加載渲染鏈路優化 和 編程代碼優化。

加載渲染鏈路優化

從訪問url到頁面呈現，整個加載和渲染鏈路能夠作優化的思路。

加載鏈路：瀏覽器導航開始->檢查緩存->DNS->HTTP->解析

渲染鏈路：瀏覽器內核或者webview（對於ios區分wkwebview和早期版本的uiwebview）渲染流程

具體詳情參看下面這篇文章：

前端網頁加載渲染鏈路優化

編程代碼優化

咱們說的「快」，並不只僅指瀏覽器器加載頁面快，就是常說的秒開率，通常指DomContentLoad時間。可是「快」其實包含更多的含義，除了前面說的瀏覽器加載快，還包含瀏覽器解析快（Javascript腳本發佈時一般都會作代碼壓縮混淆，不只是減小體積，也爲了安全性），JS腳本編譯快（咱們知道javascript在瀏覽器的javascript虛擬機【managed runtime environment for JavaScript，JavaScript託管運行時環境】中運行的，因此也須要編輯JS腳本成字節碼，才能運行），最後一個就是javascript執行快。

鏈路優化中，咱們已經解決了JavaScript下載加速的問題，那麼剩下的優化工做主要集中在優化瀏覽器解析、編譯並執行JS腳本。影響瀏覽器解析和執行JS腳本的因素主要是JS腳本的體積大小和代碼的複雜程度。因此編程代碼優化實踐主要是減小代碼的體積和按需下降代碼複雜度，實現瀏覽器解析快，JS腳本編譯快。