來源：https://m.sohu.com/a/201865334_509523/

關于頁面相應時間，有一條著名的“2-5-8原則”。當用戶訪問一個頁面：

• 在2秒內得到響應時，會感覺系統響應很快；
• 在2-5秒之間得到響應時，會感覺系統的響應速度還可以；
• 在5-8秒以內得到響應時，會感覺系統的響應速度很慢，但可以接受；
• 而超過8秒后仍然無法得到響應時，用戶會感覺系統糟透了，進而選擇離開這個站點，或者發起第二次請求。

對于一個網站如果希望抓住用戶，網站的速度以及穩定性是非常重要的。

從各式各樣的前端監控平臺中，你都可以獲得頁面很多的性能指標。本文將介紹幾個幾個比較關鍵的指標，并給出相應的優化思路。

開始渲染時間

該時間點表示瀏覽器開始繪制頁面，在此之前頁面都是白屏，所以也稱為白屏時間。

該時間點可用公式：
Time To Start Render = TTFB(Time To First Byte) + TTDD(Time To Document Download) + TTHE(Time To Head End)

• TTFB：表示瀏覽器發起請求到服務器返回第一個字節的時間；
• TTDD：表示從服務器加載HTML文檔的時間；
• TTHE：表示文檔頭部解析完成所需要的時間。

在高級瀏覽器中有對應的屬性可以獲取該時間點。Chrome可通過chrome.loadTimes().firstPaintTime獲取，IE9+可以通過performance.timing.msFirstPaint獲取，在不支持的瀏覽器中可以根據上面公式通過獲取頭部資源加載完的時刻模擬獲取近似值。開始渲染時間越快，用戶就能更快的看見頁面。

對于該時間點的優化有：

優化服務器響應時間，服務器端盡早輸出

減少html文件大小

減少頭部資源,腳本盡量放在body中

DOM Ready

該時間點表示dom解析已經完成，資源還沒有加載完成, 這個時候用戶與頁面的交互已經可用了。用公式TimeTo Dom Ready = TTSR(Time To Start Render) + TTDC(Time To Dom Created) + TTST(Time To )可以表示。TTSR上面已經介紹過了，TTDC表示DOM樹創建所耗時間。TTST表示BODY中所有靜態腳本加載和執行的時間。在高級瀏覽器中有DOMContentLoaded事件對應。

詳細規范可以查看W3C的HTML5規范。從MDN文檔上可以看出該事件主要是指dom文檔加載解析完成，看上去很簡單，但是DOMContentLoaded事件的觸發與css,js息息相關，現在有專門的名詞Critical Rendering Path(關鍵呈現路徑)來描述。

在不支持DOMContentLoaded事件的瀏覽器中可以通過模擬獲取近似值，主要的模擬方法有：

低版本webkit內核瀏覽器可以通過輪詢document.readyState來實現；

ie中可通過setTimeout不斷調用documentElement的doScroll方法，直到其可用來實現；

具體實現方法可以參考主流框架(jquery等)的實現。 DOM Ready時間點意味著用戶與頁面可以進行交互了，因此越早越好，對于該時間點的優化有：

減少dom結構的復雜度，節點盡可能少，嵌套不要太深；

優化關鍵呈現路徑；

首屏時間

該時間點表示用戶看到第一屏頁面的時間，這個時間點很重要但是很難獲取，一般都只能通過模擬獲取一個近似時間。一般模擬方法有：

不斷獲取屏幕截圖，當截圖不再變化時，可以視為首屏時間。可參考webPagetest的Speed Index算法；

一般影響首屏的主要因素是圖片的加載，通過頁面加載完后判斷圖片是否在首屏內，找出加載最慢的一張即可視為首屏時間。

針對該時間點的優化有：

頁面首屏的顯示盡量不要依賴于js代碼，js盡量放到domReady后執行或加載；

首屏外的圖片延遲加載；

首屏結構盡量簡單，首屏外的css可延遲加載；

該時間點是window.事件觸發的時間，表示原始文檔和所有引用的內容已經加載完成，用戶最明顯的感覺就是瀏覽器tab上loading狀態結束。

該時間點的優化方式有：

減少資源的請求數和文件大小；

將非初始化腳本放到之后執行；

無需同步的腳本異步加載

為了優化整站性能，頁面的時候可以考慮做一些預加載，把其它頁面需要用到的資源預先加載進來。

總結

以上是生活随笔為你收集整理的网站的几个性能指标和优化（简易）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。