前端性能的幾個基礎指標

時間 2019-11-10

標籤前端性能幾個基礎指標欄目系統性能简体版

原文原文鏈接

2018.3.1更：

有贊·微商城(base杭州)部門招前端啦，最近的前端hc有十多個，跪求大佬扔簡歷，我直接進行內推實時反饋進度，有興趣的郵件 lvdada#youzan.com，或直接微信勾搭我 wsldd225 瞭解跟多javascript

有贊開源組件庫·zanUIcss

前端性能的幾個基礎指標

先開門見山的羅列前端性能相關的幾個基礎指標名詞。html

白屏時間
首屏時間
用戶可操做時間
頁面總下載時間

爲什麼會選擇這幾個時間節點以及各自的含義能夠參考這篇文章七天打造前端性能監控系統
另外本文蒐集性能相關數據是用了高級瀏覽器的Performance Api,你們能夠參考這篇文章先行了解初探erformancep前端

正文

上圖看了有和感覺？當頁面刷新後可視區域長時間停留在白屏狀態，當一個階段後頁面忽然所有刷出，而不是咱們追崇的逐步加載顯示的狀態。java

上圖顯示的是視口上部分已經展現，可是因爲某種緣由頁面下部分的視圖被阻塞，一段時間後，剩餘頁面忽然刷出，也不符合頁面逐步顯示的體驗。jquery

上圖的現象是可交互的區域已經出如今視口中了，用戶也已經在可點擊的地方進行狂點，可是圖片資源沒有加載完可致使點擊事件沒有綁定，點擊無效。這種交互體驗也是不能容忍的。git

上面幾個例子正好能夠帶出兩個性能指標 `白屏時間` 和 `用戶可操做時間`

白屏時間：用戶從打開頁面開始到有頁面開始呈現爲止。
用戶可操做時間：用戶能夠進行正常的事件輸入交互操做。github

接下來咱們經過Performance Api看看如何獲得這兩個指標的數據。web

http://www.w3.org/TR/navigati...
上圖來自官方，從左到右表明了瀏覽器打開一個頁面內部的一系列狀態。左邊紅線表明的是網絡傳輸層面的過程，這篇文章不過多講述，右邊紅線表明了服務器傳輸回字節後瀏覽器的各類事件狀態，也就是上圖中的responseEnd以後。這個階段包含了瀏覽器對文檔的解析，dom樹構建，佈局，繪製等等。下面詳細說明。api

在瀏覽器console中輸入performance.timing，返回的各字節跟上圖performance流程的各狀態一一對應，並返回時間。

上圖簡單說明了一下performance timing api在幾個流程下所表明的含義。至於爲什麼到達domInteractive狀態時表明了Dom tree 構建完成我在下文還會解釋到。

上圖演示了一個頁面加載時Chrome的調試工具中的Network會顯示兩條豎線，一藍一紅，藍的表明document觸發了domContentLoaded事件，紅線表明了document觸發了load事件。

理一理

咱們說到了當document到達domInteractive狀態時表明了dom樹的構建完成，也表明了能夠綁定事件，即用戶可交互時間已經到達，也表明了觸發domContentLoaded事件，也即表明Chrome調試中藍線的出現。
但這一連串因果又是從何獲得的呢？

深剖why

上圖說明在瀏覽器拿到文檔首字節以後，即上文提到的responseEnd以後。瀏覽器將html解析並構建成DOM tree，並同時將css解析成CSSOM。在沒有js的參與下，這個過程是同步的。

但一旦有js的參與，這個平衡就被破壞了。

同步的javascript能夠改寫文檔在任何節點，所以DOMtree 一旦碰上script標籤（同步）就會中止構建。script也會阻塞img資源的下載。
javascript能查詢dom對象的可被計算的樣式，CSSOM構建完才能輪到js的執行（僅位於script以前的css文件（內嵌、外鏈）纔會阻塞js的執行，若樣式文件在script以後，則此樣式文件不會阻塞script）

這兩點的解釋說明能夠看這裏和這裏

因爲上面兩個緣由，致使html的解析構建與css構建成CSSOM有了依賴關係

而後咱們看一下官方文檔

        這裏解釋了document到達interactive狀態所表明的含義，我先將其中一塊信息隱藏。根據這個說明，當文檔解析完成可是，一些例如圖片這些資源尚未加載完成的狀況下，document到達interactive狀態，而且觸發DOMContentLoaded事件觸發。下面來看一個實例。

        結合上面的深剖，CSSOM構建阻塞了js的執行，因此在這幅圖中js早已加載完，仍是要等到css的下載完成才能執行，而js的被阻塞，又致使了html文檔的解析DOM樹的構建。再根據官方的說明，dom樹的構建完成才意味着interactive到達，意味着藍線的出現。
        但咱們再看下官方說明的原話。

        是的，剛剛被我遮蓋掉的是stylesheets樣式表。這裏又明確提到了不等stylesheets樣式表下載完成，一旦html解析dom樹構建完document就立馬到達interactive狀態。這不是跟咱們剛剛的例子相反了嗎？
再看個例子

        這個例子藍線停在了css文件下載完成以前，說明也驗證了後一種說法。那究竟是哪一個對？
        答案固然是都對，咱們在最以前就說明了，在沒有js參與的狀況下，html的解析DOM樹的構建和CSSOM的構建是平行的，誰也不礙着誰，interactive狀態的變動直接取決於html的解析完成度，因此在這種狀況下，不等css加載完，html一旦解析完成，document狀態立馬變動爲interactive。第二個例子是沒有js引入的。

深剖小結

上述的引入的js只是同步的。也就是不帶defer 或 async的script標籤。一旦引入了帶defer或async的script標籤，js、css的依賴關係又變了。這裏就不詳談了，能夠看一篇外文Deciphering the Critical Rendering Path
或者個人翻譯版本個人翻譯

總結

如今咱們再來看一下domContentLoaded和load事件。如今應該能清楚爲什麼domContentLoaded事件觸發表明了用戶可交互事件，以及

$(function () {

})

jquery中的這個寫法就是基於這個事件。

最後，咱們回頭看下開頭指出的衡量頁面性能的四個基礎指標，以及各自的求法。

白屏時間：除了可使用現成的performance api，咱們還能夠在head之間頭尾插入兩個script計算時間差

<head>
<script>
var t = new Date().getTime();
</script>
<link src="">
<link src="">
<link src="">

<script>
tNow = new Date().getTime() - t;
</script>
</head>

這樣作可行的原理：第一個script不受css阻塞，最後的script受css阻塞，會等到樣式都下載完才執行，執行完後即是body的解析，以後是dom tree構建，佈局，繪製而後呈如今屏幕上。