前端性能

時間 2019-11-16

標籤前端性能欄目系統性能简体版

原文原文鏈接

1.關鍵點

　　分頁面、區域、瀏覽器、性能指標php

　　頁面的性能指標詳解：css

　　白屏時間（first Paint Time）——用戶從打開頁面開始到頁面開始有東西呈現爲止html

　　首屏時間——用戶瀏覽器首屏內全部內容都呈現出來所花費的時間前端

　　用戶可操做時間(dom Interactive)——用戶能夠進行正常的點擊、輸入等操做，默承認以統計domready時間，由於一般會在這時候綁定事件操做html5

　　總下載時間——頁面全部資源都加載完成並呈現出來所花的時間，即頁面 onload 的時間java

　　肯定統計起點：jquery

　　咱們須要在用戶輸入 URL 或者點擊連接的時候就開始統計，由於這樣才能衡量用戶的等待時間。高端瀏覽器Navigation Timing接口；普通瀏覽器經過 cookie 記錄時間戳的方式來統計，須要注意的是 Cookie 方式只能統計到站內跳轉的數據。git

2.如何統計性能指標的時間

2.1白屏時間

　　公式：github

　　白屏時間=開始渲染時間(首字節時間+HTML下載完成時間)+頭部資源加載時間web

　　如何獲取：

　　chrome 高版本：

　　window.chrome.loadTimes().firstPaintTime loadTimes獲取的結果

{
  connectionInfo: "http/1",
  finishDocumentLoadTime: 1422412260.278667,
  finishLoadTime: 1422412261.083637,
  firstPaintAfterLoadTime: 1422412261.094726,
  firstPaintTime: 1422412258.085214,
  navigationType: "Reload",
  npnNegotiatedProtocol: "unknown",
  requestTime: 0,
  startLoadTime: 1422412256.920803,
  wasAlternateProtocolAvailable: false,
  wasFetchedViaSpdy: false,
  wasNpnNegotiated: false
}

　　因此計算公式：

(chrome.loadTimes().firstPaintTime - chrome.loadTimes().startLoadTime)*1000

　　其餘瀏覽器：

　　大部分瀏覽器沒有特定函數，必須想其餘辦法來監測。仔細觀察 WebPagetest 視圖分析發現，白屏時間出如今頭部外鏈資源加載完附近，由於瀏覽器只有加載並解析完頭部資源纔會真正渲染頁面。基於此咱們能夠經過獲取頭部資源加載完的時刻來近似統計白屏時間。儘管並不精確，但卻考慮了影響白屏的主要因素：首字節時間和頭部資源加載時間（HTML下載完成時間很是微小）。

　　有一個點:mod_36ad799.js等幾個js爲何會在hm.js以前下載？html代碼以下

　　這貌似與咱們熟知的腳本阻塞解析不符啊，理應是腳本插入hm.js在先，致使DOM樹改變，從新繪製DOM樹，而後繼續往下解析……緣由是如今的瀏覽器對這個過程作了優化：

處理腳本及樣式表的順序（The order of processing scripts and style sheets）

　　腳本

　　web的模式是同步的，開發者但願解析到一個script標籤時當即解析執行腳本，並阻塞文檔的解析直到腳本執行完。若是腳本是外引的，則網絡必須先請求到這個資源——這個過程也是同步的，會阻塞文檔的解析直到資源被請求到。這個模式保持了不少年，而且在html4及html5中都特別指定了。開發者能夠將腳本標識爲defer，以使其不阻塞文檔解析，並在文檔解析結束後執行。Html5增長了標記腳本爲異步的選項，以使腳本的解析執行使用另外一個線程。

　　預解析（Speculative parsing）

　　Webkit和Firefox都作了這個優化，當執行腳本時，另外一個線程解析剩下的文檔，並加載後面須要經過網絡加載的資源。這種方式可使資源並行加載從而使總體速度更快。須要注意的是，預解析並不改變Dom樹，它將這個工做留給主解析過程，本身只解析外部資源的引用，好比外部腳本、樣式表及圖片。

　　樣式表（Style sheets）

　　樣式表採用另外一種不一樣的模式。理論上，既然樣式表不改變Dom樹，也就沒有必要停下文檔的解析等待它們，然而，存在一個問題，腳本可能在文檔的解析過程當中請求樣式信息，若是樣式尚未加載和解析，腳本將獲得錯誤的值，顯然這將會致使不少問題，這看起來是個邊緣狀況，但確實很常見。Firefox在存在樣式表還在加載和解析時阻塞全部的腳本，而Chrome只在當腳本試圖訪問某些可能被未加載的樣式表所影響的特定的樣式屬性時才阻塞這些腳本。

