CSS 與 JS 是這樣阻塞 DOM 解析和渲染的

CSS 與 JS 是這樣阻塞 DOM 解析和渲染的

估計大家都聽過,儘量將 CSS 放頭部,JS 放底部,這樣可以提高頁面的性能。然而,為什麼呢?大家有考慮過麼?很長一段時間,我都是知其然而不知其所以然,強行背下來應付考核當然可以,但實際應用中必然一塌糊塗。因此洗(wang)心(yang)革(bu)面(lao),小結一下最近玩出來的成果。

友情提示,本文也是小白向為主,如果直接想看結論可以拉到最下面看的~

node 端唯一需要解釋一下的是這個函數:

function sleep(time) { return new Promise(function(res) { setTimeout(() => { res() }, time); })}

嗯!其實就延時啦。如果 CSS 或者 JS 文件名有 sleep3000 之類的前綴時,意思就是延遲 3000 毫秒才會返回這文件。

下文使用的 HTML 文件是長這樣的:

     <title>Title/<title>    

我會在其中插入不同的 JS 和 CSS。

而使用的 common.css,不論有沒有前綴,內容都是這樣的:

div { background: red;}

十五年編程經驗,今年1月整理了一批2019年最新WEB前端教學視頻,不論是零基礎想要學習前端還是學完在工作想要提升自己,這些資料都會給你帶來幫助,從HTML到各種框架,幫助所有想要學好前端的同學,學習規劃、學習路線、學習資料、問題解答。只要關注我的頭條號,後臺私信我【前端】兩個字,即可免費獲取。

好了,話不多數,開始正文!

CSS

關於 CSS,大家肯定都知道的是標籤放在頭部性能會高一點,少一點人知道如果

CSS 不會阻塞 DOM 的解析

注意哦!這裡說的是 DOM 解析,證明的例子如下,首先在頭部插入,JS 文件的內容是:

const div = document.querySelecot('div');console.log(div);

defer 屬性相信大家也很熟悉了,MDN 對此的描述是用來通知瀏覽器該腳本將在文檔完成解析後,觸發 DOMContentLoaded 事件前執行。設置這個屬性,能保證 DOM 解析後馬上打印出 div。

之後將<link>插入 HTML 文件的任一位置,打開瀏覽器,可以看到是首先打印出 div 這個 DOM 節點,過 3s 左右之後才渲染出一個淺藍色的 div。這就證明了 CSS 是不會阻塞 DOM 的解析的,儘管 CSS 下載需要 3s,但這個過程中,瀏覽器不會傻等著 CSS 下載完,而是會解析 DOM 的。

這裡簡單說一下,瀏覽器是解析 DOM 生成 DOM Tree,結合 CSS 生成的 CSS Tree,最終組成 render tree,再渲染頁面。由此可見,在此過程中 CSS 完全無法影響 DOM Tree,因而無需阻塞 DOM 解析。然而,DOM Tree 和 CSS Tree 會組合成 render tree,那 CSS 會不會頁面阻塞渲染呢?

CSS 阻塞頁面渲染

其實這一點,剛才的例子已經說明了,如果 CSS 不會阻塞頁面阻塞渲染,那麼 CSS 文件下載之前,瀏覽器就會渲染出一個淺綠色的 div,之後再變成淺藍色。瀏覽器的這個策略其實很明智的,想象一下,如果沒有這個策略,頁面首先會呈現出一個原始的模樣,待 CSS 下載完之後又突然變了一個模樣。用戶體驗可謂極差,而且渲染是有成本的。

因此,基於性能與用戶體驗的考慮,瀏覽器會盡量減少渲染的次數,CSS 順理成章地阻塞頁面渲染。

然而,事情總有奇怪的,請看這例子,HTML 頭部結構如下:

<header> <link> /<header>

但思考一下這會產生什麼結果呢?

答案是瀏覽器會轉圈圈三秒,但此過程中不會打印任何東西,之後呈現出一個淺藍色的 div,再打印出 null。結果好像是 CSS 不單阻塞了頁面渲染,還阻塞了 DOM 的解析啊!稍等,在你打算掀桌子瘋狂吐槽我之前,請先思考一下是什麼阻塞了 DOM 的解析,剛才已經證明了 CSS 是不會阻塞的,那麼阻塞了頁面解析其實是 JS!但明明 JS 的代碼如此簡單,肯定不會阻塞這麼久,那就是 JS 在等待 CSS 的下載,這是為什麼呢?

仔細思考一下,其實這樣做是有道理的,如果腳本的內容是獲取元素的樣式,寬高等 CSS 控制的屬性,瀏覽器是需要計算的,也就是依賴於 CSS。瀏覽器也無法感知腳本內容到底是什麼,為避免樣式獲取,因而只好等前面所有的樣式下載完後,再執行 JS。因而造成了之前例子的情況。

所以,看官大人明白為何 <link>


分享到:


相關文章: