從前端角度淺談性能 | 京東物流技術(shù)團隊

1 前言

自網(wǎng)站誕生以來，頁面白屏?xí)r間、用戶交互的響應(yīng)速度等一直都是開發(fā)者關(guān)心的問題，這直接影響了一個網(wǎng)站能否為用戶的瀏覽提供舒適的服務(wù)，而這種舒適度，直接關(guān)系著對用戶的吸引力，畢竟誰都不能忍受一個頁面長達10秒的空白屏?xí)r間，更別說點擊按鈕后，頁面長時間的毫無反應(yīng)。

web 的性能一定程度上影響了用戶留存率，Google DoubleClick 研究表明：如果一個移動端頁面加載時長超過 3 秒，用戶就會放棄瀏覽。BBC 發(fā)現(xiàn)網(wǎng)頁加載時長每增 1 秒，用戶就會流失 10%。在2006年，Amazon曾做過一個報道，響應(yīng)時間每提高100ms，他們便會增加1%的收入。從中可以看出，頁面性能的重要性，但是到底多快才是快呢。

Google 開發(fā)者提出了一種RAIL模型來衡量應(yīng)用性能，這是一種以用戶為中心的性能模型，它提供了一種考慮性能的結(jié)構(gòu)。該模型將用戶體驗分解為關(guān)鍵操作（例如，點擊、滾動、加載），并幫助您為每個操作定義性能目標。

2 RAIL模型

RAIL代表著 web 應(yīng)用生命周期的四個不同方面，即：Response(響應(yīng))、Animation(動畫)、Idle(空閑)、Load(加載)。

最好的性能指標是：100ms 內(nèi)響應(yīng)用戶輸入；動畫或者滾動需在 10ms 內(nèi)生成每一幀；最大化空閑時間；頁面加載時長不超過 5秒。

不同的用戶對RAIL中的每一個都有不同的性能期望，因此性能指標是根據(jù)上下文和關(guān)于用戶如何感知延遲的用戶體驗研究來定義的。

2.1 用戶感知性能延遲的關(guān)鍵指標

用戶對性能延遲的感知有所不同，具體取決于網(wǎng)絡(luò)條件和硬件。例如，通過快速 Wi-Fi 連接，在功能強大的臺式機上加載站點時，通常只需不到 1 秒時間，用戶已經(jīng)習(xí)以為常。通過速度較慢的 3G 網(wǎng)絡(luò)連接，在移動設(shè)備上加載站點則需要更長的時間，因此，移動用戶通常會更有耐心。在移動設(shè)備上，5 秒鐘內(nèi)完成加載是更現(xiàn)實的目標。

以上，我們了解了用戶是如何感知性能延遲的，下面介紹關(guān)于RAIL模型中的關(guān)鍵性能指標。

2.2 Response：100毫秒內(nèi)響應(yīng)用戶交互

• 為了確保在100毫秒內(nèi)產(chǎn)生可見響應(yīng)，需要在 50 毫秒內(nèi)處理完成用戶的交互事件，例如單擊按鈕、切換表單控件或啟動動畫。
• 在部分情況下，即時響應(yīng)用戶的交互行為并不一定是正確的做法。可以使用這100 毫秒的時間來執(zhí)行其他需要消耗大量時間的工作，但要注意不要妨礙用戶。如果可能，應(yīng)在后臺工作。
• 對于需要超過50毫秒才能完成的操作，需要為用戶隨時提供反饋。

2.3 Animation：在10毫秒內(nèi)生成一幀

• 在 10 毫秒或更短的時間內(nèi)生成動畫中的每一幀。從技術(shù)上講，每幀的最大預(yù)算是 16 毫秒（1000 毫秒/每秒 60 幀≈16 毫秒），但是，瀏覽器需要大約 6 毫秒來渲染每幀，因此準則為每幀 10 毫秒。
• 以視覺平滑為目標。用戶會注意到幀速率何時發(fā)生變化。

2.4 Idle：最大限度利用空閑時間

• 利用空閑時間完成延緩的工作。例如，對于初始頁面的加載，應(yīng)加載盡可能少的數(shù)據(jù)，然后利用空閑時間加載其余數(shù)據(jù)。
• 在空閑時間被利用期間，如果用戶與頁面交互，則應(yīng)中斷對空閑時間的利用，用戶交互始終具有最高優(yōu)先性。