　　因此就獲得了上面的那個結果

　　看看IE的處理

　　迴歸正題，普通瀏覽器須要獲取兩個時間：開始渲染時間和頭部資源加載時間：

　　開始渲染時間：

　　須要藉助瀏覽器的navigator timing屬性performance；window.performance.timing（Navigation timing性能時間線）相關屬性：

// 在同一個瀏覽器上下文中，前一個網頁（與當前頁面不必定同域）unload 的時間戳，若是無前一個網頁 unload ，則與 fetchStart 值相等
navigationStart: 1441112691935,
 
// 前一個網頁（與當前頁面同域）unload 的時間戳，若是無前一個網頁 unload 或者前一個網頁與當前頁面不一樣域，則值爲 0
unloadEventStart: 0,
unloadEventEnd: 0,
 
// 第一個 HTTP 重定向發生時的時間。有跳轉且是同域名內的重定向纔算，不然值爲 0 
redirectStart: 0,
redirectEnd: 0,
 ...
 // 開始解析渲染 DOM 樹的時間，此時 Document.readyState 變爲 loading，並將拋出 readystatechange 相關事件
domLoading: 1441112692690,
 ...

var timing = performance.timing;

var loadingTime = timing .domLoading - timing.navigationStart;//開始渲染時間

　　看一下navigator timing瀏覽器支持狀況

　　對於IE等低版本瀏覽器是不行的。

　　IE8 等低版本瀏覽器經過 cookie 記錄時間戳的方式來統計，須要注意的是 Cookie 方式只能統計到站內跳轉的數據。首次進入沒有好的統計方法。

　　頭部資源加載時間：

<!DOCTYPE HTML>
<html>
    <head>
        <meta charset="UTF-8"/>
    <script>
      var start_time = +new Date; //測試時間起點，實際統計起點爲 DNS 查詢
    </script>
    <!-- 3s 後這個 js 纔會返回 -->
    <script src="script.php"></script>  
    <script>
      var end_time = +new Date; //時間終點
      var headtime = end_time - start_time; //頭部資源加載時間    
      console.log(headtime);
    </script>
    </head> 
    <body>     
    <p>在頭部資源加載完以前頁面將是白屏</p>
    <p>script.php 被模擬設置 3s 後返回，head 底部內嵌 JS 等待前面 js 返回後才執行</p>
    <p>script.php 替換成一個執行長時間循環的 js 效果也同樣</p>  
    </body>
</html>

　　這個比較簡單，在head的前面計時開始，在head最末尾計時結束，中間的差值就計算爲頭部資源加載時間。

　　因此，最終計算方法:

var firstPaintTime = end_time - performance.timing.navigationStart

2.2首屏時間

　　首屏時間的統計比較複雜，由於涉及圖片等多種元素及異步渲染等方式。觀察加載視圖可發現，影響首屏的主要因素的圖片的加載。經過統計首屏內圖片的加載時間即可以獲取首屏渲染完成的時間。統計流程以下：

　　首屏位置調用 API 開始統計 -> 綁定首屏內全部圖片的 load 事件 -> 頁面加載完後判斷圖片是否在首屏內，找出加載最慢的一張 -> 首屏時間

　　這是同步加載狀況下的簡單統計邏輯，另外須要注意的幾點：

頁面存在 iframe 的狀況下也須要判斷加載時間
gif 圖片在 IE 上可能重複觸發 load 事件需排除
異步渲染的狀況下應在異步獲取數據插入以後再計算首屏
css 重要背景圖片能夠經過 JS 請求圖片 url 來統計(瀏覽器不會重複加載)
沒有圖片則以統計 JS 執行時間爲首屏，即認爲文字出現時間

//IE gif重複onload解決
var img=new Image(); 
img.load=function(){ 
//do something 
img.load=null;//從新賦值爲null 
} 
img.src='××.gif';

　　統計方法1:

　　原理：在首屏渲染以前埋上處理邏輯，使用定時器不斷的去檢測img節點的圖片。判斷圖片是否在首屏和加載完成，找到首屏中加載時間最慢的的圖片完成的時間，從而計算出首屏時間。若是首屏有沒有圖片，若是沒圖片就用domready時間。

　　缺點： 1.瀏覽器定時器最大精度爲55ms 2.背景圖片加載沒有計算在內 3.不斷檢測並執行的腳本耗時

View Code

　　統計方法2：

　　原理：對於網頁高度小於屏幕的網站來講，只要在頁面底部加上腳本打印當前時間便可；或者對於網頁高度大於一屏的網頁來講，只要在估算接近於一屏幕的元素的位置後，打印一下當前時間。固然這個時間要得把首屏中全部圖片的加載時間也算上。

