要徹底瞭解web效能優化的問題，得搞清楚瀏覽器的工作原理。

我們需要了解，你在瀏覽器位址列中輸入url到頁面展示的短短几秒中，瀏覽器究竟做了什麼，才能瞭解到為什麼我們口中所說的優化方案能夠起到優化作用。

瀏覽器的多程序架構（以下的例子都是以chrome為例）

chrome由多個程序組成，每個程序都有自己的核心職責，每個程序又包含多個執行緒，一個程序內的多個執行緒也會協同工作，配合完成程序的職責。

說了這麼多，還是來張圖更直白：

程序（process）和執行緒（thread）

 當我們啟動一個應用，計算機會建立一個程序，作業系統會為程序分配一部分記憶體，應用也會建立多個執行緒來輔助工作，這些執行緒可以共享這部分記憶體中的資料。如果應用被關閉，程序就會被終結，作業系統會釋放相應的記憶體。

一個程序還可以要求作業系統生成另外一個程序來執行不同的任務，系統會為新的程序分配獨立的記憶體，兩個程序之間可以使用IPC (Inter Process Communication)進行通訊。如果一個程序反應遲鈍，重啟該程序不會影響其他的程序。

這是chrome多程序：

有了這個基礎，我們知道一個瀏覽器，可以是單程序多執行緒，也可以是多程序應用了。

這裡我們來分析下chrome的多程序是怎麼工作的

chrome主要程序

Chrome有一個主程序（Browser Process）用來協調瀏覽器的其他的程序。

Browser Procee:

• 負責包括位址列，書籤欄，前進後退等部分工作
• 負責處理瀏覽器的一些不可見的底層操作，比如網路請求和檔案訪問

Renderer Process：

• 負責一個網頁內關於呈現的所有事情

Plugin Process：

• 負責控制一個網頁所用的外掛，如flash

GPU Process：

• 負責處理GPU相關的任務

 Utility Process：

• 負責工具相關的任務

 Chrome多程序的優缺點比較：

優點：

某一渲染程序出問題不會影響其他的程序

缺點：

由於不同程序不能共享記憶體，不同的程序常常需要包含相同的內用。

那麼從位址列輸入發生了什麼：

1. 處理輸入

　　UI Thread 判斷使用者輸入的是url還是query,開始顯示spinner在位址列

2.開始導航

　　當用戶點選回車鍵，UI Thread通知 Network Thread獲取頁面內容

　　Network Thread會查詢DNS，隨後為請求建立TLS連結

3.去讀響應

　　當請求返回時，network thread會一句Content-Type和MIME Typesniffing判斷響應內容的格式

　　如果響應的內容是HTML，則把資料轉給Renderer Process；

　　如果是Zip檔案或者其他檔案，則把資料傳輸給下載管理器

4.查詢Renderer Procee

　　當上述所有完成後，network thread確認瀏覽器可以導航到請求網頁，network thread會通知UI thread，UI Thread會查詢到一個renderer process進行頁面渲染

5.確認導航，Renderer Process開始渲染page。

6.額外的工作

　　當渲染結束，rederer process會發送IPC訊號到Browser process，UI thread會停止tab中的spinner.

還是用一張圖來表示：

 在這個過程中，我們需要優化的地方，主要考慮：

• dns是否通過快取減少查詢時間
• 網路請求走最近的網路環境
• 相同的靜態資源快取
• 減小請求的大小
• 服務端渲染優化

這裡涉及的優化點，在後續文章中有講解。