2.5 Load：在5秒內(nèi)交互內(nèi)容并實現(xiàn)可交互

當頁面加載緩慢時，用戶注意力會分散，他們會認為任務(wù)已中斷。加載速度快的網(wǎng)站具有更長的平均會話時間、更低的跳出率和更高的廣告可見性。

根據(jù)用戶的設(shè)備和網(wǎng)絡(luò)能力優(yōu)化相關(guān)的快速加載性能。目前，對于首次加載，在使用速度較慢 3G 連接的移動設(shè)備上，理想的目標是在 5 秒或更短的時間內(nèi)實現(xiàn)可交互。
對于后續(xù)加載，理想的目標是在 2 秒內(nèi)加載頁面。

以上，提供了一種以用戶為中心的性能模型，詳細的將用戶體驗分解到了按鍵操作（例如點擊、滾動、加載）中，為每個操作自定義性能目標。

接下來，我們看一下關(guān)于每一個web頁面的核心指標。

3 核心web指標

2020年Google 定義的核心Web指標閾值，旨在為網(wǎng)絡(luò)質(zhì)量指標提供統(tǒng)一指導(dǎo)，這些指標對于提供出色的網(wǎng)絡(luò)用戶體驗至關(guān)重要。

3.1 三大核心指標

• LCP（Largest Contentful Paint，最大內(nèi)容繪制，測量加載性能）：根據(jù)頁面首次開始加載的時間點，報告可視區(qū)域內(nèi)可見的最大圖像或文本塊完成渲染的相對時間。
• FID（First Input Delay，首次輸入延遲，測量交互性）：測量從用戶第一次與頁面交互（例如當他們單擊鏈接、點按按鈕或使用由 JavaScript 驅(qū)動的自定義控件）到瀏覽器對交互作出響應(yīng)，并實際能夠開始處理事件處理程序所經(jīng)過的時間。
• CLS（ Cumulative Layout Shift，累積布局偏移，測量視覺穩(wěn)定性）：測量整個頁面生命周期內(nèi)發(fā)生的所有意外布局偏移中最大一連串的布局偏移分數(shù)。每當一個可見元素的位置從一個已渲染幀變更到下一個已渲染幀時，就發(fā)生了布局偏移。計算方式為：布局偏移分數(shù) = 影響分數(shù) * 距離分數(shù)

3.2 其他指標

• FCP（First Contentful Paint，首次內(nèi)容繪制）：首次內(nèi)容繪制 (FCP) 指標測量頁面從開始加載到頁面內(nèi)容的任何部分在屏幕上完成渲染的時間。對于該指標，”內(nèi)容”指的是文本、圖像（包括背景圖像）、

以上，我們完成了對用戶性能體驗指標、web性能核心指標的介紹，那么你是否想再稍微深入的了解一下一個web頁面從輸入網(wǎng)址到可交互的過程呢。

4 web加載全過程

從輸入url到用戶可以使用頁面的全過程時間統(tǒng)計，會返回一個PerformanceTiming對象，單位均為毫秒

按觸發(fā)順序排列所有屬性：

• navigationStart:在同一個瀏覽器上下文中，前一個網(wǎng)頁（與當前頁面不一定同域）unload 的時間戳，如果無前一個網(wǎng)頁 unload ，則與 fetchStart 值相等
• redirectStart:第一個 HTTP 重定向發(fā)生時的時間。有跳轉(zhuǎn)且是同域名內(nèi)的重定向才算，否則值為 0
• unloadEventStart:前一個網(wǎng)頁（與當前頁面同域）unload 的時間戳，如果無前一個網(wǎng)頁 unload 或者前一個網(wǎng)頁與當前頁面不同域，則值為 0
• redirectEnd:最后一個 HTTP 重定向完成時的時間。有跳轉(zhuǎn)且是同域名內(nèi)的重定向才算，否則值為 0
• unloadEventEnd:和 unloadEventStart 相對應(yīng)，返回前一個網(wǎng)頁 unload 事件綁定的回調(diào)函數(shù)執(zhí)行完畢的時間戳

注意：開始頁面請求