　　缺點： 1.須要每一個頁面手動加入到對應位置 2.背景圖片加載沒有計算在內

View Code

2.3統計用戶可操做

　　用戶可操做爲全部DOM都解析完畢的時間，默承認以統計domready時間，由於一般會在這時候綁定事件操做。對於使用了模塊化異步加載的 JS 能夠在代碼中去主動標記重要 JS 的加載時間，這也是產品指標的統計方式。

　　使用jquery中的$(document).ready()便是此意義 window.performance.timing.domInteractive window.performance.timing.domContentLoadedEventStart

　　計算公式：

performance.timing.domInteractive - performance.timing.navigationStart

2.4總下載時間

　　默承認以統計onload時間，這樣能夠統計同步加載的資源所有加載完的耗時。若是頁面中存在不少異步渲染，能夠將異步渲染所有完成的時間做爲總下載時間。

　　計算公式：

performance.timing.loadEventStart- performance.timing.navigationStart

2.5統計api相關

片斷摘自：美團性能分析框架和性能監控平臺，並加入部分其餘文字

對於統計腳本，須要知足兩個條件：

避免對業務代碼的入侵；（獨立的腳本）
不影響被測量的頁面的性能；（主文檔加載完畢以後，再注入統計腳本收集數據，而且儘量的合併數據請求，減小帶寬消耗。）

肯定了數據統計腳本的約束條件以後，咱們從哪裏獲得這些數據呢？目前使用的主要途徑有：

主文檔加載速度，利用 Navigation Timing API 取得；

靜態資源加載速度，利用 Resource Timing API 取得；

首次渲染速度，IE 下用 msFirstPaint(window.performance.timing.msFirstPaint) 取得，Chrome 下利用 loadTimes(window.chrome.loadTimes()) 取得，咱們的 Chrome 瀏覽器用戶佔比超過 70%；
文檔生成速度，則是在後端應用內打點來得到；

對於主文檔加載速度，咱們從宏觀到微觀的作了這樣的分解，從上到下的時間流，右邊的時刻標記了每一個指標從哪裏開始計算到哪裏截止，好比，跳轉時間 redirect 由 redirectEnd - redirectStart 計算獲得，其餘的類推：

採集主文檔加載速度的具體作法是：

在主文檔 load 以前提供可緩存數據的接口，方便在統計腳本載入前就能夠準備數據；
在主文檔 load 以後注入數據收集腳本，該腳本加載完成以後會處理全部的數據；
利用 Navigation Timing API 收集計算獲得上圖中的指標；
給全部數據打上頁面、地理位置、瀏覽器等標籤，方便更細維度的分析；

對於靜態資源的加載速度，咱們也作了相似的分解和採集(使用resource timing API)：

須要特別提示的是，若是你使用 CDN 的話，須要讓 CDN 服務商加上 Timing-Allow-Origin 的響應頭，才能拿到靜態資源的數據。

而對於主文檔生成速度，咱們則開發了性能統計的 Library，在框架級別集成後端性能的時間指標。

High Resolution Timing（高精度計時）

該API規範所定義的JavaScript接口可以提供精確到微秒級的當前時間，而且不會受到系統時鐘誤差或調整的影響。對於性能分析來講，精確的測量結果意義重大。

var perf = performance.now();
// console output 439985.4570000316

Page Visibility （頁面可見性）

經過這一規範，網站開發者可以以編程方式肯定頁面的當前可見狀態，從而使網站可以更有效地利用電源與CPU。

當頁面得到或失去焦點時，文檔對象的visibilitychange事件便會被觸發。

