從瀏覽器原理分析界面性能優化00
前言
提到前端總是繞不開前端的性能優化部分,而前端性能優化的難點在於不成體系,需要我們在開發過程中去注意各種細節.
最近這段時間在學習瀏覽器的原理的過程中,發現了很多知識點和我們的前端優化部分緊密相關,加上之前自己在項目中的實踐以及參考網絡上大神們的性能優化總結,進行一個只是框架的梳理.
文章的主要目的是提供一個大致的思路框架,以期望各位在實際項目實踐中能夠快速的定位到自己需要的點.
瀏覽器原理與優化—網絡篇
瀏覽器原理與優化—渲染篇
因爲個人感覺這個話題太大了,所以打算分幾章的時間來慢慢整理出來一個大致的輪廓,下面先簡單來個概括:
從輸入 URL 到界面顯示,瀏覽器經歷了什麼
這是一道前端經典的面試題,如果要詳細講的話,可以拓展 N 多的知識點.在這裏我們只需要記住重要的幾步,然後順着這個思路去看看,我們可以從哪些方面進行優化
- 瀏覽器將輸入的 URL 進行 DNS 解析,解析成 IP 地址
- 瀏覽器的網絡進程和服務器進行 TCP 連接
- 連接建立後,客戶端發送 HTTP 請求,請求數據
- 請求有結果後,瀏覽器渲染進程獲取數據進行內容的解析,將解析後得到的界面展示出來
上面幾個核心步驟是所有界面渲染都需要經歷的過程,我們可以從上面幾點剖析一下瀏覽器的工作原理,同時整理一下我們前端的優化知識點.
按照上圖中的思路,我們可以從網絡請求和DOM渲染兩個層面來進行我們的性能優化.
PS:因爲本人看的瀏覽器的原理主要是基於 Chrome 的,所以我們暫時只討論在 Chrome 瀏覽器下的過程
瀏覽器的多進程架構
宏觀看瀏覽器的話,他是一個多進程的架構,多進程指的是當我們打開一個瀏覽器網頁的時候,可以從瀏覽器的任務管理器看到開啓的多個進程.
它通常包含:瀏覽器進程、網絡進程、插件進程、GPU 進程和網頁渲染進程五個進程.每個進程所負責的工作都是不同的
- 瀏覽器進程,負責界面顯示、用戶交互、子進程之間的調度和一些存儲功能
- 渲染進程,渲染進程主要負責將 HTML 文件、CSS、JS 轉換爲用戶可以訪問的網頁,排版引擎 Blink(前身是 Webkit)和 JavaScript 引擎 V8 都運行在該進程中,默認情況下 Chrome 會爲每個標籤頁面創建一個渲染進程(同源站點的情況單獨考慮).
- GPU 進程,GPU 主要是用來繪製界面同時實現一些特殊的效果
- 網絡進程,網路進程主要負責網絡請求的處理,之前都是依附在瀏覽器進程中.現在獨立稱爲一個單獨的進程
- 插件進程,主要負責插件的運行,因爲進程間數據相互獨立的特性,插件崩潰也不會影響到界面的運行
多進程架構的優勢
瀏覽器的多進程架構是由之前的單進程架構改進而來的,我們都知道進程內的資源是共享的,但是進程與進程間是互相隔離的.
相對於之前的單進程架構,多進程架構的優勢很明顯
更穩定
之前所有的瀏覽器任務都運行在一個進程內,插件模塊和渲染模塊等都運行在一個進程中,當其中一個模塊出現問題,就可能引起整個瀏覽器的崩潰
但是多進程架構很顯然規避了這個問題,插件模塊和渲染模塊都在不同的進程中,當插件模塊崩潰時,渲染進程依然能夠保證界面渲染實現
更流暢
在單進程架構的情況下渲染模塊和插件模塊以及 JS 都運行在一個進程中,這也意味着當我們的 JS 執行一段耗時操作的時候,會造成所有界面的卡頓.
例如:
function timer(){
while(true){
console.log('something')
}
}
timer()
但是在多進程的情況下,每個界面都對應了一個渲染進程(先不考慮同源站點的情況),也就是說當同樣執行一段耗時操作的時候,只有本界面會造成卡頓,其他界面依然能夠流暢的運行.
更安全
單進程的情況下,通過 C/C++編寫的插件可以獲取到操作系統的任意資源,我們使用一個插件的時候這個插件也可以任意操作我們的電腦.另外的頁面腳本也可以通過瀏覽器的漏洞獲取我們的系統權限,這是非常不安全的.
但是多進程的瀏覽器架構採用了安全沙箱的策略,可以看作是操作系統對瀏覽器進程的一種封鎖,進程內的程序能夠流暢的運行,但是不能夠在你的硬盤上寫入數據也不能讀取電腦的一些敏感信息等.
多進程架構的缺陷
多進程架構確實很強大,但是也有他的缺點
- 更高的資源佔用,多進程以爲着消耗更多的內存資源
- 更復雜的架構,現在的多進程架構會增大瀏覽器各個模塊之間的耦合性造成擴展性變差,因此不得不使用更加複雜的架構來滿足新的需求.