web效能優化瀏覽器工作原理

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

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

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

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

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

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

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

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

這是chrome多程序：

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

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

chrome主要程序

chrome有乙個主程序（browser process）用來協調瀏覽器的其他的程序。

browser procee:

renderer process：

plugin process：

gpu process：

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；

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.

還是用一張圖來表示：

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

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

web效能優化 瀏覽器工作原理