document.addEventListener('visibilitychange', function(event){if(document.hidden){// Page currently hidden.}else{// Page currently visible.}});

這一事件對於瞭解頁面的可見狀態十分有用，舉例來講，用戶可能會同時打開多個瀏覽器標籤，而你但願只在用戶顯示你的網站頁面時才進行某些操做（好比播放一段音頻文件、或是執行一段JavaScript動畫），就能夠經過這一事件進行觸發。對於移動設備來講，若是用戶在某個標籤中打開了你的網站，但正在另外一個標籤中瀏覽其它內容時，這一特性可以節省該設備的電池消耗。（雖然對於你的網站性能來講意義不大……）

其它部分API功能簡介

Resource Timing（資源計時）——對單個資源（如圖片）的計時，能夠對細粒度的用戶體驗進行檢測。
Performance Timeline（性能時間線）——以一個統一的接口獲取由Navigation Timing、Resourcing Timing和User Timing所收集的性能數據。
Battery Status（電池狀態）——可以檢測當前設備的電池狀態，例如是否正在充電、電量等級等等。能夠根據當前電量決定是否顯示某些內容（例如視頻、動畫等等），對於移動設備來講很是實用。
User Timing（用戶計時）——能夠對某段代碼、函數進行自定義計時，以瞭解這段代碼的具體運行時間，相似於stop watch的做用。
Beacon（燈塔）——能夠將分析結果或診斷代碼發送給服務器，它採用了異步執行的方式，所以不會影響頁面中其它代碼的運行。對於收集測試結果並進行統計分析來講是一種十分便利的工具。
Animation Timing（動畫計時） - 經過requestAnimationFrame函數讓瀏覽器精通地控制動畫的幀數，可以有效地配合顯示器的刷新率，提供更平滑的動畫效果，減小對CPU和電池的消耗。
Resource Hits（資源提示） - 經過html屬性指定資源的預加載，例如在瀏覽相冊時可以預先加載下一張圖片，加快翻頁的顯示速度。
Frame Timing（幀計時）——經過一個接口獲取與幀相關的性能數據，例如每秒幀數和TTF。該標準目前還沒有被支持。
Navigation Error Logging（導航錯誤日誌記錄）——經過一個接口存儲及獲取與某個文檔的導航相關的錯誤記錄。該標準目前還沒有被支持。

瀏覽器支持

下表列舉了當前主流瀏覽器對性能API的支持，其中標註星號的內容並不是來自於Web性能工做小組。

規範	Internet Explorer	Firefox	Chrome	Safari	Opera	iOS Safari	Android
Navigation Timing	9	31	所有	8	26	8 (不包括 8.1)	4.1
High Resolution Timing	10	31	所有	8	26	8 (不包括 8.1)	4.4
Page Visibility	10	31	所有	7	26	7.1	4.4
Resource Timing	10	34	所有	-	26	-	4.4
Battery Status*	-	31 （部分支持）	38	-	26	-	-
User Timing	10	-	所有	-	26	-	4.4
Beacon	-	31	39	-	26	-	-
Animation Timing	10	31	所有	6.1	26	7.1	4.4
Resource Hints	-	-	僅限Canary版	-	-	-	-
Frame Timing	-	-	-	-	-	-	-
Navigation Error Logging	-	-	-	-	-	-	-
WebP*	-	-	所有	-	26	-	4.1
Picture element and srcset attribute *	-	-	38	-	26	-	-

其它

DZone.com在《Performance & Monitoring 2015》這份白皮書中專門介紹了性能API以及W3C所推薦的新協議、標準及HTML元素，並提供了簡單的示例。能夠在這裏下載完整的白皮書（須要註冊）。本文中的示例代碼即來自於該白皮書。

若是想了解有關Web性能API的更多內容，能夠參考W3C官方文檔或這篇博客。

2.6 性能優化分爲兩個階段來作

　　1.使用測試工具自測和優化（工具如ySlow/,線上工具www.webpagetest.org、阿里測、gtmetrix）

　　ySlow/ShowSlow：http://www.showslow.com/ 【前端性能監控系統，前端性能指標數據展現，沒法實現自動化監控用戶真實的應用場景，針對移動端的性能監控，目前因爲其自己依賴的工具絕大多數只有PC端，在移動端缺少相應的數據上報工具（特別是移動端自己複雜的網絡環境），因此若是想使用ShowSlow做爲前端性能監控平臺，須要單獨實現數據收集系統，而只是將ShowSlow看成展現系統使用,開源】

　　Page Speed: 【基於一系列優化規則對網站進行檢測，相似的有Yslow（推薦使用https://gtmetrix.com/來檢測網站性能和規則，使用不一樣的工具檢測對比）】　　

　　阿里測：基於WebPageTest，網頁前端性能測試工具;　　

　　PhantomJS：自動化監測，模擬Phantom JS 是一個服務器端的 JavaScript API 的 WebKit，基於它能夠輕鬆實現 web 自動化測試。相似的有berserkJS。可是都是服務器模擬測試，不能監控用戶真實環境。

　　webpagetest線上版

　　基於WebPagetest的阿里測（已下線，不舉例了，上17測:http://www.17ce.com/）

　　綜合了pagespeed和ySlow的GTmetrix

　　2.啓用線上監控用戶真實狀況（前端性能監控平臺）

　　看幾個例子

　　透視寶：http://www.toushibao.com/brower.html 【前端性能上報，圖表展現，監控用戶真實的應用場景，付費】　　

　　提供了每個請求的詳細信息

　　能夠按選擇的字段排序，經過過濾進行相似數據對比，能夠查看每個請求的詳細信息，不過按url搜索貌似沒有用,若是這個有用的話那就能夠對同一個頁面作時間的對比。

　　優勢：