《响应式Web设计性能优化》一2.1 性能度量基础
本節書摘來異步社區《響應式Web設計性能優化》一書中的第2章，第2.1節，作者： 【美】Tom Barker 譯者： 余紹亮 , 丁一 , 葉磊 責編： 趙軒，更多章節內容可以訪問云棲社區“異步社區”公眾號查看。
2.1 性能度量基礎
如果你正在閱讀本書，很可能你已經熟知性能的含義，或是至少曾經圍繞你的Web應用做過一些性能相關的討論。但在繼續往下看之前，我們來確認下在術語方面我們的理解是一致的。
如若這是你首次聽到Web性能優化一詞，趕快去搞一本Steve Souders的High Performance Web Sites和Even Faster Web Sites（均由O’Reilly出版）讀一讀。這些都是Web性能的標準，也是所有Web開發者都應掌握的基礎知識。
本章并不打算覆蓋性能的每個細節。從前面提到的Steve Souders的著作開始，已經有大量的資料在講這些東西。但是，本章的目標是對性能（Web性能和Web運行時性能）做個概述，包括一些性能度量的工具。這樣一來，后面章節我們說到這些概念時，就不會再有歧義和混淆了。
當提及網站和Web應用性能的時候，我們說的要么是Web性能，要么是運行時性能。我們將Web性能定義為，一個終端用戶從請求一段內容開始到這段內容顯示在用戶設備上這段時間的度量值。我們將運行時性能定義為，應用在運行時對用戶輸入響應能力的一個標示。
應當意識到，針對你的Web應用性能進行量化和標準的制定，是應用的一個關鍵方面。Web性能和運行時性能都有一些指標可以進行實證測度和量化。本章中，我們來看一看這些指標，以及可以用來量化這些指標的工具。
注意
性能指標是組織機構用來定義一次嘗試是成功或是失敗的可量化目標。通常稱作關鍵性能指標，縮寫為KPI。
本章我們將談到的性能指標類型如下所示。
定量指標
可以通過實驗進行度量的一種目標（如某個東西的數量）。
定性指標
不能通過實驗度量的一種目標（如某個東西的質量）。
先行指標
用于預測結果。
輸入指標
用于度量某個過程中消耗的資源。
什么是Web性能？
想想每次瀏覽網頁的過程。打開瀏覽器，鍵入URL，然后等待網頁加載。從鍵入URL后按下回車鍵（或是從書簽列表中點擊某個書簽，亦或是點擊頁面中的某個鏈接），到頁面渲染，這之間消耗的時間就是所瀏覽頁面的Web性能。若站點運行正常，這個時間甚至不應該被人感受到。
Web性能的定量指標數不勝數。
- 頁面加載時間。
- 頁面文件大小。
- HTTP請求數。
- 頁面渲染時間。
- Web性能的定性指標總結起來比較簡單：速度感。
在看這些指標之前，先來討論下頁面是如何到達瀏覽器并展現給用戶的。當通過瀏覽器請求一個Web頁面，瀏覽器會創建一個線程去處理這個請求，隨后開始遠程dns查找，遠程dns服務器會將你輸入的URL對應的IP地址返回給瀏覽器。
接著，瀏覽器通過與遠程Web服務端的三次握手來建立一個TCP/IP連接。這個握手由瀏覽器與遠程服務端之間的SYN、SYN-ACK以及ACK消息組成。
TCP連接建立之后，瀏覽器通過連接發送一個HTTP GET請求到Web服務端。Web服務端找到請求的資源，然后在HTTP響應中將其返回，狀態200表示響應正常。如果服務端找不到請求的資源或是解析資源的過程中出錯，抑或是資源被重定向，HTTP響應狀態也會反映出這些情況。這個頁面可以找到狀態碼的完整列表：http://bit.ly/stat-codes。下面是最常用的狀態碼。
- 200表示服務端成功響應。
- 301表示永久重定向。
- 302表示臨時重定向。
- 403表示請求被拒絕。
- 404表示服務端找不到請求的資源。
- 500表示處理請求時出錯。
- 503表示服務不可用。
- 504表示網關超時。
圖2-1是TCP事務的時序圖。
圖2-1 瀏覽器和Web服務器的協商過程
要時刻記得，加載一個HTML頁面不只需要一次這個過程，瀏覽器還要為頁面鏈接的每個資源發起一個HTTP請求——所有的圖片、鏈接的CSS和JavaScript文件以及其他類型的外部資源（但是要注意，只要后續的HTTP請求連接的是相同的源，瀏覽器就可以重用相應的TCP連接）。
當瀏覽器收到頁面的HTML后，就開始解析并渲染頁面內容。
瀏覽器用其渲染引擎來解析和渲染內容。現代的瀏覽器架構由幾個關聯的模塊組成。
UI層
這一層為瀏覽器繪制界面。有些元素，如地址欄、刷新按鈕以及用戶界面上（UI）的其他元素是瀏覽器自身的。
網絡層
該層處理網絡連接，承擔的職責有建立TCP連接以及處理HTTP的往返過程。網絡層處理內容下載，然后將內容傳遞給渲染引擎。
B
渲染引擎負責將內容繪制到顯示器上。瀏覽器制造商會將他們的渲染引擎以及JavaScript引擎打上商標并對外授權。所以，相對流行的渲染引擎你可能已經聽說過了。可以說，最流行的渲染引擎是WebKit，Chrome（Blink是它的譯名）、Safari、Opera以及其他一些瀏覽器中都用到了WebKit。當渲染引擎遇到了JavaScript，會將其傳遞給JavaScript解釋器。
JavaScript引擎
JavaScript引擎會解析并執行JavaScript。如同渲染引擎，瀏覽器制造商給他們的JavaScript打上商標進行授權，很可能你已經聽說過它們了。一個流行的JavaScript引擎是Google的V8，Chrome、Chromium中都用到了它，Node.js就是用它作為引擎的。
圖2-2展示了這樣的架構。
圖2-2 分成多個模塊組件的現代瀏覽器架構
設想這樣一個用例，用戶在瀏覽器地址欄里鍵入一個URL。UI層將這個請求傳遞到網絡層，網絡層隨后建立連接，然后下載初始頁面。當含有HTML塊的數據包到達，就被傳遞給渲染引擎。渲染引擎將HTML組裝成原始文本，然后對文本中的字符開始進行詞法分析——或解析。這些字符會與一個規則集相比較——我們在HTML文檔中指定的文檔類型定義（DTD）——然后轉換成基于規則集的符號。DTD規定了一系列標簽，這些標簽組成了我們將要使用的語言版本。這些標簽就是由一些被分隔成有意義片段的字符組成。
這里有個網絡層是如何處理并返回下列字符串的例子。
<!DOCTYPE html><html><head><meta charset="UTF-8"/>這串字符會被分割成下面這樣有意義的塊。
<!DOCTYPE html> <html> <head> <meta charset="UTF-8"/>渲染引擎拿到這些符號后將它們轉換成文檔對象模型（DOM）元素（DOM是頁面元素的內存表現形式，也是JavaScript用于訪問頁面元素的API）。DOM元素被布局成一棵渲染樹，渲染引擎會迭代該樹。首次迭代中，渲染引擎會布局好DOM元素的位置；下一次迭代就將這些元素繪制到屏幕上。
如果渲染層在解析和符號化過程中發現了script標簽，就會暫停下來然后評估下接下來要進行的處理。如果script標簽指向一個外部JavaScript文件，解析過程暫停，隨后網絡層介入，下載JavaScript文件，然后初始化JavaScript引擎解析，執行該文件。如果script標簽包含的是內嵌的JavaScript，渲染引擎暫停，JavaScript引擎被初始化，內嵌的JavaScript會被解析與執行。執行完成后，之前暫停的渲染過程會恢復運行。
這是一個很重要的細微差別，影響的不僅僅是DOM元素何時對JavaScript可見（我們的代碼可能會嘗試訪問頁面上的一個元素，但該元素可能還沒有被解析和符號化，更不用提渲染了）和性能。例如，我們是想要阻塞頁面的解析直到下載并運行了那一段代碼嗎，或是如果我們先展示內容再去加載頁面的代碼，頁面的功能能否正常？
圖2-3描繪了這種工作流程。
圖2-3 瀏覽器中內容加載和渲染的工作流程
了解網頁內容是怎樣傳遞給瀏覽器對于理解Web性能影響因素是至關重要的。也要注意到，由于瀏覽器的快速更新，瀏覽器廠商可能會時常對這個工作流進行調整和優化。
既然我們已經了解了內容傳遞和展現的架構，那來看一看在這個傳遞工作流上下文中的性能指標。
HTTP請求數
時刻記住，當瀏覽器獲取HTML頁面時會創建一個HTTP請求，還會創建更多的HTTP請求來獲取頁面中鏈接的每個資源。根據網絡延遲情況，每個HTTP請求都會使總的頁面加載時間增加20～200毫秒（如果考慮可以并行加載資源的瀏覽器，這個數字會有所不同）。如果只是少量的資源，這些額外的加載時間可以忽略不計，但如果是100個或更多的HTTP請求，將會顯著加大總體Web性能的延遲。
減少頁面需要的HTTP請求數才有意義。開發者有很多辦法可以做到，如將不同的CSS或JavaScript文件合并成單個文件，將常用的圖片合并成單個的稱之為sprite的圖片文件。
頁面負載
影響Web性能的因素之一是頁面的總文件大小。總負載包括組成該頁面的HTML、CSS以及JavaScript累計的文件大小。還包括所有的圖片、cookie以及其他嵌在頁面中的媒體。
頁面加載時間
HTTP請求數以及總的頁面負載本身只是輸入，但Web性能方面需要關注的真正KPI是頁面加載時間。
頁面加載時間是最明顯的性能指標，也是最容易量化的。簡而言之，它是瀏覽器下載并渲染所有頁面內容的時間。以前，度量的是從頁面請求到頁面（窗口加載，window onload）事件之間消耗的時間。最近，由于開發者越來越喜歡在頁面完成加載之前就提供好的用戶體驗，這樣度量結束的時間點就會移動，甚至完全改變。
特別是，在有一些用例中，window.onload事件觸發之后，可以動態加載內容——比如，如果內容是延遲加載的，就會出現這種情況——并且有一些用例，在window.onload事件觸發之前頁面就是可用的，看起來也是完整的（如先加載內容，然后再加載廣告）。這些用例會降低依靠window.onload事件追蹤特定頁面加載時間的有效性。
有一些選擇可以規避這個難題。WebPageTest的創建和維護者Pat Meenan，在WebPageTest中加入了一種度量方式，稱為速度指標（Speed Index），其實質上是對頁面內容渲染快慢計分。有一些開發團隊創建了自己自定義的事件，來追蹤他們覺得用戶體驗關鍵頁面的各個部分是何時加載的。
無論你選擇何種方式進行追蹤，頁面的加載（即，你的內容已經準備好接受用戶交互）都是應當監控的關鍵性能指標。
超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生總結
以上是生活随笔為你收集整理的《响应式Web设计性能优化》一2.1 性能度量基础的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 《无人机DIY》——4.2 项目1：Ma
- 下一篇： 《响应式web设计》读书笔记（三）拥抱流