web效能優化-瀏覽器工作原理
要徹底瞭解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是否通過快取減少查詢時間
- 網路請求走最近的網路環境
- 相同的靜態資源快取
- 減小請求的大小
- 服務端渲染優化
這裡涉及的優化點,在後續文章中有講解。