U4 核心首屏性能的定義及統計名額前言首屏性能定義UC的首屏性能評估體系UC首屏性能統計名額 API 擴充性能優化的方向

Web 開發者為了了解或則統計自己站點的性能，可以通過浏覽器标準接口 Navigation Timing API 來擷取一些頁面性能上的相關耗時資料，如 requestStart，domComplete 等。但是僅僅這些資料還無法準确反映頁面的真實性能，特别是移動Web所注重的首屏性能。于是就有了一些通過 domComplete 時間，頁面加載完成時間等作為參考的性能體系，這些參考體系并不完全準确，并非使用者角度真正意義上的首屏。

首先說一下什麼是首屏性能：

移動 Web 頁面受網速和終端手機性能影響，使用者通常會比較關注頁面内容完全顯示出來的時間，過長的時間會極大考驗使用者的耐心，這個時間的長短是影響使用者體驗的關鍵因素之一，很大程度上決定着使用者的去與留。

一個頁面的加載性能怎麼樣，就是看從開始加載到首屏内容顯示出來需要經需要多長時間，是以就有了首屏性能這個名額來衡量頁面的加載性能。

UC 在手機浏覽器領域耕耘多年，她是怎麼來衡量頁面加載性能的呢，又有哪些名額體系，今天就來為大家解讀一下。

使用者從點選到首屏渲染完成主要路徑如下圖：

說明：

start：blink 核心開始建立請求的時間；

t0：blink 收到 http head 的時間；

t1：首屏有内容顯示的時間；

t2：首屏全部顯示出來的時間；

自然而然 UC 也是使用首屏性能來衡量各站點的性能情況，UC 對首屏性能的定義是從使用者使用的角度來定義的，即：首屏加載完成時間是以頁面首屏區域所要顯示的資源已經全部顯示出來的時間為準，該時間點也被定義為 t2 時間點。

當然使用者能直接感受到的性能名額除了 t2 還有 t1，UC 核心對 t1 的定義：頁面首次有内容顯示的時間。t1 在UC使用了多年，在以前弱網絡占比較高的時代，t1 在還是有其比較大的性能衡量價值，目前也還在繼續沿用。鑒于目前國内的網速提高很快，t1 衡量的權重已沒弱網絡時代那麼高了，衡量體系已經快速偏向 t2， UC内部的自有業務性能衡量目前都是在采用 t2 來衡量性能。

t2 即首屏是否渲染完成的判斷是一個相當複雜的工作，是以到目前為止現有其他浏覽器都沒有真正首屏渲染完成的事件，包括 Chrome。在首屏性能相關的一些打點統計中，包括以前的 t1 和現在的 t2，UC 一直走在 Chrome 前面，當然目前 Chrome 也在這塊發力，Chrome 在較新版本核心開始支援 First Meaningful Paint，據他自己的描述大概準确率 75% 左右。

UC 核心的 t2 計算是采用自己創新的一套算法，從渲染層次去計算何時頁面首屏渲染完成，簡單來說就是根據頁面内容以及圖檔資源加載渲染的情況做出判斷給出一個合理且較準确的時間值，是以計算出來的值非常貼近使用者的實際感受，因為是在核心渲染層級代碼實作的統計，是以帶來的性能消耗也相對較小，在可控範圍内。

該統計方法通過抽取線上 1000 個 TOP 移動站點的頁面，再經過 UC 内部的 WPT 測試工具對比驗證，準确率和覆寫率可達 85% 以上。

目前，我們已在最新釋出的 Android UC 浏覽器 11.5.0.939 版本擴充了性能統計名額 API，在現有的 ucweb.window 對象下增加了 performance 對象來提供 t0、t1、t2 接口，新增加一個自定義事件 BacktracePaintReady，腳本通過注冊監聽該事件，當收到事件通知時則可擷取t0、t1、t2 的值，機關為 ms。

該自定義事件通知在切換頁面（前進、後退、重新整理、關閉頁）的時候觸發，擷取到的 t0、t1、t2 必須采用 navigator.sendBeacon 方法上傳。

調用方法示例代碼：

是以，前端性能問題首先是統計問題，隻有采取了恰當的統計方法，收集到準确的統計資料，我們才可以更加準确量化優化的效果。

Web 頁面性能優化絕不是浏覽器核心或業務頁端單方面的事情。通常情況下業務對核心的實作不了解，某些情況下為了實作某個功能點，需要靠猜，靠驗證，費時費力，且不一定能達到效果。而核心側通常情況下離業務比較遠，對頁端慣用的技術或則方法并不一定完全了解，其性能優化的思路更多的是從核心本身的角度去考慮，實際不一定貼合業務，展現不出價值，甚至都不知道還有什麼優化空間。

在弱網絡時代，性能優化的重要方向之一就是怎麼樣提高加載速度，更多的是依賴緩存，預連接配接，資源加載控制等手段來優化加載性能。而在快速網絡的時代，随着Web技術的發展，H5技術普及，頁面效果越來越炫，複雜度也越來越高，純粹的資源加載速度已經不是最大的痛點了，資源的加載時機，使用者的互動體驗又成了最大的痛點了，性能優化難度也越來越大，單獨任何一個技術端的優化都也很難優化出滿意的整體效果，這就凸顯從前端到後端再到浏覽器核心各端的技術資料拉通顯得越來越有必要了。