本節書摘來異步社群《響應式web設計性能優化》一書中的第2章，第2.1節，作者： 【美】tom barker 譯者： 餘紹亮 , 丁一 , 葉磊 責編： 趙軒，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
如果你正在閱讀本書，很可能你已經熟知性能的含義，或是至少曾經圍繞你的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後按下Enter鍵（或是從書簽清單中點選某個書簽，亦或是點選頁面中的某個連結），到頁面渲染，這之間消耗的時間就是所浏覽頁面的web性能。若站點運作正常，這個時間甚至不應該被人感受到。
web性能的定量名額數不勝數。
頁面加載時間。
頁面檔案大小。
http請求數。
頁面渲染時間。
web性能的定性名額總結起來比較簡單：速度感。
在看這些名額之前，先來讨論下頁面是如何到達浏覽器并展現給使用者的。當通過浏覽器請求一個web頁面，浏覽器會建立一個線程去處理這個請求，随後開始遠端dns查找，遠端dns伺服器會将你輸入的url對應的ip位址傳回給浏覽器。
接着，浏覽器通過與遠端web服務端的三次握手來建立一個tcp/ip連接配接。這個握手由浏覽器與遠端服務端之間的syn、syn-ack以及ack消息組成。
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規定了一系列标簽，這些标簽組成了我們将要使用的語言版本。這些标簽就是由一些被分隔成有意義片段的字元組成。
這裡有個網絡層是如何處理并傳回下列字元串的例子。
這串字元會被分割成下面這樣有意義的塊。
渲染引擎拿到這些符号後将它們轉換成文檔對象模型（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），其實質上是對頁面内容渲染快慢計分。有一些開發團隊建立了自己自定義的事件，來追蹤他們覺得使用者體驗關鍵頁面的各個部分是何時加載的。
無論你選擇何種方式進行追蹤，頁面的加載（即，你的内容已經準備好接受使用者互動）都是應當監控的關鍵性能名額。