• fetchStart:瀏覽器準備好使用 HTTP 請求抓取文檔的時間，這發(fā)生在檢查本地緩存之前
• domainLookupStart:DNS 域名查詢開始的時間，如果使用了本地緩存（即無 DNS 查詢）或持久連接，則與 fetchStart 值相等
• domainLookupEnd:DNS 域名查詢完成的時間，如果使用了本地緩存（即無 DNS 查詢）或持久連接，則與 fetchStart 值相等
• connectStart:HTTP（TCP） 開始建立連接的時間，如果是持久連接，則與 fetchStart 值相等,如果在傳輸層發(fā)生了錯誤且重新建立連接，則這里顯示的是新建立的連接開始的時間
• secureConnectionStart:HTTPS 連接開始的時間，如果不是安全連接，則值為 0
• connectEnd:HTTP（TCP） 完成建立連接的時間（完成握手），如果是持久連接，則與 fetchStart 值相等,如果在傳輸層發(fā)生了錯誤且重新建立連接，則這里顯示的是新建立的連接完成的時間

注意：這里握手結(jié)束，包括安全連接建立完成、SOCKS 授權(quán)通過

• requestStart:HTTP 請求讀取真實文檔開始的時間（完成建立連接），包括從本地讀取緩存,連接錯誤重連時，這里顯示的也是新建立連接的時間
• responseStart:HTTP 開始接收響應(yīng)的時間（獲取到第一個字節(jié)），包括從本地讀取緩存
• responseEnd:HTTP 響應(yīng)全部接收完成的時間（獲取到最后一個字節(jié)），包括從本地讀取緩存
• domLoading:開始解析渲染 DOM 樹的時間，此時 Document.readyState 變?yōu)?loading，并將拋出 readystatechange 相關(guān)事件
• domInteractive:完成解析 DOM 樹的時間，Document.readyState 變?yōu)?interactive，并將拋出 readystatechange 相關(guān)事件

注意：只是 DOM 樹解析完成，這時候并沒有開始加載網(wǎng)頁內(nèi)的資源

• domContentLoadedEventStart:DOM 解析完成后，網(wǎng)頁內(nèi)資源加載開始的時間,文檔發(fā)生 DOMContentLoaded事件的時間
• domContentLoadedEventEnd:DOM 解析完成后，網(wǎng)頁內(nèi)資源加載完成的時間（如 JS 腳本加載執(zhí)行完畢），文檔的DOMContentLoaded 事件的結(jié)束時間
• domComplete:DOM 樹解析完成，且資源也準備就緒的時間，Document.readyState 變?yōu)?complete，并將拋出 readystatechange 相關(guān)事件
• loadEventStart:load 事件發(fā)送給文檔，也即 load 回調(diào)函數(shù)開始執(zhí)行的時間,如果沒有綁定 load 事件，值為 0
• loadEventEnd:load 事件的回調(diào)函數(shù)執(zhí)行完畢的時間,如果沒有綁定 load 事件，值為 0

5 各指標計算方式

6 總結(jié)

在優(yōu)化網(wǎng)站性能時，我們發(fā)現(xiàn)這些標準有時會相互沖突。例如，一個閾值始終可實現(xiàn)和該閾值始終能提供良好的用戶體驗之間可能存在矛盾。此外，鑒于人類感知研究通常提供一個范圍值，而用戶行為指標又顯示了行為的逐漸變化，我們發(fā)現(xiàn)通常沒有唯一”正確”的指標閾值。因此，我們在優(yōu)化網(wǎng)站的性能時可以參考上訴范圍閾值，同時認識到?jīng)]有一個完美的閾值，畢竟“盡信書不如無書”，并且我們有時可能需要從多個合理的候選閾值中進行選擇。我們不是要弄清”完美的閾值是多少”，相反地，我們應(yīng)該要專注于認清”哪一個候選閾值最符合我們的網(wǎng)站”。

7 后續(xù)

本文從前端角度，講述了用戶性能體驗的幾種核心指標，并總結(jié)了相應(yīng)的標準。同時從輸入網(wǎng)址到頁面完全加載完畢，系統(tǒng)的介紹了一個web頁面的加載全流程。但是這只是作為一個開發(fā)者，評估一個頁面性能所需要的基礎(chǔ)理論知識，后續(xù)將努力為大家提供一些實際工作中的實踐應(yīng)用，如性能檢測的應(yīng)用方案，如lighthouse等工具的實際使用；web頁面性能優(yōu)化要知道的二三事。

作者：京東物流 李菲菲

來源：京東云開發(fā)者社區(qū) 自猿其說 Tech 轉(zhuǎn)載請注明來源