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是否經過緩存減小查詢時間
• 網絡請求走最近的網絡環境
• 相同的靜態資源緩存
• 減少請求的大小
• 服務端渲染優化

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